Flash DM6437 EVM with user application

Off the top of my head the first thing I can think of to check is whether or not the demo app configures anything that your software does not. For example, check to ensure the PINMUX and EMIF registers are configured properly. Note that if you are booting through AIS that this can be done through the Function Execute command for PLL, EMIFA and DDR2 registers but the others will need to be done manually with the SET commands or in your application code.

As to things you have to do that are not included in the flashing instructions I think Tim has got it, chances are this is some configuration dependancy your code has that is not being done in the boot process.

As a next step if nothing is obvious that needs fixed you may want to try connecting up to your newly flashed board and take a look at the memory contents, comparing them to what it looks like when you load the .out file directly, this should give you an idea of if it is at least loading the code into the memory properly and makes a good first step test. Beyond this you can actually step through the code booted from flash to see where it is ending up, there is an option in CCS under the file menu to load symbol tables, this allows you to debug code on a target without actually loading the .out file contents to the target (perfect for debugging flash booting), essentially it loads the .out file into the CCS side of the debugger so that CCS knows where everything should be on the target so you can step through C and watch variables.

I have the same problem, I'm using DM6437.

when I emulate my application it works fine, when I run it out of flash (without emulator) it  it stops working..

I tried emulating the .out from the DEBUG folder , works fine..  however when I run  the .out from the RELEASE folder in the emulator ( which built to be written in flash) stops working.. additionally it only allows me to mark breakpoints in the start of main functions, not within the body .. I asume this has sense since it must run out of symbol tables.

I tried loading the symbol tables from the option below file menu as well, it loads data but how is it supposed to work? should I open the Symbol browser and put breakpoints
in the functions to be able to debug it as if it was a normal debug process ? I don't understand very well how to debug using the symbol tables, since it appears the "F10 step over" option becomes unavailable,  and only "F11 steps into" works..  My application still freezes at some point I cannot reach though.

how can I debug a Release .out then ?

Additionally, In my code I only test my board by sending some messages using the UART and use GPIO CSL calls to turn on and off some user leds.  I have no libraries included , I only include some csl header files in my project and compiles and builts just fine, but shouldn't I be adding a library for the GPIO CSL calls as well? ( CSL_FMK, CSL_FEXT )  such as rts64plus.lib  ?? how can it compile and built if I'm not adding the library for CSL code ? (besides the headers)

Thank you !!!

 I found the problem...

The problem was an optimization level set for the proyect.

In my "release" version,   Within Build Options -> Compiler -> opt level, it was set to "File (o3)", I changed it to "none" and everything worked just fine.
I tried using different optimization levels but all seem to freeze my code when running in either the debugger or my custom target.
What it seems to happen is that sometimes using these optimization levels, some functions are skipped from being executed, or others are ran as if they were no code
inside of them (empty), I mean as if they were executed instantly.

Why does this occur in these optimization levels ??

Although I still have the library inclusion doubt mentioned above.

rafael becerra said:

I tried using different optimization levels but all seem to freeze my code when running in either the debugger or my custom target.

This is likely a bug in the optimizer, these do happen from time to time, often an optimization related bug can be fixed by adjusting the way the project is coded slightly, or perhaps better, moving to a newer version of the code generation tools which resolves the issue. Since this looks to be optimization related, you may want to ask over in the compiler forum.

rafael becerra said:

What it seems to happen is that sometimes using these optimization levels, some functions are skipped from being executed, or others are ran as if they were no code
inside of them (empty), I mean as if they were executed instantly.

Why does this occur in these optimization levels ??

This is typical optimizer behavior, it often has to move around the code to optimize it fully, so when you try to debug an optimized binary your C code will no longer line up properly with the assembly which makes debugging difficult. It is likely that your functions exist somewhere, but that the binary generated by the optimizer just does not line up with the code properly in the debugger. You will often see cases where large sections of C code have no associated (dis)assembly, and the optimized assembly is squished at the top or the bottom of the C file.