i2c hangs when reading just one byte

[barthess]

The same problem

Code: Select all

> flash erase_sector 0 0 2
erased sectors 0 through 2 on flash bank 0 in 1.092930s
> flash erase_check 0
successfully checked erase state
        #  0: 0x00000000 (0x4000 16kB) erased
        #  1: 0x00004000 (0x4000 16kB) erased
        #  2: 0x00008000 (0x4000 16kB) erased
        #  3: 0x0000c000 (0x4000 16kB) erased
        #  4: 0x00010000 (0x10000 64kB) erased
        #  5: 0x00020000 (0x20000 128kB) erased
        #  6: 0x00040000 (0x20000 128kB) erased
        #  7: 0x00060000 (0x20000 128kB) erased
        #  8: 0x00080000 (0x20000 128kB) erased
        #  9: 0x000a0000 (0x20000 128kB) erased
        # 10: 0x000c0000 (0x20000 128kB) erased
        # 11: 0x000e0000 (0x20000 128kB) erased
> flash write_image /mnt/work/projects/chibios/testhal/STM32F4xx/I2C/build/ch.bin 0x08000000 bin 
wrote 13196 bytes from file /mnt/work/projects/chibios/testhal/STM32F4xx/I2C/build/ch.bin in 0.394957s (32.628 KiB/s)
> verify_image /mnt/work/projects/chibios/testhal/STM32F4xx/I2C/build/ch.bin 0x08000000         
verified 13196 bytes in 0.305961s (42.119 KiB/s)

[barthess]

yagarto-bu-2.22_gcc-4.7.1-c-c++_nl-1.20.0_gdb-7.4.1_eabi_20120616 under winxp the same problem.

[barthess]

Hi Giovanni,
When I put breakpoint on chSysLock(); (line #192 of chthreads.c) than than I can successfully start one by one all my threads. But If I set breakpoint on line #193 and press "play" button in Eclipse than I immediately have unhandled exception. Any ideas?

[Giovanni]

No idea.

I am not sure about the conditions required to trigger the problem, all the demos I am trying are working normally, could you describe how to replicate the problem? I could give it a try in the weekend.

Giovanni

[barthess]

After 3 days of debugging I still have no ideas how to stably reproduce it.

[Giovanni]

I cannot run the I2C demo, I am trying with ARMCM4-STM32F407-DISCOVERY, it works no matter what optimization option I choose, testing with GCC 4.6.x and 4.7.x.

Giovanni

[mingthemad]

I've think I've just hit this problem too.

When trying to receive just one byte, the logic analyser shows
that the I2C port is requesting two bytes. Occasionally, the
port locks up and needs a power off to recover.

I think problem may lie with special handling of one byte transfers as described
in 23.3.7 of the STM32F407 Reference manual:

- When a single byte must be received, the NACK must be programmed
during EV6 event, i.e. program ACK=0 when ADDR=1, before clearing
ADDR flag. Then the user can program the STOP condition either
after clearing ADDR flag,or in the DMA Transfer Complete interrupt
routine

I'm trying to work out what this means

Craig

[mingthemad]

Further to this, I2C sample code from ST has the following:

/* If number of data to be read is 1, then DMA couldn't be used */
/* One Byte Master Reception procedure (POLLING) ---------------------------*/
if ((uint16_t)(*NumByteToRead) < 2)

Looks like polling is needed if less than one data byte.

I'm working on this now...

[barthess]

Hi, Giovanni
I have added hardfault handler saving registers in local variables just after fault and catch some information.

Code: Select all

"r0"   0x2000280c   
"r1"   0x20002807   
"r2"   0x779b   
"r3"   0x74   
"r12"   0xbc5e69c8   
"lr"   0xfffffffd   
"pc"   0x280c78a0   
"psr"   0x81000031   
"_CFSR"   0x100   
"_HFSR"   0x40000000   
"_DFSR"   0x0   
"_AFSR"   0x0   
"_BFAR"   0xe000ed38   
"_MMAR"   0xe000ed34   
"_SCB_SHCSR"   0x0   

Some instruction try to access to 0xe000ed38 with hardfault as result. Some meaningful value in PC too.
If remove leading 2 than we will have 0x080c78a0 - it is I2C interrupt VectorC4 (accidental??).

Some times I have "inconsistent semaphore" panic during i2cReleaseBus()

[Giovanni]

It looks some kind of memory corruption that makes the program go out of control but I am unable to understand much more from that dump. Does this happen only while using I2C or is it a more general problem for you?

Also, in this thread we are talking about 2 distinct problems, the single byte problem and the crash problem, probably the who issues should be handled separately.

Giovanni