STM32 chip keeps rebooting

[rwmao]

Posted on December 11, 2015 at 02:00

Hi all,

it is really very weird. I am using stm32f411rct6,which has 256k program space and 128k ram. Very often the program is weird, keeps rebooting or dead at all. For example in a subroutine, when I delete 2 or 3 lines of code, it is working well. If I keep them, the chip keeps rebooting. I swear the lines I deleted have no any problem in logic. Adding code somewhere else may also have the similar problem. Sometime after I add the code, the chip is totally dead. No any response. Please give me some clue to debug: 1. limit of ram, overflow? Program Size: Code=28884 RO-data=456 RW-data=748 ZI-data=29364  I don't really use too much space. 2. when chip keeps rebooting, I measured the voltage. It is fluctuating. But I swear the code I added, which causes the problem, have nothing to do with the power. Please help.

[Tesla DeLorean]

Posted on December 11, 2015 at 05:00

Make sure you stack is big enough for any local allocations you have in your routines. The few lines might change the register/stack utilization. Stack size is in the startup_stm32f4xx.s, or equivalent, file. Figure out what your actual utilization is like.

For hardware issues, check VCAP pins, voltages/capacitors, etc.

[rwmao]

Posted on December 11, 2015 at 07:05

Stacksize is 0x4000

it is also very weird that sometime turning on a LED has no problem.But i replace it with turning off the same LED, the chip keeps reseting.I don't think it is because of GPIO because even I delete the line for LED and do something else, the problem appears again.

[rwmao]

Posted on December 11, 2015 at 07:44

For example in the following code:

It is working well. But if I uncomment the last 3lines, the chip is totally dead. No response. In logic, it has no any problem. Note that the Flash as large space. Total space is about

ADDR_FLASH_SECTOR_5+0x20000. I am sure the hex code only use much less space than

ADDR_FLASH_SECTOR_5

//save average value
Hex32bitTemp001=AverageValue8points<<16;
Hex32bitTemp001=Hex32bitTemp001 +AverageValue8points;
HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, ADDR_FLASH_SECTOR_5, Hex32bitTemp001);
/* //save upper and lower value
Hex32bitTemp001=FilterUpperStartingValue<<16;
Hex32bitTemp001=Hex32bitTemp001 +FilterLowerStartingValue;
HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, ADDR_FLASH_SECTOR_5+4, Hex32bitTemp001);
*/

[rwmao]

Posted on December 11, 2015 at 19:14

Please help checking the schematic if there is anything wrong.

As the power supply, I use RFE3033, which is capable to output 25mA current, is it enough? In the microcontroller, I use the module of I2C1,I2C3,USB, timer9,10,11, SWD debug, and the system is running at 96MHz using 16MHz internal clock(I could use external clock too). Do you think 25mA current is enough? My question is if power supply is the reason, why adding couple lines would significantly change the system? Thanks

[Tesla DeLorean]

Posted on December 11, 2015 at 21:00

My question is if power supply is the reason, why adding couple lines would significantly change the system?

I'm not sure it does, I'm trying to shot-gun a solution/causes based on very limited data. Not sure why you'd get a reset, beyond a watch-dog or external issues. Perhaps it's in the Hard Fault Handler? Perhaps you can add some more diagnostics there, or debug a bit more?

[rwmao]

Posted on December 12, 2015 at 00:11

I use while(1){;} to track which line has problem.

It is very weird that it comes to this linehex16_currentdata=ADS7828buffer_i[ADS7828buffer_pointer_process];while(1){;}ADS7828buffer_pointer_process++;for above code, everything is still OK. The voltage at the power supply is still 3.3v.But if I move while(1) to end of the highlighted line, the program goes wrong. the measured voltage is 3.0v. which means something causes excessive power consumption.ADS7828buffer_pointer_process just a uint16_t variable.overflow? causing crash of other register?

[rwmao]

Posted on December 12, 2015 at 00:29

Update.

I add 3 lines at the beginning of main() right after initialization.GREEN_LED_ON;TM_DelayMillis(500);GREEN_LED_OFF;They are just a indicator showing whether the program was ever running.very weird that the program can correctly run the code,hex16_currentdata=ADS7828buffer_i[ADS7828buffer_pointer_process];ADS7828buffer_pointer_process++;while(1){;}Therefore it is not caused by the above code. Instead there is something else wrong.Code overflow to mess up register?Please give me more advise.Thanks

[Tesla DeLorean]

Posted on December 12, 2015 at 01:38

Ok, can you step through this with a debugger? Or see where it gets stuck? Are you sure it ''resets'', can you stick a logic analyzer on NRST and capture these events?

Have you tried turning optimization off? Have you double checked the clocks the system is running from? Use the MCO (PA8) pin, review. Have you double checked the flash wait states, and cache/prefetch settings?

[Tesla DeLorean]

Posted on December 12, 2015 at 01:48

Assuming the supply is browning-out, suggest you use a 2 ch scope, trigger on falling edge of NRST on first channel, with second channel attached to supply.