ChibiOS Free Embedded RTOS

Hi,

Running 21.1.1 on a board with I2C slave devices on both I2C3 and I2C4 busses (device has the same address so needed to be separated that way). I started with the STM32F769-discovery demo code, and adapted it to my board, which uses a F765 but seemingly close enough for I2C.

With a working config, I can successfully write a command and read back the result to the device on I2C3. All looks good on the logic analyzer.

Just switching that same test code to use I2C4 and the same configuration, and it stops working. The driver returns MSG_RESET, and digging in I can see that the I2CD4 structure has error=4 which seems to mean that the NACKF bit was set and it prematurely stopped. However, inspecting the SDA/SCL lines with a logic analyzer, the start bit is sent, then the slave address, the device is indeed acking after the slave address is clocked out (just like the one on I2C3) but then the peripheral aborts and finishes.

I have tried with and without DMA, same result.

I have also tried running 21.1.3 in case this was a bug that was fixed and to no avail.

I also blindly tried a change similar to bug #1202 (in case ordering matters) and it did nothing (again it doesn't work non-DMA either). As an aside, the RM seems to have errata in the I2C4 DMA channels (one of the TX channels seems to have been mislabelled as RX, but the definitions in stm32_registry.h seem to follow the CubeMX tool).

I'm not sure what to try next. I had a quick look thru the HAL code for obvious cut/paste errors between drivers and didn't see anything myself.

Dave

Hi,

I would check GPIO settings for I2C4 pins.

Giovanni

Forgot to mention that, I used the same GPIO settings for both I2C3 and 4, namely:

Alternate=4 (from RM), Open Drain, No pull (this is handled in HW), Speed High. Looking at the SDA and SCL pins on a scope, and they look fine to me.

I also verified the programming by inspecting the registers in the debugger at runtime, just in case I botched the board.h

The weirdest part is that I can see the slave device assert the ACK on the ninth bit. It's clear since there's a tiny blip when the master lets go and the slave begins to pull low. This happens long before the clock is asserted, and looks just list the working I2C3 peripheral to me.

I had access to two free pins that I could assign to I2C1, so to rule out a copper problem, I wired up I2C4 and I2C1 together in parallel (and obviously turned off I2C4 GPIO pins). Using the I2C1 driver with the same configuration, I can successfully talk to the devices that "belong" to I2C4.

Try looking into device errata, it you see the command going out then GPIO and clocks should be ok.

Giovanni

I don't see anything specifically like my problem. There is some mention of NACKF getting set incorrectly when using 10bit mode, but I am not.

For fun, using the I2C4 peripheral again, I just #if 0'd out the code that stops the transmission if the NACKF bit is set:

LLD/I2Cv2/hal_i2c_lld.c:


And it "works", so I don't feel like it is a driver/programming issue. Maybe I discovered a new errata?

It would be interesting to test I2C4 on a different device STM32G4 for example.

Giovanni

The only other high-pin-count devices I have access to which would have I2C4 are still in the F7 family, but I'm willing to try anyway.
- STM32F746ZG on a nucleo-144 board
- STM32F769NI on a disco kit.

I'll wire them up with a i2c chip in the coming days.

I've got a STM32F767 board which uses I2C4 as a master port; works OK accessing a FRAM using tried and tested routines.
Unfortunately only used during board testing - not currently required for real-world applications - so limited use.

Interesting, thanks steved.

Before I had a chance to play with different chips, I took inspiration from
viewtopic.php?f=16&t=6243

I did a start/stop/start on I2C4, and now it seems to work as expected. Note, this is a twenty line test program, coming out of reset so it shouldn't be a case of the hardware was left in indeterminate state from previous actions/threads etc..