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.

  • 0
    •  Analog Employees 
    on Sep 27, 2010 10:22 AM

    Hi ADUzer,

    the only way to recover the ADuC7024 is to do a mass-erase in that case.

    You can do this as explained in the mentioned thread with ARMWSD.

    http://ez.analog.com/thread/3969

    Only from the default UART pins.

    Or you need to implement any kind of SW in your application which can

    do this mass-erase from within your application - i.e. via password protected

    command over in your communication.

    During RESET the part has no clock and so the access via JTAG is limited.

    You can't download and execute code into SRAM - what is normally required

    for FLASH-erase/programming via JTAG.

    The only chance you possbly can try, but depends on how quick after release of

    the RESET the NAP is executed, you can possibly get control via JTAG if you

    start the download at the same time.

    But the chance is very small.

  • As a general rule for all developers I would suggest that they place a 1 second delay at the start of their code at least during the development phase.  This then allows them to gain JTAG access to the part before any problem code gets executed.  If such delay is unacceptable a spare pin could be used that will put the part in a loop to allow JTAG to gain access without reaching the offending code.  As long as you can gain JTAG (debug) access you can erase the code and put on corrected code.  These tricks can be removed for the final product after development is complete.

  • I have manually modified the PCB to route the serial data channel to P1.0 and P1.1 and managed to recover the part using the Serial Download program. It's not something I'd like to do too often!

    I'm not familiar with how a JTAG interface is used to interact and control a microcontroller. Does the processor have to execute it's code when using the JTAG connection to program/erase/etc? I was thinking that if I powered up the processor with its !RST pin asserted (low) I could then establish a connection with JTAG which would say keep the part in reset with the TRST signal. The processor would then never have opportunity to execute it's code. It seems the dificulty is in getting control of the micro via JTAG quick enough before the processor reset signal is removed and has had time to execute user code.

    Also, ARMWSD.exe did not list a COM port I had at COM36 in the Serial Port list of the comms tab. Is there a limit to the COM number that this program will show?

    On the subject of nap mode. When timer 2 interrupts the processor from nap mode by the timer 2 interrupt, my testisng has seemed to show that a wakeup timer interupt (IRQ, bit4) handler in the ISR is not called, i.e the transition from nap to active mode occurs without the ISR being called. Is this correct?

    Thanks.

  • 0
    •  Analog Employees 
    on Sep 28, 2010 1:22 PM

    Yes - the core need to be used for Flash erase/programming.
    The small code snippets are loaded via JTAG into SRAM and

    at the end a watch-/breakpoint is placed to communicate

    with the JTAG-state.machine. This is the standard for ARM-cores.

    More details to find in the ARM Technical Documentation.

    ARMWSD is written for up to 32 ports.

    Normally the port number can be changed back in

    Windows Device Manager for a number in this range - also if

    the ports are listed as used.

    The IRQ should execute as normal after wake-up from NAP - you may check this with a GPIO

    i.e. you can toggle a pin :

    if(IRQSTA & 0x00000010){
        GP0DAT ^= 0x00010000;            // Toggle P0.0 on IRQ entry
        T2CLRI = 0;
    }

  • 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.