Major Cerbuino issue

I have a Cerbuino Bee that has been working fine and now I can’t get it to run without the debugger being attached.

Even if I deploy a release build it does not run.

If I deploy the debug version and then connect to the device with attach I see this in the output window:

   Invalid address 0 and range 40 Ram Start 20000000, Ram end 20020000
   Invalid address 0 and range 40 Ram Start 20000000, Ram end 20020000

What could be causing this?

The board is updated to the latest release but tiny booter is still and latest is so could this be the issue?

[quote=“Dave McLaughlin”]
but tiny booter is still and …[/quote]

I updated TinyBooter and still the same error.

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 now also see this when I run the debugger for the first time. A dialog appears with

An exception occurred while attempting to launch the debugger: Object reference not set to an instance of an object

Could be related?

If anyone has a Cerbuino Bee and could download and try this code I’d appreciate if you have similar issues.

[url][/url] (794K)

It is not Gadgeteer based.

I compiled the lib and program as debug; flashed my Cerb Bee with the latest bits ( 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.

Same result with RELEASE bits - works with debugger, fails without. It’s a confirmed Heisenbug.

You’re going to need some non-debugger-based logging to sort this one out.

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. :frowning:

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)


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.


1 Like

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.

I suspect this might be the case in debug mode.

Posting it here anyway helps others who might come across something similar.

Will know soon as the guy is about the install the board in the next hour :wink:

Appreciate your time on this. Cheers.