Hi , we are testing mbed-os-blinky example on our discof746ng stm32f7 board.
We added few print statements in mbed os blinky example :
DigitalOut led(LED1);
printf("before starting\n");
printf("now led should blink\n");
while (true) {
led = !led;
ThisThread::sleep_for(BLINKING_RATE);
}
now led should▒before starting
now led should▒before starting
now led should▒before starting
now led should▒before starting
now led should▒before starting
now led should▒before starting
now led should▒before starting
now led should▒before starting
now led should▒before starting
now led should▒before starting
now led should▒before starting
now led should▒before starting
now led should▒before starting
now led should▒before starting
now led should▒before starting
now led should▒before starting
LED is blinking as well
Prior to this we were working on using qspif as block device and also having a large buffer initialised on stack.
What can be the issue here?
It was continuously only printing these lines and only half of the second line,even though it is not in the loop.For any binary that we are testing now, we only get the starting lines(in most cases only the first line) as if it were in a loop or being reset after every sec.The swapping part doesn’t happen with other binaries.
It is really looks like continuously restarting. If so, maybe you can try to use ResetReason.
And strings could be swapped by compiler optimization maybe.
Can you tell me what a version of MbedOS (2,5,6) you tried and what a tool (Mbed Studio, Online Compiler…)you use? For reproducing.
I can not verify it, because I normally not use the Mbed CLI and currently I am not able to make it working and I do not know why… sorry.
Anyway I tried it with the OnlineCompiler and MbedStudio IDE/online and it seems be ok, with these three tools.
But that not looks like an issue in the binary if you write
the same binary works fine on another discof746ng board
I have no idea if that can help but you can try to use the STM32CubeProgrammer and make full erase of chip of the board (also ST-link’s firmware update).
I had some strange behavior of a board in the past and the full chip erasing solve that.
Yes.It is not an issue with the binary itself as the behaviour is same with any other well tested binaries.We have tried a full chip erase as well,but it still shows the same behaviour.
There was a camera attached to the board which was capturing images and these captured images were being sent to a server using http. Quality of these images being captured were continuously degrading and camera initialization was also failing at times.
Driver used : BSP_DISCO_F746NG - STM32746G-Discovery board drivers V1.0.0 | Mbed
Tested without the camera attached,but it is still getting reset.
Other than that we were also testing writing the image data to a file with qspif as block device.
Do you know how we can check and erase bad blocks in qspif or just set watchdog to stop.
When I have an issue a usually refer back to basics. So if your issue occurs also on a blinky example then try to solve it on the basic example without the unimportant things - software/hardware.
I don’t understand it so deep but I do not think a bad value in external memory which is not initialized in a Blinky example can not cause an watchdog error. Ofc maybe I am wrong.
About the WatchDog… I probably successfully achived same state like you have, with a simulation but on different board (Nucleo-L432KC). STM32CubeProgrammer >> left panel OB button>>UserConfiguration>>IWDG_SW
OR STM32 ST-LINK Utility >>Target>>OptionBytes>> WDG_SW.
In the default state I had the checkbox checked. But when I changed the WDG_SW to unchecked and save it then the board “keep restarting”.
It will be probably necessary connect the board with pressed reset button.
The process of saving new values every time fails
This setting is not changed when you load new binary.
Setting option bytes with stlink worked.
Thank you so much for your help
We had few other bytes which were all in unchecked state in both stlink and stm32cubeprogrammer.
After setting the option bytes same as set in the working disco board,the binaries are running fine now and not getting reset.
Only the camera initialization part is failing, but that seems to be an issue with the camera cable.
Thank you for your feedback, I am glad you achieved what you wanted.
Please be so kinde and mark as Solution a post what was helpful for you. That will mark the topic as closed and will inform someone else “That is working” in the future.
