I have upgraded a DC application running on a small machine equiped with a RMC2110, by adding several functionalities (the resulting .BIN file has grown up from 160 Kb. to 205 Kb)
Debugging makes the application work without problems. And then putting the programming cable out, and letting the small machine running stand-alone, with the application as it has been sent during the last compilation (“Compile to flash, optimize size”), makes it work also.
But if I generate a .BIN file, instead (using the same options) and send it to the small machine with RFU, after putting the programming cable out and turning on the machine, the application remains “hanged” in the very first display.
I have no idea of the cause. Do you have any hint? Is there any essential difference between the binary results sent to the flash during “compilation for run”, and during “compilation to .BIN file”?
Are you sure your targetless configuration is set for your processor?
I’m having a similar problem with an RCM3700. Did anyone find any answer?
I’ve noticed that RFU displays a different download size than DC. Perhaps it’s counting its’ downloader code, which is reported in a separate message in the DC environment.
I thought it might be an unititialized variable that get trashed differently in the two download methods, but I’ve spent a couple weeks looking for that, and if that’s the issue it could be in any of the hundreds of lib files that get compiled.
I’m trying a udpdebug utility on an ethernet port, and oddly enough it’ll work once the debugger attaches. It’s like something is waiting to link up with the debugger when you download with the RFU.
All I can reply is the same. Are you sure you are compiling to the correct processor. When the programming cable is plugged in, and you are compiling your program with Dynamic C, the program checks automatically which processor it is connected to.
If you create the binary file for the RFU, the program doesn’t know which processor will be used in the end, that is why you have to select the correct processor in the targetless options.
Checked processor type many times.
I think it has something to do with printf’s in the startup code. I’ve found that if I use SHDesign’s udpdebug as an ethernet debugger it will start up once the debugger is detected. Before the debugger is found, it goes through most of its startup sequence, but then either the watchdog times out or it loses its stack, or something, because it keeps re-starting until the startup coincides with the debugger attachment packet.
Checking some of the other threads, I ran across references to printf vs debug mode, and I done some preliminary investigation along that track. It looks like OPMODE indicates it’s in debug mode, even when the programming cable isn’t attached. It’s hard to be sure, because right now I have no way of monitoring debug mode other than through a debugger - need to set up a hardware flag somewhere to see that.
Why this happens only with the RFU downloaded version is the real mystery.
Eureka! Found a solution to this particular instance, anyway.
It seems that calls to kbhit() and/or getch() hang up when download is done from the RFU. From info on another thread about printf issues, I created a global variable
debugMode = (OPMODE & 8) == 8;
in the startup code, then blocked the kbhit() & getch() calls if debugMode is false. This lets them work in the DC environment but bypasses them in free-run mode. Along the way, I used a hardware output to confirm that debugMode is false when the program starts after an RFU download.
Thanks to assorted contributors!