cancel
Showing results for 
Search instead for 
Did you mean: 

MCU operates fine when started from STM32CubeIDE(Debug or Run), but does not operate properly on its own.

YAkse
Associate III

update:

I plug the board to PC, click on this button(the right one, run button) below, CubeIDE loads the code into board and it works like a charm. I then disconnect the board, replug it, and now it is not working. Adding a delay(around 8 ms) after setting PE bit in I2C1->CR1 solves this strange behaviour.

0693W000003Q3PSQA0.png

--------------------------

OK, it seem weird, I know.

I do have an STM32F103C8T6 MCU and doing some I2C with it. My code works just fine if I start the debug session and let it run, or to press the run button directly, inside STM32CubeIDE.

My debugger is one of these:

0693W000003Q390QAC.png

I do have some I2C initializations and some sensor reading just before while(1) loop, and inside of the infinite loop is:

while(1){

led_toggle();

dummy_delay(16800);

}

So, when I pressed the run button for example, everything is alright, LED flashes on and off normally. At this point, I think that code is loaded into the MCU, so anytime I power the board, it should start to execute same flow, that is what I expect. Then I unplug the debugger USB from PC, board is powered off and debug session is terminated, then I just replug the USB an expect it to start to flash the LED. However, that is not the case. LED never flashes.

This looks strange to me, why it is working while debugging or even by runned inside CubeIDE but not working when the board is out of debug connection with the PC?

Any ideas?

p.s : SystemCoreClock is at 24 MHz.

I2C speed 100 kHz.

I should also add that, after some tryings, I came up with the following observation.

in main(), before while(1), I do have the following lines,

I2C1_EN();
	i2c_init();
 
	/* MPU6050 initiation */
 
	mpu6050_wake_up();
	led_toggle();

With the above code, led never lights up or flashes after unplug-plug sequence.

But I observed that if I insert led_toggle() before mpu6050_wake_up(), after unplug-plug sequence, the LED lights up once and then stucks there, i.e LED stays ON, instead of moving to while(1) and flashing. So, it is possibly stucking in mpu6050_wake_up() function. That is just a I2C write function, by the way, and confirmed that it is working, as it is also sure that the program runs fine when runned from CubeIDE.

I found that adding a delay in I2C initialization, after setting PE bit looks like solving the ambiguity. But I could not find any warnings stating one should delay the MCU for a while after initiating I2C peripheral.

9 REPLIES 9
KnarfB
Principal III

What board? How are BOOT0 and NRST pins connected?

Make sure BOOT0 is pulled LOW, check what you're doing with BOOT1 also

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
TDK
Guru

> and confirmed that it is working

Sounds like your investigation confirms it is not working to me. Doesn't that function never returning explain exactly what's going on?

If you feel a post has answered your question, please click "Accept as Solution".
YAkse
Associate III

OK, function works, because there is no problem when I start a debug session, disable all breakpoints, and let it run freely. Everything works. But then when I unplug the board from PC, thus powering off, and then re-plug, it stucks between i2c_init() and i2c_write() (inside mpu6050_wake_up). Adding a delay after setting I2C1->CR1 PE bit solves this ambiguity.

so called blue pill board. I don't know which NRST pin you are talking about, there is a RST pin on ST-Link, but I am not using it, only SWDIO, SWCLK, GND and 3.3V are used. BOOT0 jumper on blue pill board is on the "0" side, not 1.

Both jumpers are on the "0" side rather than "1" side.

YAkse
Associate III

The biggest thing that I cannot understand is that, without the need of a delay, it works like a charm while a debug session is going on. But while it is freely running, the problem occurs.

The MPU6050 has some startup time. Are you waiting long enough after it's powered before you're accessing it?
If you feel a post has answered your question, please click "Accept as Solution".
YAkse
Associate III

Hmm, this looks valid, let me move the delay not after i2c_init() but somewhere before it, so we can now that delay is needed but not specifically after setting PE bit but anywhere before accessing MPU6050. I will let you know when I try it.