cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F103RC I2C Nightmare - Help!

clark2
Associate II
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!??!

0690X00000605LhQAI.png

0690X00000605LmQAI.png

 
6 REPLIES 6
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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
clark2
Associate II
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
Associate II
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
Senior II
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
Associate II
Posted on February 11, 2016 at 22:26

What?

clark2
Associate II
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.