A program I am developing runs perfectly when downloaded via the debugger, but when booted from Flash, after sleeping and then waking, it hangs when writing to the ICR:
Development platform: Spectrum Digital ezDSP for TMSC5515
Development tool: Code Composer Studio v 4
The core of the code I use to put the CPU to sleep and to restore CPU clock domain configuration upon waking is as follows.
(At this point of the program, I have also inhibited all interrupts and all peripheral clocks and bypassed and disabled the PLL.)
iOrigICR = IDLE_ISTR ;
// Apply deepsleep ICR (write & IDLE cmd) ==> CPU sleeps
IDLE_ICR = 0x03EF ;
asm(" idle");
// ================ CPU IS NOW SLEEPING ================
// Because global interrupt-inhibit is set, upon awakening,
// control will continue here:
// RTC interrupt ==> CPU awakens w/ default ICR configuration
LED_GREEN_REG &= ~LED_GREEN_MASK ; // Turn on green LED
// Disable all individual interrupts via IER0,1
CSL_CPU_REGS->IER0 = 0x0000 ;
CSL_CPU_REGS->IER1 = 0x0000 ;
LED_RED_REG &= ~LED_RED_MASK ; // Turn on red LED
// Restore original ICR (write & IDLE cmd)
IDLE_ICR = iOrigICR ;
LED_YELLOW_REG &= ~LED_YELLOW_MASK ; // Turn on yellow LED
asm(" idle");
LED_BLUE_REG &= ~LED_BLUE_MASK ; // Turn on blue LED
If I download and run the program from the CCSv4 debugger, it runs just fine.
When I cold-boot from Flash (by connecting power via the USB cable), the program runs until the point at which the red LED is lit, then hangs. If I replace "IDLE_ICR = iOrigICR" with two NOP_16's, it runs through another waking cycle, then hangs when it tries to sleep again, so the program is obviously hanging when writing to ICR after having executed a single sleep / wake sequence.
The following shows that the code in the Flash memory is functional, but needs some sort of intervention by the debugger to perform correctly:
- Connect USB cable to ezDSP => Cold boot from Flash => hang after lighting red LED
- Launch TI debugger
- Connect Target => Error 0x80000242/-1143
- Retry => Connects OK (CPU halted)
[ If, at this point, I use 'CPU Reset' and Run to reboot from Flash, the program again hangs. ]
- Load Symbols for program resident in Flash - As I understand it, this should only affect CCSv4, not the target.
- CPU Reset [PC <= boot loader entry point]
- Run => Reboot from Flash => Runs perfectly!
I do nothing whatsoever to change the code that has been loaded from Flash into the DSP RAM, but somehow loading the symbols into CCSv4 while connected to the target changes the behavior of the target in a way that allows it to function correctly.
I am now using a .gel file with nothing but GEL_TextOut(...) calls, so it does nothing to alter the target state..
Somehow, "Load Symbols" is the magic incantation that allows my code to run. "Connect Target" alone is not enough. Certainly puzzling.
This earlier experiment: downloaded code and then wiped it out by powering down:
- Launch TI debugger
- Connect USB cable to ezDSP => Cold boot from Flash => hang after lighting red LED
- Connect Target => Error 0x80000242/-1143
- Retry => Connects OK (CPU halted)
[ If, at this point, I use 'CPU Reset' and Run to reboot from Flash, the program again hangs. ]
- Load (into DSP RAM) .out file for same program as is in Flash
- Disconnect
- Unplug USB cable from ezDSP; after ~30 seconds, reconnect => Cold boot from Flash => hang after lighting red LED
- Connect Target => Error 0x80000242/-1143
- Retry => Connects OK (CPU halted)
- CPU Reset [PC <= boot loader entry point]
- Run => Reboot from Flash => Runs perfectly!
After using the debugger to download a copy of the program, I both logically and electrically disconnect it from the target, thus wiping out the code I had downloaded, but when reconnected, it now allows the target to successfully boot from Flash. [Downloading an unrelated program does not have this effect.]
It appears that, somehow, downloading the code changes the state of the debugger in way that it, in turn, changes the state of the target device in a way that allows it to execute correctly.
Why does the write to ICR fail, and what can I put into my code to put the DSP into the same state that the debugger appears to?
Dan
