After deploy an app and leave the Cerberus running stand alone for more than one hour, the execution stops.
We try using two different boards, and two diferent firmware (March version 0.1.0, and beta April version 4.2) with same results.
Anybody know about this? I’ve tryed to find around this theme with no results. I’m new in this forum and I apreciate if anybody can explain where I can report this bug.
It maybe raising an exception so keep VS2010 attached so you can see the messages.
Welcome to the community.
Thanks Gus for prompt response!
Ok, I’ll be try to keep VS2010 attached to catch exception.
After discover this problem I have try with this very simple code and is dificult imagine an exception inside.
(probably is firing any other exception from core).
public static void Main()
LED = new OutputPort((Cpu.Pin)FEZCerberus.Pin.PC4, false);
Yes the code is very simple and will probably not throw an exception. I am not sure.
I just started my Cerb40 running the same code (except I used PC3, as PC4 is not available on Cerb40). I’ll let you know how it goes. I’m running the 2nd firmware version.
I have encountered the same issue. There is a bug involving Thread.Sleep(n).
I have run several tests of loops with a Thread.Sleep in them. Loops with longer sleep durations lock up in fewer iterations than loops with shorter sleep duration.
See my post:
Another thing to note…
I compiled the Netduino Go firmware for a 8MHz crystal and flashed a STM32F4xx Discovery with it and have been running 3 boards for a couple days now without a lockup. Also, the sleep duration with this firmware is correct and not doubled as is the Cerb40 firmware.
I can confirm. I didn’t watch to see at what point it locked up, but eventually did.
Can you provide some general steps on how you did this? Did you compile with RVDS or GCC? Did you need to modify the hardware? Did you flash via the on-board STLink or via the bootloader?
@ Joel Kunze: Please provide instructions and files how can we flash discovery board with Netduino FW…
I used the time limited demo of RVDS. No hardware mods. Did not flash with ST-Link, I used the bootloader.
In Netduino Go solution, change platform_selector.h line 46 to
#define SYSTEM_CRYSTAL_CLOCK_HZ 8000000 // 8MHz external clock
in the STM32 device code, change STM32_bootstrap.cpp line 26 to:
#define PLL_M HSE_VALUE / 1000000
build as normal.
Use DFU File Manager to combine the bin ER_BOOT, ER_CONFIG and ER_FLASH
Use DFU Demonstration to flash DFU into Discovery.
I don’t know if this was the best or even the right way to do it.
I also did this for a 12MHz crystal because I had done the hardware mod on a Discovery to use the Cerb40 firmware on it.
That 12 MHz Discovery and two un-modded Discoveries have been blinking the 4 leds around the accelerometer for a couple days now each with a different sleep duration. So I haven’t run any code of significance on them to know if there are issues.
I did make a couple of attempts at flashing the 12MHz firmware to a Cerb40 but could not get it to boot afterwards so I put the original Cerb40 firmware back on it.
Hi, did anyone find a solution to this problem? i’m heaving it too, and so far i didnt finad any workaround.
I did make my own alternative delay method, but it slows everitihng down so much that it is more or less unusable. It seems to me that thread.sleep is needed to enable diferent threads to switch… if there is no thread.sleep the procesor can compute only one thread.
The issue is the same witch basic 1.0.0 firmaware and the 4.2 - which by the way seems more unstable.
New SDK 4.2/4.2 will be out very shortly, the very next thing will be to go back and update cerberus
Hi, thank you for your information, now when the new 4.2 sdk is out, when can we expect this problem to be touched?
Hi, i wonder, if there is any prograss on this issue? If not is it somhow possible to SW reset the device?
I have measured, that for example the freezing happens somewhere in about an hour and half, if i could issue a system restart every hour, it would be some kind of workaround… I have one idea how to do it… dedicate one pio for reset - wire the pin to the reset button and set the pin high for a while to issue a reset.
Do you guys think it is possible to do it this way… or is there any other purelly SW solution… Or is fix imminent?
Thank you for your answers.
It is done already but not out yet. Few days.