Hello,
I tried to run the blinker program on a Nucleo-144 STM32L496ZG board with ChibiOS 18.2. So I based my project on RT-STM32L476RG-NUCLEO64 project found in the "demos" folder, after installing ChibiStudio_Preview20.7z on a Windows 10 64 bits computer.
Unfortunately the blinker program gets reset unexpectedly before half an hour of program run... I discovered that issue after interfacing the Nucleo-144 board with a display: the time printed on that display was always resetting to 00:00:00 before half an hour of program run. Thinking it was a mistake of mine, I reverted back to the original blinker program and discovered that it was also unexpectedly resetting after a period of time.
Then I tried to understand what was going on by enabling debug flags, stopping hypothetical timers on reset, suspending the core on reset, etc. without any debug success... I other words, I am completely stuck.
I join the source code of my blinker program which contains the files I modified to port on Nucleo-144 STM32L496ZG board. I also modified the behaviour of the original blinker program in order to emphasize the reset of the MCU: the blue LED is flashing at a fast pace for 10s on program boot; on normal program operation, the green and red LEDs are flashing alternatively.
Do you have the possibility to test that program on the same board as me ?
Thanks for the help,
Unexpected reset while running blinker program on Nucleo-144 STM32L496ZG board with ChibiOS 18.2
Moderators: RoccoMarco, barthess
Unexpected reset while running blinker program on Nucleo-144 STM32L496ZG board with ChibiOS 18.2
- Attachments
-
- BlinkerUnexpectedReset.7z
- (17.54 KiB) Downloaded 128 times
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Unexpected reset while running blinker program on Nucleo-144 STM32L496ZG board with ChibiOS 18.2
hi,
Is the time period before reset fixed or random?
Do debug options catch anything? (by stopping MCU)
Giovanni
Is the time period before reset fixed or random?
Do debug options catch anything? (by stopping MCU)
Giovanni
Re: Unexpected reset while running blinker program on Nucleo-144 STM32L496ZG board with ChibiOS 18.2
The time period before reset is random. I even seen resets occuring several times in a row at program boot.
About debugging, here is what I wanted to tell you (a few weeks ago) with a first port attempt of the blinker program : I putting a break point at the call of halInit() function at the beginning of the main(). When the unexpected reset occurs, the program hits that break point (see screen shot "UnexpectedReset_01_halInitBreakPointHit") but after pressing F8 to resume the program, the led is not blinking anymore (see screen shot "UnexpectedReset_02_ResumeButNoLedBlinking"). Finally, trying to know where the program is running, I clicked the suspend button and apparently it went into the unhandled exception vector (see screen shot "UnexpectedReset_03_SuspendAndUnhandledException").
Otherwise, I made the main thread to permanently check the flags in the RCC_CSR register. It seems that SFTRSTF and PINRSTF flags are set when the reset occurs.
About debugging, here is what I wanted to tell you (a few weeks ago) with a first port attempt of the blinker program : I putting a break point at the call of halInit() function at the beginning of the main(). When the unexpected reset occurs, the program hits that break point (see screen shot "UnexpectedReset_01_halInitBreakPointHit") but after pressing F8 to resume the program, the led is not blinking anymore (see screen shot "UnexpectedReset_02_ResumeButNoLedBlinking"). Finally, trying to know where the program is running, I clicked the suspend button and apparently it went into the unhandled exception vector (see screen shot "UnexpectedReset_03_SuspendAndUnhandledException").
Otherwise, I made the main thread to permanently check the flags in the RCC_CSR register. It seems that SFTRSTF and PINRSTF flags are set when the reset occurs.
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Unexpected reset while running blinker program on Nucleo-144 STM32L496ZG board with ChibiOS 18.2
Could you try the code in trunk? I made changes to the L4 support, maybe it changes something, please try the unmodified demo.
It could also be a defective board, if you can, try another one.
Giovanni
It could also be a defective board, if you can, try another one.
Giovanni
Re: Unexpected reset while running blinker program on Nucleo-144 STM32L496ZG board with ChibiOS 18.2
Hi Giovanni,
Yesterday evening, I tested the blinker program on another board: a Nucleo-64 STM32L476RG. I got the same unexpected reset. Nervertheless, I observed that when the reset occured, the LD1 (COM) led was flashing for a short period of time and that without having OpenOCD connected to the board. So something weird here...
Today, I powered up that same board with a basic USB power block, and I didn't observed any reset (not sure at 100% because I was not always in front of the board). So I am suspecting something wrong with the USB port of my laptop computer under Windows 10 on which I plugged the board... I will continue my investigation this evening.
Yesterday evening, I tested the blinker program on another board: a Nucleo-64 STM32L476RG. I got the same unexpected reset. Nervertheless, I observed that when the reset occured, the LD1 (COM) led was flashing for a short period of time and that without having OpenOCD connected to the board. So something weird here...
Today, I powered up that same board with a basic USB power block, and I didn't observed any reset (not sure at 100% because I was not always in front of the board). So I am suspecting something wrong with the USB port of my laptop computer under Windows 10 on which I plugged the board... I will continue my investigation this evening.
Re: Unexpected reset while running blinker program on Nucleo-144 STM32L496ZG board with ChibiOS 18.2
Hi,
For the one interested, a workaround for this issue consists to disable the device called "MBED microcontroller USB device" in Windows 10's device manager. This device appears as a removeable disk drive and Windows was doing something with it, causing the reset of the Nucleo board... I found some clues in a topic called "STM32F4 Resetting itself (Nucleo 64)" on the ST community forum.
Good bye.
For the one interested, a workaround for this issue consists to disable the device called "MBED microcontroller USB device" in Windows 10's device manager. This device appears as a removeable disk drive and Windows was doing something with it, causing the reset of the Nucleo board... I found some clues in a topic called "STM32F4 Resetting itself (Nucleo 64)" on the ST community forum.
Good bye.
Who is online
Users browsing this forum: No registered users and 45 guests