This issue has been resolved. See https://github.com/raspberrypi/linux/pull/6050

There appears to be a bug in the Pi 5 i2c driver. This is a rather serious bug because it prevents the CPi-M from communicating reliably with the MCP23017 (Modular FADUINO DO module). A demonstration of the bug has been provided to Raspberry Pi engineers, and at this time, they are expected to address it. See the following bugs reports:

• https://github.com/raspberrypi/linux/issues/6043
• https://github.com/raspberrypi/linux/issues/5784
• https://github.com/raspberrypi/linux/issues/6047

When the CPi-M is booted to the desktop, the following warning appears.

The reason for this error appears to be because the bootloader is querying the capabilities of the power supply through the USB-C port using the USB PD communication protocol. However, the CPi-M is currently powered through the GPIO pins, not the USB-C port, so the Pi 5 cannot query the capabilities of the power supply.

Some potential solutions:

• The warning message can be suppressed by modifying the bootloader. However, that means the production team will need to modify the bootloader for every CPi-M product, and a utility will need to be created for them to do that.

• The Pi 5 could potentially be powered over the USB-C port instead of the GPIO pins. In that case, however, some additional hardware will need to be added to connect the sub board to the Pi 5's USB-C port, and some additional hardware will need to be added to handle USB-PD protocol queries. Perhaps a device like this: https://www.ti.com/lit/ds/symlink/tps65982.pdf?ts=1710706740672-

After shutting down the CPi-M and then booting up again, the following error message is displayed:

There error only occurs after shutting down, and then rebooting. If just rebooting, the error does not occur.

I'm not sure what is causing this error or how to solve it. Perhaps powering through the USB-C port could also solve this problem, but I'm not sure.

The CPi-M was tested at an ambient temperature of 60℃ in the temperature chamber, while running the aging test software. After several minutes, the CPi-M goes down.

The problem was determined to be caused by the PMIC overheating, as adding a heatsink to the PMIC resolves the issue.

We don't currently have a heatsink on the PMIC.

A possible solution could be to add another aluminum cylinder to couple the PMIC to the main heatsink. Unfortunately, that may also require modifying the enclosure design and mold.

The WiFi and Memory ICs may also require cooling, but that has not yet been determined.

Now that the Pi 5 i2c driver bug was fixed by the Raspberry Pi engineers, I've begun testing the CPi-M and Modular FADUINO more thoroughly.

Using a configuration of Pi5←→Sub Board←→HEAD Module←→ADC Module 1←→ADC Module 2, I see the following strange signal anomaly.

The signal is improved if one of the ADC modules is removed.

Using a configuration of Pi5←→Sub Board←→ADC Module 1←→ADC Module 2 (i.e. removing the HEAD module), the signal shows some improvement, but watch this video for how one can introduce a similar symptom as that mentioned above.

I suspect this is due to a lack of proper buffering. In the CPi-M sub board, we are currently using the TCA9406 for 3.3←→5V level translation, but that chip does not have a built in buffer. The TCA9617B might be a better choice. See https://www.ti.com/interface/i2c/level-shifters-buffers-and-hubs/overview.html for more information.

Also, the HEAD module uses FETs for buffers. See the following schematic:

I'm not sure if that type of buffer provides proper bi-directional buffering for i2c communication. It might help to use a TCA9617B on both the CPi-M and the HEAD module, but that might also introduce propagation delays. See https://www.ti.com/lit/an/scpa054/scpa054.pdf?ts=1710874431673 for more information.

According to the TCA9406 datasheet, the voltage translator circuit may need to be modified:

OE might need to be tied to 3.3V instead of 5V. See the following from the datasheet:

It appears the i2C signals never truly reach 0V (GND). With the 1K resistors added, there is a bias of about 0.7~0.8V. Without the 1K resistors, the bias is slightly reduced to 0.5V.

In contrast, notice there there is almost no bias when using the Pi 5 without a sub board:

The datasheet says the TCA9406 already has built-in 10K pullup resistors:

The ADS1115 has a special way of SDA and SCL as address pins. You can see it documented on pp. 34 of the datasheet: https://www.ti.com/lit/ds/symlink/ads1115.pdf?ts=1710875972274

The ADC module utilizes that feature as can be seen in the following schematic:

Addresses 0x48 and 0x49 work fine, but I have not been able to get the the CPi-M and Linux to communicate with 0x4A and 0x4B. There might be a way to make it work, but I have not figured it out yet. Also, the signal integrity issues are making the research process difficult.

Maybe after the signal integrity issues are solved, the addressing issue will also be solved.

UPDATE: After connecting the ADC module directly to the Pi 5, without the sub board and HEAD module, I was able to communicate with a device configured for address 0x4B, so this problem appears to be a problem with the sub board and/or HEAD module.

Currently, there is no way to connect the camera and PCIe ribbon cables without disassembling the CPi-M.

A potential solution could be to add 22pin-to-22pin FFC/FPC connectors to the sub board and expose one side outside of the enclosure, as pictured below:

For Bookworm, I'm proposing that we add a read-write data partition to our OS image so that, when users enable the read-only file system overlay, they will still have a place to write data to. However, due to a bug in the Bookworm OS, when enabling the read-only file system overlay, the read-write partition also becomes read-only.

This is not a serious issue. It is easy to fix, but will probably be confusing and annoying for customers.

The bug has been reported to Raspberry Pi engineers, and a fix offered, but they have not yet decided on the implementation. See https://github.com/RPi-Distro/raspi-config/pull/225

As of right now, there is no audio driver for GPIO 12 and 13, so it seems it may not be possible to have a stereo audio feature for the Pi 5 unless we were to add an additional hardware codec and use something like i2s.

According to one of the Raspberry Pi engineers, this features should be added some time in the future, but no commitment has yet been made.

i2c on the Raspberry Pi has a lot of jitter compared to serial communication, even if using a realtime kernel. It seems the reason for this is the use of interrupt IO for the i2c driver. It is possible to isolate a single CPU core and dedicate it to running a process, but it's not currently possible to isolate interrupt handlers to a single core. So any driver that utilizes interrupt IO will result a lot of jitter.

A potential solution would be to modify the driver to use polling IO instead of interrupt IO.

Another potential solution is to wait for Raspberry Pi to release the Programmable IO (PIO) feature for the Raspberry Pi 5. With PIO it should be possible to create an I2C driver independent of the main CPU. Raspberry Pi engineers have stated that they plan to release PIO for the Pi 5 in the future, but have not yet committed to a release date.

We might be able to improve the jitter by setting the affinity of interrupts. See https://github.com/raspberrypi/linux/pull/6090