2008-06-04 09:44 PM
IAP programming - cannot stop target
2008-03-03 03:49 AM
Hi all,
I have programmed an IAP application in order to load other programs remotely. I am using ARM7 STR7. Now I got two microcontrollers ''blocked'', when I try to reprogram these I always get the following message: ''cannot halt target after reset'' the explanation I found is the following: This error message is displayed when the debugger is unable to make the ARM stop running and enter debug mode typically after carrying out a reset. This error message could be caused by the following: * Unreliable JTAG Connection �? Try reducing the JTAG clock frequency or reducing the target interface's cable lengths as much as possible. * Incorrect support package �? Make sure you are using a CPU/board support package intended for your part. * Incorrectly connected reset signals �? Typically the nSRST signal should be connected to the target's core reset signal, it should not be connected to the JTAG TAP reset (TRST) signal. * Invalid code has been executed �? This may be caused by your program not being loaded correctly, a problem with the target's memory or a bug in your program. You can check the download and memory by verifying the download. The point is that I've checked the first three possibilities and I think there's no problem. And I'm not getting access to the uController so I can't try the forth. Is there any possibility that I've set some register or internal variable unintendedly that blocks the uController? In that case, is there a possibility to set it to the default paramaters? I hope anyone could help me, many thanks. Dani.2008-03-03 07:44 AM
Funny, I just had a similar situation today. I could not connect to the MCU via JTAG to reprogram the flash memory. Apparently, the problem was caused by a failed flash rewrite: the partial firmware would start executing at power-up and leave the MCU in a state in which it would not allow a JTAG connection. I solved it by managing to connect to the MCU after the power-up reset but before the firmware in flash is able to derail it (very short time window).
I have another idea: the MCU has the DBGRQS pin. I'm not sure what it does, but maybe it forces the MCU to enter the debug state before the buggy firmware starts executing, so that you can reprogram the flash ROM.2008-05-05 11:09 PM
Hi,
Tie BOOTEN = 1 boot0 = 1 boot1 = 1 and erase flash or reprogram with some working application. Then BOOTEN = 0 boot0 = 0 boot1 = 0 and reprogram with some working application. In my example it works. r,Alex2008-06-04 09:44 PM
Hi,
Seems an invalid code is executed from flash. Booting from SRAM or System memory instead of flash you can connect again to MCU and erase the flash ;)