Main Site Documentation

Cerb40: Code not running on reboot w/o debugger


#1

Ok, hopefully this is my last road block. I’ve been developing a pure digital I/O solution (no analog, that is) off and on for the past few months. I’ve always worked in the debugger. Now, I am ready to demo my new board and code, but I can not connect to the Cerb40 via UART unless I am debugging! I disconnected my USB cable, grounded the reset pin, and no response. Everything works fine when I run under the debugger.

Sorry, I can not update the codeshare with my latest code version (http://www.ghielectronics.com/community/codeshare/entry/589), and the project is too complex to post here. However, the posted version behaves the same.

I’m powering the Cerb40 through USB w/voltage regulator and cap, connecting to the Cerb’s COM3 via virtual serial port, at 460800.

If I start debugging, then stop debugging, I don’t lose connection, and if I disconnect, I can reconnect without issue, as long as I don’t power down or reset the Cerb40.

Anyone have any tips? Do I need to delay before initializing COM3 or something?


#2

Hmm, the hit I found that had a similar issue was http://www.ghielectronics.com/community/forum/topic?id=10984&page=4 and it was a GND issue. Any chance that’s your issue too?

I assume you have “flash a LED” at startup or something equally simple that shows the code is getting past that point?


#3

I did at one time, but I disabled it. I just put an indicator back in at the top of Main and it lights and extinguishes the LED as expected. I can debug using my 16 outputs with my 16 demo LED’s, but 16-bit debug messages are a little sparse.

I’ve not sure the GND issue applies here. I am supplying 5V through a USB to TTL cable, and my power-on LED on the 3V3 rail lights when I plug in. Thanks for the hint though.


#4

often when a program works fine in the debugger and has problems starting standalone is is a timing problem.

when a MF device is booted with the debugger, there is a small delay before your code begins to execute. when booted standalone, this delay is much shorter. often this results in an external device receiving commands before it has time to initialize.

you can test to see if there is a startup timing issue by putting a sleep at the beginning of your program.


#5

ok, so it runs, so now the issue is just about serial comms.

I am guessing now you’re hitting the serial port subscribe-before-open issue - do you use a DataReceived event handler?


#6

Thanks guys! I think I found it. One of the threads I kick off (the Random Number Generator) was going down, I believe, and killing everything. I guess this goes down as a timing issue. Threw in a delay in that thread proc and it all works!