Chip resetting after every sleep

[Ludeks]

Hello everyone,

I have a board with the STM32F103C8T6 mcu from ebay, it can be found for $3 as STM32 minimum system board, it's basically a clone of Maple Mini. I have been trying for two days but I can't get it working. It's working fine with the standard peripheral library provided by ST, but when I try Chibios it just keeps restarting.

I use stm32flash utility to load the firmware through UART, I don't have any ST-LINK or any debugger unfortunatelly

The source code is here: https://github.com/ludekstepan/stm32-playground
It's based on Maple Mini demo (I have tried almost every demo for the STM32F1xx) I tried to remove everything that could cause a problem, I have tried different clock options, but nothing seems to work.

The OS boots properly, the LED is lit for one second and then the whole system restarts. By observation and trying different timeouts, I came to a conclusion that the system restarts when quitting the sleep routine. But I can't tell more.

I feel like I have tried everything and I feel very desperate

Perhaps someone can have a look at my code and see if there is an obvious mistake. Thank you!

[Giovanni]

Hi,

Few suggestions:
1) Is the watchdog enabled?
2) Enable assertions, checks, state checker, stack overflow checker in chconf.h and see if something is caught. If so then the system stops without rebooting.
3) Get a cheap discovery/nucleo board so you can debug your code.

Giovanni

[Ludeks]

Hi,

1) since I don't know how to enable it, I assume it's disabled Now seriously, the chip works with other projects without Chibios and when I remove all references to chThdSleepMilliseconds() from the code and rise the priority of the blink thread, it keeps running with LED 50% duty cycle.
2) A have enabled all the CH_DBG_* in chconf.h but the result is the same, it keeps restarting, no halt.
3) I'll try to connect it to this board http://www.st.com/web/en/catalog/tools/PF250990 and see how it goes.

Thanks!

[rew]

The discovery boards are not expensive, but the nucleo are even cheaper. And somehow, ST has decided that all of them are almost the same price independent of the CPU. So, for cases where you quickly want to see if something works, without having to worry about "if it fits" or "if the CPU is fast enough" I would recommend getting one with the biggest CPU you can get.

I think that's the nucleo-F446 right now.

[Ludeks]

Hello guys,

I finally discovered what was wrong The program was fine, the problem was with the way how I flashed it and executed it. I used the BOOT pins to select the internal bootloader, then I uploaded the hex file over uart using the stm32flash utility and then I instructed the utitility to start execution from 0x08000000 by executing stm32flash -b 19200 -g 0x08000000 /dev/tty.SLAB_USBtoUART. When I switched the BOOT pins to execute directly from flash, it started to work. I guess the mcu wasn't properly reset after starting execution directly from the bootloader. Anyway, do you have any idea how to prevent this? Is it possible to enable a reset routine during the initialization?

Ludek

[rew]

To get a proper reset, what is done occasionally, is to enable the watchdog. It can trigger a real reset.... The problem is then you'd end up in the bootloader again.

Sorry, I can't be of more help. I've briefly tried what you are doing and given up...