The application is only 35928 bytes in size and I only allocate 100 bytes maximum in my application.
I am using the Modbus library from codeshare and before I update the firmware to the latest this was all working. Do I need to roll back to an earlier version?
I compiled the lib and program as debug; flashed my Cerb Bee with the latest bits (4.3.7.9 from GHI SDK 4.3 R3) and deployed the program. I single stepped through Main() and then let it fly after the first iteration. I get Modbus exceptions of course, but it is happily blinking away.
However, if I power the board up without the debugger attached, then no lights are flashing. I have to assume there was an uncaught exception somewhere. At this point, to debug it, one would have to insert some logging to capture what’s going on to an SD card or over a comms line so that you can observe it without the debugger.
I am having a similar problem on my Radius device not working standalone, and just haven’t gotten around to debugging it yet.
Thanks mcalsyn it is good to know that there is an issue.
The exceptions are the Modbus no reply so that is good.
We only have one of these to install to update a really old project we did many moons ago. My college is on standby on a platform in the north sea for this.
I need a fix for this ASAP.
I built a test programme to run on the Cerbuino Bee to flash the LED and this works in debug and in no debug so I suspect this is something in the code somewhere. Strange thing is that an original design worked for this. Mmmm, hang on I might still have that code.
Ok - I did some real hamfisted debugging and the program is locking up, but not crashing, on this line: (Program.cs ~line 84)
sendModbusFormat();
In the debugger, a first-chance exception is thrown, but on a free-running device, it looks like it hangs. I figured this out by inserting a fast-blink loop into a try/catch around the whole program - it never fired, so it is a hang and not an exception. Then I put a fast-blink loop into the main code and moved down through the code bit by bit until the led didn’t flash anymore. That’s how I knew the line that was hanging.
If you comment out the gyroThread.Start() line the code runs in non-debug mode.
I then dug deeper and found why. When i was originally testing I had the gyro simulator running which means that the thread would be processing and Thread.Sleep() would be called after the telegram was found. With nothing connected, the loop was never calling Thread.Sleep(). Adding an else statement on check for bytes and calling Thread.Sleep() gets it working.
That must mean that having the debugger attached introduces additional context-switching opportunities, which is good to know. As I said, I have a similar problem elsewhere and it appears that the lack of those additional context-switching opportunities can lead to hangs when the debugger is not attached.
