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.
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()
{
OutputPort LED;
LED = new OutputPort((Cpu.Pin)FEZCerberus.Pin.PC4, false);
while (true)
{
LED.Write(true);
Thread.Sleep(200);
LED.Write(false);
Thread.Sleep(200);
}
}
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.
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.
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?
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.
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.
Pavel