Permanently locked out from ADuC7024 after entering Nap Mode.

I've been testing switching from internal oscillator to external crystal using the procedure in the device data sheet (Rev C, page 55) and reproduced below. (This procedure was not in Rev A datasheet). This code is placed just after entering main() of the application

T2LD = 5;
TCON = 0x480;
while ((T2VAL == t2val_old) || (T2VAL > 3)) //ensures timer value loaded
IRQEN = 0x10; //enable T2 interrupt (commented out this line)
PLLKEY1 = 0xAA;
PLLCON = 0x01;
PLLKEY2 = 0x55;
POWKEY1 = 0x01;
POWCON = 0x27; // Set Core into Nap mode
POWKEY2 = 0xF4;

I commented out the IRQEN line (to try something out) and built and ran the application. Since this time I have not been able to access the ADuC to re-program it. I am using IAR EWARM and a miDAS J-Link. I get error dialogue messages along the lines of "Unable to halt the ARM core".

I have tried holding the !RST pin low while powering up and then accessing using JTAG and other conditions, but I seem to be permanently locked out of the device. By holding !RST low while powering up I expected the ADuC7024 would not execute (the above) code to enter nap mode and that I could then use the JTAG connection to reprogram with a program that does enable the wakeup timer IRQ.

There is a related thread http://ez.analog.com/thread/3969 ("When debugging the ADuC70xx parts via JTAG, I sometimes encounter problems where the JTAG interface no longer works?"). I am not able to use ARMWSD to try a mass erase as the application has SIN and SOUT mapped to pins other than P1.0 and P1.1 and those pins have other uses.

Is there any way to recover? Also, why am I locked out, as I mentioned earlier I expect that if I hold the device in reset on power up it would not enter nap mode?

I could do with changing the bootloaded/kernel to map the UART to pins other than P1.0 & P1.1, but accoring to http://ez.analog.com/thread/3984?tstart=30 this is not possible.

Parents
  • 0
    •  Analog Employees 
    on Oct 13, 2010 2:05 PM

    Debug on an ARM7TDMI requires the core to be active.

    All accesses to the chip resources go through the core, and involve loading instructions into the ARM7TDMI pipeline and satisfying memory requests though the JTAG interface while in debug mode.

    The JTAG interface on an ARM7TDMI does not have any means of waking up the part so if it doesn't respond there is little that it can do outside of asserting the RESET pin.

    Therefore it is recommended that you allow a little time after a reset before going into this type of mode to allow the JTAG interface to gain control. Or providing some means of waking up the part.

    If the application does not cater for this, then the ARMWSD means of erasing the memory is recommended.

Reply
  • 0
    •  Analog Employees 
    on Oct 13, 2010 2:05 PM

    Debug on an ARM7TDMI requires the core to be active.

    All accesses to the chip resources go through the core, and involve loading instructions into the ARM7TDMI pipeline and satisfying memory requests though the JTAG interface while in debug mode.

    The JTAG interface on an ARM7TDMI does not have any means of waking up the part so if it doesn't respond there is little that it can do outside of asserting the RESET pin.

    Therefore it is recommended that you allow a little time after a reset before going into this type of mode to allow the JTAG interface to gain control. Or providing some means of waking up the part.

    If the application does not cater for this, then the ARMWSD means of erasing the memory is recommended.

Children
No Data