STM32 I2C PROBLEM

akp25i · ‎2012-09-02

Posted on September 02, 2012 at 16:57

Hello ,

I am developing firmware for an application , in which a 24 series eeprom and a GPS module is connected to same I2C bus of stm32l151 , stm32 will receive data from GPS as ''SLAVE ( DEFAULT MODE)'' , and will communicate with EEPROM as MASTER , what is happening is that , while communicating with I2C eeprom , the GPS master is sending data , and the flags like '' stop (slave mode) '' are set , so it is not possible to decode the Event correctly in ISR , i am checking busy flag before entering in to EEPROM communication , still it is happening

is there a way to avoid this ? or shtting down GPS module while communicating with EEPROM only option ?

Also how does ''Debugging '' affects I2C communication , if i Breakstop in mid of communication , while STM32 is in Slave mode , will it Hang ?

David Littell · ‎2012-09-03

Posted on September 03, 2012 at 15:57

From your description it sounds as if the I2C multi-master stuff isn't implemented correctly at either the GPS or the STM32 (or possibly both). Do you know for certain that the GPS implements the multi-master mechanisms? Did you implement that stuff at the STM32?

In either case, I'd personally separate the EEPROM from the GPS and use two I2C interfaces, even if I had to bit-bang the EEPROM I2C. I2C is quirky enough to make reliable without mixing in multiple masters on the same bus. Or better, if your GPS module provides a different interface (serial and SPI are pretty common) change to that.

Regarding your debugging question, I don't have direct experience with your specific device, but I've seen things work both ways. Some devices have breakpoint options to ''stop only the core'' or ''stop everything'' which will determine if peripheral modules are allowed to continue (as far as they can without core attention) or if they just freeze at the breakpoint.

emalund · ‎2012-09-04

Posted on September 04, 2012 at 15:13

I once made the mistake (fortunately caught it before I powered up) of making SCL push-pull (after all it is a clock generated by the master) That would create exactly the problem you have.

Also how does ''Debugging '' affects I2C communication , if i Breakstop inmid of communication , while STM32 is in Slave mode , will it Hang ?

if all devices are I²C NOT SMB you can breakpoint your hearts delight. SMB has timeout, I²C does not

Erik

akp25i · ‎2012-09-06

Posted on September 06, 2012 at 20:17

Erik ,

Both pins SDA , SCL are configures as NO PULL

akp25i · ‎2012-09-06

Posted on September 06, 2012 at 20:19

Dave ,

I am working with finished board , the interface can't be changed , the GPS datasheet says that it operates in Multi master mode by default , and STM32 Data sheet also says so ,

David Littell · ‎2012-09-06

Posted on September 06, 2012 at 22:09

Is the board shipping in volume? If not, then it really isn't finished, now is it? Especially if it doesn't work... Never accept the ''can't change it, it's finished'' (c)rap from hardware guys or managers. If that BS were true we'd never see anything other than ''Rev A'', would we?

Just as an experiment, mod the board and your code to split the I2C's and see how it behaves.

It still sounds like multi-master isn't working correctly. I think your new best friends are a really good I2C protocol analyzer, the I2C spec, and a huge pot of coffee. You're about to become an I2C expert.

Have fun.

emalund · ‎2012-09-06

Posted on September 06, 2012 at 22:50

Just as a test try to slow the I²C down to a crawl. I did some I²C testing on the STM32 and the clock to data/data to clock delays are sometimes almost in picoseconds (all these lightning fast transitions ARE within the I²C spec).

It is possible that the GPS just can't handle zero delay even where zero delay is legal by the I²C spec. Bus standards is just about the most violated thing in the industry (I have yet to see a J1708 that adheres to that standard, we have all seen the 0-4V ''RS-232'' drivers'', most USB to serial thingies do not work if you do more than pass one way data .....)

It seems most device interfaces are thrown together and 'tested' with ONE other device.

Erik

akp25i · ‎2012-09-15

Posted on September 15, 2012 at 22:52

For now i have got EEPROM working by hibernating the GPS , although its not a solution , but for my purpose EEPROM will be only needed for Firmware Upgrade , so this can work