My program wont run after removing the download cable on BL4S160

I am using BL4S160 Rabbit Controller board. My program is able to run smoothly on Prog/DEbug Mode. However, the program will not able to run on Run Mode after I remove the downloading cable and do a power restart on the Rabbit Controller board. I have used the Compile >> Compile to target >> store program in flash option.

I am using Dynamic 10.72E version.

I have removed all printf statement in my program.

Have you tried compiling to target with one of the sample applications and see if it executes the sample application after removing the cable.

1 Like

If you leave your printf() statements in, and add the STDIO_DEBUG_xxx macros as described in the STDIO_SERIAL.c sample, you can connect the “RUN” connector of the programming cable and see the debug output.

Program timing can be different when running outside of the debugger, and the memory layout can change such that a bug that doesn’t crash the program in debug mode (say a buffer overflow) will crash it in run mode (since it overwrites a different area of memory).

I have also seen an instance where the target needed the ground connection of the programming cable to work correctly (because it was otherwise missing a ground needed to communicate with some device).

As Campbell stated, try a simple sample (maybe one that toggles an output) to see that it can work.

Does the program work at all? Do you see any change in the I/O state? Network link on the Ethernet?

Ensure you are using ‘Compile target’, not ‘Compile to .bin file’, unless you’ve set the correct board in Options->Targetless->Board Selection.

I believe the BL4S160 should automatically handle the startup mode pins (SMODE0 and SMODE2), based on the programming cable. Yet, running only in debug mode would be a symptom of a SMODE pin stuck asserted. Some Rabbit development boards have a jumper for this. You might check for a jumper and also ensure you aren’t using an IO pin designated for SMODE pins.

As the others have said, trying demo code is a good way to rule out simple code bugs. Aside from memory being laid out differently, running in debug mode may hide some timing related bugs by simply slowing down processing. It is more common than you might expect.

1 Like