STM32F103RC I2C Nightmare - Help!

[clark2]

Posted on February 11, 2016 at 21:40

I have been trying for way too long to get this peripheral to behave the way I want it to.  I'm trying to implement a driver that makes use of interrupts and DMA so as not to block.  While much about this device is baffling, my most recent debugging episode led to this remarkably baffling situation:

With a breakpoint set at the entry to the ISR, after setting the START bit, the first thing I do is read SR1.  I can see from the ''registers'' window in my debugger that ADDR is set.  However, after reading the register to a local variable, this variable reads 0x00000080.As if this peripheral isn't flaky enough, I need more mysteries of this nature like I need another hole in my head.Can anyone explain this?  Please!??! 

[Tesla DeLorean]

Posted on February 11, 2016 at 21:51

It is important to understand that viewing the registers in the debugger alters the internal state of the peripheral. It doesn't provide a magic window into the device.

You should instrument your code and let it tell you what it sees and how it reacts.

[clark2]

Posted on February 11, 2016 at 21:58

There is something fishy about the way this is happening... if I move the breakpoint to inside the ''ADDR - EV6'' condition, it stops there with sr1 == 0x00000082 as expected.  But if I break at ''uint32_t sr1 = I2C1->SR1'' and single-step, then the results are wrong.  This must be an artifact of the debugging process???

I'm using Rowley CrossStudio 3.6 with a generic FT2232 debug interface...Considering STM's crappy micros, crappy documentation, and crappy forum hosting, I'm about ready to close this chapter and go back reality and play with some real hardware.

[clark2]

Posted on February 11, 2016 at 22:00

Yeah.  I think I figured that out.  It doesn't help me tame this belligerent peripheral.

[Radosław]

Posted on February 11, 2016 at 22:23

1. Magic number = ugly code.

2. to much bb. 3. Read AN2824 and see coresponding code. 4. Read note to SR registers, is important. This I2C isn't frendly, but not that hard to program. NEVER VIEW registers with bits clerable by reading this register.

[clark2]

Posted on February 11, 2016 at 22:26

What?

[clark2]

Posted on February 11, 2016 at 23:48

1. What?

2. What?3. I've been through it a dozen times.  It is far from ''optimized'' and certainly not non-blocking.  I did implement many of the procedures, however.4. What?I get the part about the debugger reading registers. That makes sense.