I2C Read Issue STM32 F3

[aglaser]

Hey,

I'm trying to talk to an MPU9150 from an STM32F303C on a custom board. In debugging the I2C communication, I don't seem to be able to perform reads from the IMU.

I get a complete I2C transaction (see first attachment for logic analyzer cap) when I call i2cMasterTransmitTimeout in the following manner (corresponding to a write of 'd' to register 'ra' on the IMU):

Code: Select all

txbuf[0] = ra;
txbuf[1] = d;
status = i2cMasterTransmitTimeout(i2cptr, mpu9150_addr, txbuf, 2, rxbuf, 0, 100);

A complete write to the microcontroller, resetting the device

complete_write.png (46.31 KiB) Viewed 6383 times

However, when I call it in the next manner (corresponding to a read from register 'ra', putting the data in 'd'), the microcontroller sends the address byte, receives an ack, and then hangs with SCL low until the timeout event (see second capture from logic analyzer):

Code: Select all

txbuf[0] = ra;
status = i2cMasterTransmitTimeout(i2cptr, mpu9150_addr, txbuf, 1, rxbuf, 1, 100);
d = rxbuf[0];

An incomplete read from the microcontroller, hanging after transmitting device address

incomplete_read.png (42.31 KiB) Viewed 6383 times

I'm configuring the timing for the i2c in the following manner (which I pulled from an F373 testhal example). The I2CConfig struct on this architecture corresponds to low-level registers in the microcontroller.

Code: Select all

const I2CConfig i2c1_config = { 
  STM32_TIMINGR_PRESC(15U) |
  STM32_TIMINGR_SCLDEL(4U) | STM32_TIMINGR_SDADEL(2U) |
  STM32_TIMINGR_SCLH(15U)  | STM32_TIMINGR_SCLL(21U),
  0,  
  0
};

Things I've verified:

-There ARE pullup resistors on the SDA and SCL lines
- I don't have SDA and SCL swapped
- I'm using the correct I2CD peripheral (I2CD1)
- I've set the "alternate" PAL mode, the correct alternate function, and have set them both as open drain (configuration in board.h)
- The address I'm sending is correct
- I'm attempting to read from a valid register
- Timing appears to be valid (since I get complete 'write' operations, but not 'read' ones).
- I've looked through this (http://forum.chibios.org/phpbb/viewtopic.php?f=16&t=1312) forum post, and my problem seems to be different.

I've verified that I can read from and write to the accelerometer using a different hardware library, so I'm assuming my problem is with ChibiOS HAL configuration. Any advice would be appreciated!

[gleb]

Just faced with the same or alike problem today when was trying to pair the BMP180 barometric sensor with STM32F103 under ChibiOS 2.6.2. The system hangs (or loops waiting for an hardware event) after any i2c operation following a successful i2c read. Interesting enough is that when I open registers view window in IAR and read i2c1 status regs via STLink (which I guess makes some hardware flags be reset upon the status regs read), the system resurrects and starts working until another i2c read occurs. I have not yet tried to explore it further, but from what I can see so far I think that ieither the platform has a flaw in i2c state machine, or the HAL code does not process the state machine events correctly.

[Giovanni]

The problem is that I cannot test that specific scenario, any idea about the source of the problem?

Giovanni

[gleb]

Will send you the problem piece of code tomorrow when get back to my desktop PC @ work. BTW, another thing that I noticed when working with i2c hal driver is that if I turn off background thread creation in chconf.h, the i2c transmission functions stop working, looping endlessly somewhere inside them. There are multiple conditions on looping, so I did not go further in my investigations, just turned the background thread back on. Might that be a clue to the above?

[Giovanni]

You are disabling the idle thread so it is expected. You can do that only if you create your own idle thread.

Giovanni

[gleb]

this might introduce problems as there's neither compile-time nor debug-mode runtime checks against that. As some HAL drivers do not require idle thread and some do, I would add a compile-time warning in those HAL drivers that require idle thread once they find CH_NO_IDLE_THREAD set to TRUE

[Giovanni]

The idle thread is always required, there must be always at least one thread that never leaves the ready state.

Giovanni

[gleb]

Giovanni, thank you - now it's clear re idle thread. Re I2C read problem on BMP180 - the HAL code seems not guilty - the BMP180 device requires 16-bit reading, so once I switched to 2-byte read buffer length, everything started working ok. Sorry for bothering you, it was my mistake as I was referring to BMP085 code which is read byte-by-byte in a sample code

[Giovanni]

Hi,

Don't worry, I think there can be something lurking in the I2C code, there have been other reports but I2C is not something I can test easily.

Giovanni