STM32 I2C wont work without debugger

[ojoel]

Posted on August 28, 2013 at 12:45

Hi all!

Im currently working with a project that should read data from sensors using the I2C bus.When i am using a debugger to start the program it runs at it should. Reading sensor values and putting out the data on a CAN-bus. When i remove the debugger the MCU still behaves like it should.BUT, when i try to start the MCU after a reset (just pulling the plug) the MCU stops reading data from the sensors. Is there any background processes that the debugger prevents from running or runs that can make this error occure?Im using a stm32f107 and reading sensor data from an MPU-6050 and a HMC5883LKindest regardsJoel

[Tesla DeLorean]

Posted on August 28, 2013 at 13:46

The debugger is invasive, it disables certain features, see DGBMCU section in Reference Manual

''Clock control for timers, watchdog, I2C and bxCAN during a breakpoint'' If the debugger probes peripheral registers it doesn't have a magic way of accessing them that doesn't clear status bits, ie reading USART1->DR will clear SR RXNE Instrument via the serial port to understand function when the debugger is not attached.

[chen]

Posted on August 28, 2013 at 18:40

Hi

Are you sure the project is set up to a) run from flash b) is the vector table correct? The debugger can load and start your program from anywhere in RAM or Flash. Your program must be set up to run from Flash and the vector table should point to where it is in flash. The vector table is usually in an assembly file named after the processor eg stm32f107.s Depending on what development enviroment you are using, there is also a file which sets the vector table offset address at start up. Start off with a simple test for you program - flash a LED and see if that works from a cold boot. Check this works from  a cold boot (just applying power no debugger attached)

[mlakata]

Posted on August 28, 2013 at 19:04

Two ideas (both of which have happened to me)

1. Check that you have good decoupling on your power rails and that there isn't a stray source of RF that is coupling into the I2C lines. The additional ground from the JTAG debugger might be sucking some of the RF noise out of the I2C lines making it work. I had this problem and the workaround was to add a 10 pF cap to the I2C SDA line.2. Make sure that the I2C lines are high before you enable the I2C periph on the STM32. Perhaps the pull-ups are too weak and the idle state is not good immediately after power-up. Or some other device on the I2C bus is pulling it lower after power-up.  Look at it with a scope on power up.  If necessary, put in a few millisecond delay in your STM32 firmware before you enable I2C.

[ojoel]

Posted on August 29, 2013 at 13:58

Thank you for your help guys! It was actually your idea no2 Mark that helped my solve it!

Thank you!

[pierremld87]

Hi,

i have the same problem. When Debugger is set on my soft, all is ok (debugger or not connect). But if i desactivate the debug functionnality the I2C don't work for read my sensor.

What's solution did you find to resolve your problem ?

Thanks

Pierre

[Andrew Neil]

---

@pierremld87 wrote:

When Debugger is set on my soft, all is ok (debugger or not connect)

---

Not sure what you mean by that?

---

@pierremld87 wrote:

if i deactivate the debug functionality

---

Or that?

Also, what does "the I2C don't work for read my sensor" mean?

• Is there no activity at all on the I2C lines?
• Is there activity, but incorrect?
• or what?

Does the rest of your code work OK?

As @Tesla DeLorean said, instrument your code to give UART output so that you can tell what's happening without the debugger connected.

Have you checked all the things suggested by @chen and @mlakata ?

[pierremld87]

Hi Andrew, excuse me for error in text.

if i define : DEBUGGER_ENABLED = 1

#define DEBUGGER_ENABLED 1

HAL_DBGMCU_EnableDBGSleepMode();

HAL_DBGMCU_EnableDBGStopMode();

HAL_DBGMCU_EnableDBGStandbyMode();

I2C functions are ok. I read my sensor each minutes.

if i not define : DEBUGGER_ENABLED = 0

#define DEBUGGER_ENABLED 0

HAL_DBGMCU_DisableDBGSleepMode();

HAL_DBGMCU_DisableDBGStopMode();

HAL_DBGMCU_DisableDBGStandbyMode();

I2C functions are not ok. I read value 0 on my sensor each minutes.

It's like I2C don't work if debugger is not activated and when i'm on stop mode.

I try to read sensor but result is 0.

[Tesla DeLorean]

As the thread's been kicked, I'll add than anything with FIFO's is particularly prone to breaking. ie USB, QSPI, SDMMC/SDIO, UART and things like NAND memories, where you advance the internal state every time you read or inspect the content.

Basically the Schrödinger's Cat dilemma, that inspection of what's going on interferes with the experiment's outcome. Or the Watched Pot Never Boils / Continuously opening/shutting the oven door.

What's better is to express the states as part of the more normal operation, that when you read UART->SR / ISR in normal operation, you store or express that information so the subsequent flow and behaviour can be analyzed. Dyanmic Analysis of Real Time Systems cannot be done well via Single Stepping in a debugger.

[Tesla DeLorean]

So perhaps a different problem, not sure the poster from 10-11 years ago is going to manifest to help you. Their email may have changed, could have expired, and we've gone through about 4 forum software transitions. Predates HAL / Cube

Present your code/situation in 2024 terms.

Consider if optimization is on or off.

That the timing or behaviour of the code changes between the debugged / undebugged conditions.

The debugger can enable pins, clocks and features it needs to operate, these can be non-reset conditions, and things your code isn't normally doing / enabling.

If optimization changes things, look for latent issues in your code, where memory/registers are used differently, or things that change under interrupt/callback need to be volatile as they are happening outside normal / linear code flow.

I2C look at the physical interfacing, pull-ups, and slave devices and expectations.

Any Errors / Status reported by the HAL ?