LPC925 ISP - Erasing Hangs FM

Started by marshall, December 31, 2006, 03:08:39 AM

Previous topic - Next topic

marshall

Hi there, I have successfully entered ISP mode using the NoTouch on a LPC925, and can perform all the ISP commands, like Blank Check, Device ID.....

However when I go to program the device with my code, FM hangs on Erasing a Block, it will sit like this for 20+ minutes and never complete. I can see with a serial sniffer that whatever it is trying to do it keeps trying every minute (based on the timeout in the advanced options I suspect). When I try and cancel the operation, this has no affect either and the same message is transmitted to my device.

I think that there is a bug (or several) in the FM version 3.41.178 the bugs are:

1. There are 2 check boxes under Step 2, Erase all Flash & Erase Blocks used by Hex File. if both of these are unchecked, it is logical to assume that no erase will occur at all, however, when trying to progam the device in step 5, the selected block in the list box in step 2 is always attempted to be erased, there is no way in the list box to have no line selected.

2. As from my comments above, the Erase hangs, and there is no way to successfully cancel it other than closing the application. of course this leaves the device still in ISP which is the next issue. It appears that others have had this same issue at http://forum.flashmagictool.com/index.php?topic=501.0 & http://forum.flashmagictool.com/index.php?topic=563.0

3. Once the device has entered ISP mode and the auto baud has been completed, the device will no longer autobaud, (in the code in AN10337) yet FM will continue to send a "U" (0x55) to the serial port at which point the device will reply with a 0x00. and then FM will spit the dummy as it is expecting an echoed "U" back. at this point there is now no way to force a download from FM and no way to recover the device from the ISP mode. This of course happens when youo have to shut FM down from a failed erase, as it doesn't cancel the erase and never closes the comm port. The only way I can recover from this is to reflash the device using ICP (and the same code)


4. Not a bug but I thought someone may be interested in the NoTouch Code from Erik, I have added an extra section in it to set the bootvector to the ISP code, as I found that having the code as per the included examples, would not cause my device (LPC925) to enter the ISP. adding the Bootvector address made all the difference, call it a fail safe if you will. I would happily post this on 8052.com but it is down at the moment.

$NOMOD51
$include (REG922.INC)

NAME NOTOUCH925

PGM_MTP    EQU 0FF03H

?PR?no_touch925?NOTOUCH925     SEGMENT CODE
    public no_touch925
   
   ; void no_touch925(){
   
    RSEG ?PR?no_touch925?NOTOUCH925
no_touch925:
    push    IEN0            ;save EA Status
    clr     EA              ;disable int's
    mov     R0,     #0FFH   ;IAP authourisation key first
    mov     @R0,    #96H
    mov     A,      #02
    mov     R5,     #01     ;write bootstat with 01H
    mov     R7,     #03
    lcall   PGM_MTP
   
    ;mkb added boot vector for the ISP (31-Dec-2006)
    mov     R0,     #0FFH   ;IAP authorisation key first
    mov     @R0,    #96H
    mov     A,      #02
    mov     R5,     #1FH     ;write bootvec with 1FH
    mov     R7,     #02
    lcall   PGM_MTP
   
   
    pop     IEN0            ;restore EA status
    RET
   
    ;}
   
; END of no_touch925
 
  END


I am using the following kit LPC925, RC oscillator, Acqura PDS900 Emulator, Raisonance IDE, SerialMon (hhdsoftware.com) serial port sniffer) WinXP Pro with a real serial port. LPC voltages are OK @ 3.492VDC 

Any help or thoughts on this are appreciated.

Andy Ayre

Quote from: marshall on December 31, 2006, 03:08:39 AM
1. There are 2 check boxes under Step 2, Erase all Flash & Erase Blocks used by Hex File. if both of these are unchecked, it is logical to assume that no erase will occur at all, however, when trying to progam the device in step 5, the selected block in the list box in step 2 is always attempted to be erased, there is no way in the list box to have no line selected.

Click on the selected block - it will be deselected. If no blocks are selected AND both checkboxes are unchecked, then no erase will be performed. However you will get a warning from Flash Magic that you are attempting to program a hex file without first erasing.

Quote from: marshall on December 31, 2006, 03:08:39 AM
2. As from my comments above, the Erase hangs, and there is no way to successfully cancel it other than closing the application. of course this leaves the device still in ISP which is the next issue. It appears that others have had this same issue at http://forum.flashmagictool.com/index.php?topic=501.0 & http://forum.flashmagictool.com/index.php?topic=563.0

In the topics you give the problems were with 89C51Rx2 devices, which are completely different. In the first topic the cause was ripple on the power supply.

Please complete the following so I can see what is going on:

1. Start Flash Magic
2. Press F1 to enter debug mode - [Debug] appears at the top of the window
3. Go to ISP -> Erase and select a flash block
4. Perform the erase and wait for a couple of minutes into the hang.
5. Close Flash Magic (Ctrl-Alt-Del if needed)
6. Email me the debug file C:\flashmagic.fmd and then delete it

Quote from: marshall on December 31, 2006, 03:08:39 AM
3. Once the device has entered ISP mode and the auto baud has been completed, the device will no longer autobaud, (in the code in AN10337) yet FM will continue to send a "U" (0x55) to the serial port at which point the device will reply with a 0x00. and then FM will spit the dummy as it is expecting an echoed "U" back. at this point there is now no way to force a download from FM and no way to recover the device from the ISP mode. This of course happens when youo have to shut FM down from a failed erase, as it doesn't cancel the erase and never closes the comm port. The only way I can recover from this is to reflash the device using ICP (and the same code)

I'm not sure why the device won't autobaud again. What crystal frequency and baud rate are you using? Have you tried lowering the baud rate? Do you have high speed communications disabled in the Advanced Options?
I'm not sure what "spit the dummy" means... Exact error messages are more helpful if there appears to be a problem with FM.  :)

So the device cannot reenter ISP mode only after attempting to autobaud the second time, or also after a failed erase? When you forcefully close FM Windows closes the COM Port. Even if the COM port was left open that won't have an effect on the device, only on your ability to run FM (or a terminal program) again.

Andy
Embedded Systems Academy, Inc.
support at esacademy dot com

marshall

#2
Point 1 - (erasing nothing) Resolved, indeed you are correct, thanks for this.

Point 2 - (Erase Block Hangs FM) tried your suggestions, I forgot to add in my previous post that I had tried the debug option for Flash Magic as per an App note on your web site. I can put the application into debug mode, but no debug file is created. in C:\ (or anywhere else for that matter - searched for *.fmd) - the issue with erasing persists.

Point 3 - (Re-entry into ISP) My mistake, apologies here, I can get back into ISP, AFTER I reset the device and reattempt to connect. It is wierd that it drops the connection though - oh well it works.

Using internal RC oscillator at 7.373MHz, High speed comms disabled, serial hardware is true 232 with Max232 drivers etc.
"Spit the Dummy" is what your kid does when he has a tantrum - sorry for the colloquailism.
After a failed erase attempt (of block 0) , I can still access the ISP routine with a reset of the device and a restart of Flash Magic.

If erasing nothing and simply attempting to program the device, the status bar comes up "Programming..." then it always times out with a MessageBox stating Unable to communicate. (transmit/receive), after resetting the device (but not the Flash Magic application) I am again able to access the ISP routines.

Sorry it's not more descriptive, if you can let me know why the debug doesn't create a Log file, I'll have another go.

Regards Marshall

PS. Just had a thought, I am using the ISP code from the NXP AN10337 13 DEC 2004 The link is
http://www.nxp.com/acrobat_download/applicationnotes/AN10337_1.pdf

The source is
http://www.nxp.com/files/markets/microcontrollers/Adding%20ISP%20in%20source%20code.zip

I'll try it with a virign board and see what if I have the same issues, if not then we'll know that the issue is in the erase (& programming) functions of the NXP source code

Andy Ayre

OK, if you enter debug mode and then read the device signature (which I assume works) then a debug file should be generated. Please check it is. You may need to press F2 to exit debug mode or close FM before the file is written to disk. If that doesn't work then there is something weird going on with your PC.

If it does work then try the steps I gave before but this time read the device signature first before trying to erase.

Andy
Embedded Systems Academy, Inc.
support at esacademy dot com

marshall

Thanks Andy,

I have emailed you the debug file, hope that it is of some use. I haven't been able to test with the virgin boards yet (holidays here at the moment) but will let you know when I have

Regards

Marshall

Andy Ayre

Everything is going fine until this point:


tx> :03000004010000F8
debug> ReadFile - not enough or too many bytes read
debug> wanted 20 bytes, read 16 bytes
rx> :03000004010000F


FM sends the erase sector command. The device is supposed to echo back the command and then a response, however it just stops echoing. So FM tries again:


tx> :0100000303F9
debug> ReadFile - not enough or too many bytes read
debug> wanted 16 bytes, read 11 bytes
rx> f\1e\80\fe\98\98\98f\9ef\e6


This time the device replied with junk, as if the baudrate of the device had changed. From this point on the device continually returns junk for everything that FM sends to it, and it seems that this cycle continues indefinately rather than stopping after six attempts like it should. So that is a problem with FM, however the device is not responding correctly and causing the initial problem.

I'm not sure why the device would do this. Are there any glitches or ripple on the power supply? Is the supply voltage and current within the required range?

Andy
Embedded Systems Academy, Inc.
support at esacademy dot com