If you want your software to jump to the ISP why not use the IAP "Reinvoke ISP"
command.
I haven't used it myself, but I think that entering the ISP bootloader via
setting an output and using the WD reset wont work.
Simply because all registers (except RTC) are reset on a reset, that includes
the ISP entry pin.
The user manual did say something about the systemclock when using "Reinvoke
ISP".
Hope this helps.
--- In l..., "boru2600" wrote:
>
> Greetings, Community.
>
> I'm trying to get a LPC 2458 to drop into ISP mode after reset (I have
the reset working via the watchdog). I've had a look around a few
forums/websites - including NXP documentation - and this group but the examples
I've seen don't work for me. The information I have so far is mostly
from the following links:
>
> http://www.compuphase.com/lpc2100_isp.htm
>
>
http://electronics.stackexchange.com/questions/3419/is-it-possible-to-reset-nxp-lpc2100-microcontroller-from-code
>
> and the NXP documents AN10356 and UM10237, and a few posts regarding other
devices on this list.
>
> Here is my ISP mode code:
>
> // ...
> PINSEL0 = 0x00000000;
> PINSEL1 = 0x00000000;
>
> // Set P2.10 low
> FIO2SET = 0x00000400;
>
> // Power up all peripherals -- correct value?
> PCONP = 0x07FF1420;
>
> // Disconnect PLL
> PLLCON = 0x00;
> PLLFEED = 0xAA;
> PLLFEED = 0x55;
>
> // Map vectors
> MEMMAP = 0x00;
>
> // This is working fine.
> watchdog_reset_timeout(ticks);
>
> Is there something glaringly obvious that I'm missing? I realise that
P0.14 is the usual pin to set low for ISP mode on reset, but it's P2.10 on
the 2400 series. As usual, any input or insights are most welcome.
>
LPC 2458 ISP Mode from User Code
Started by ●November 22, 2012
Reply by ●November 22, 20122012-11-22
Reply by ●November 22, 20122012-11-22
--- In l..., "Kevin" wrote:
>
> If you want your software to jump to the ISP why not use the IAP "Reinvoke ISP" command.
> I haven't used it myself, but I think that entering the ISP bootloader via setting an output and using the WD reset wont work.
> Simply because all registers (except RTC) are reset on a reset, that includes the ISP entry pin.
>
> The user manual did say something about the systemclock when using "Reinvoke ISP".
>
> Hope this helps.
>
I've actually just come across this section in the manual. /facepalm
This should do what I'm looking for. I'll take a look at this and report back. Thank you for your suggestion, and thanks to Paul and Martin also for the sanity check!
Regards
>
> If you want your software to jump to the ISP why not use the IAP "Reinvoke ISP" command.
> I haven't used it myself, but I think that entering the ISP bootloader via setting an output and using the WD reset wont work.
> Simply because all registers (except RTC) are reset on a reset, that includes the ISP entry pin.
>
> The user manual did say something about the systemclock when using "Reinvoke ISP".
>
> Hope this helps.
>
I've actually just come across this section in the manual. /facepalm
This should do what I'm looking for. I'll take a look at this and report back. Thank you for your suggestion, and thanks to Paul and Martin also for the sanity check!
Regards
Reply by ●November 23, 20122012-11-23
> I've actually just come across this section in
the manual. /facepalm
>
> This should do what I'm looking for. I'll take a look at this and report back. Thank you for your suggestion, and thanks to Paul and Martin also for the sanity check!
>
> Regards
>
I've used the IAP reinvoke ISP command and had limited success; The board does indeed seem to go into ISP mode, but, when I try flashing a new firmware (using lpc21isp) onto it after it has dropped into ISP mode, it starts off at the normal speed but then slows down (one "dot" every few seconds) and then stalls entirely. Is there something I need to do prior to issuing the IAP command?
As a contingency I tried the alternative suggestion in the manual: disabling the PLL and selecting the IRC as the clock source before the IAP command but it results in the same behaviour.
Has anyone seen something like this before?
Regards.
>
> This should do what I'm looking for. I'll take a look at this and report back. Thank you for your suggestion, and thanks to Paul and Martin also for the sanity check!
>
> Regards
>
I've used the IAP reinvoke ISP command and had limited success; The board does indeed seem to go into ISP mode, but, when I try flashing a new firmware (using lpc21isp) onto it after it has dropped into ISP mode, it starts off at the normal speed but then slows down (one "dot" every few seconds) and then stalls entirely. Is there something I need to do prior to issuing the IAP command?
As a contingency I tried the alternative suggestion in the manual: disabling the PLL and selecting the IRC as the clock source before the IAP command but it results in the same behaviour.
Has anyone seen something like this before?
Regards.
Reply by ●November 23, 20122012-11-23
Hello Boru,
> I've used the IAP reinvoke ISP command
> and had limited success; The board does indeed
> seem to go into ISP mode, but, when I try flashing
> a new firmware (using lpc21isp) onto it after it has
> dropped into ISP mode, it starts off at the
> normal speed but then slows down (one "dot" every few seconds)
> and then stalls entirely.
have your tried same same with FlashMagic (on Windows and Mac OS)?
Can you add "-debug" to command line of lpc21isp
and redirect the output to a file and send it to me?
Is lpc21isp working for normal flashing?
Which OS / version are you using? Which USB <-> serial port
adapter are you using? Or built in serial port?
Which version of lpc21isp are you using?
Where have you downloaded it (yahoo lpc21isp file area,
sourceforge, somewhere else)?
Best regards,
Martin
> I've used the IAP reinvoke ISP command
> and had limited success; The board does indeed
> seem to go into ISP mode, but, when I try flashing
> a new firmware (using lpc21isp) onto it after it has
> dropped into ISP mode, it starts off at the
> normal speed but then slows down (one "dot" every few seconds)
> and then stalls entirely.
have your tried same same with FlashMagic (on Windows and Mac OS)?
Can you add "-debug" to command line of lpc21isp
and redirect the output to a file and send it to me?
Is lpc21isp working for normal flashing?
Which OS / version are you using? Which USB <-> serial port
adapter are you using? Or built in serial port?
Which version of lpc21isp are you using?
Where have you downloaded it (yahoo lpc21isp file area,
sourceforge, somewhere else)?
Best regards,
Martin
Reply by ●November 23, 20122012-11-23
> have your tried same same with FlashMagic (on Windows
and Mac OS)?
> Can you add "-debug" to command line of lpc21isp
> and redirect the output to a file and send it to me?
> Is lpc21isp working for normal flashing?
> Which OS / version are you using? Which USB <-> serial port
> adapter are you using? Or built in serial port?
> Which version of lpc21isp are you using?
> Where have you downloaded it (yahoo lpc21isp file area,
> sourceforge, somewhere else)?
>
> Best regards,
>
> Martin
>
Hi Martin,
- I haven't tried it with FlashMagic, no.
- I will send the log file to you personally as I'm unable to attach it via the mailing list portal.
- lpc21isp works just fine otherwise (i.e. manually setting the board into ISP mode and flashing)
- I'm currently using Linux with a 3.2.0-32 kernel (32 bit)
- It's a FTDI USB interface on board, so far as the PC interface goes, it's whatever LKM was loaded.
- I'm using version 1.83 of lpc21isp downloaded from sourceforge.
If I can provide any further information, please do not hesitate to ask.
Many thanks.
> Can you add "-debug" to command line of lpc21isp
> and redirect the output to a file and send it to me?
> Is lpc21isp working for normal flashing?
> Which OS / version are you using? Which USB <-> serial port
> adapter are you using? Or built in serial port?
> Which version of lpc21isp are you using?
> Where have you downloaded it (yahoo lpc21isp file area,
> sourceforge, somewhere else)?
>
> Best regards,
>
> Martin
>
Hi Martin,
- I haven't tried it with FlashMagic, no.
- I will send the log file to you personally as I'm unable to attach it via the mailing list portal.
- lpc21isp works just fine otherwise (i.e. manually setting the board into ISP mode and flashing)
- I'm currently using Linux with a 3.2.0-32 kernel (32 bit)
- It's a FTDI USB interface on board, so far as the PC interface goes, it's whatever LKM was loaded.
- I'm using version 1.83 of lpc21isp downloaded from sourceforge.
If I can provide any further information, please do not hesitate to ask.
Many thanks.
Reply by ●November 26, 20122012-11-26
> Hi Martin,
>
> - I haven't tried it with FlashMagic, no.
> - I will send the log file to you personally as I'm unable to attach it via the mailing list portal.
> - lpc21isp works just fine otherwise (i.e. manually setting the board into ISP mode and flashing)
> - I'm currently using Linux with a 3.2.0-32 kernel (32 bit)
> - It's a FTDI USB interface on board, so far as the PC interface goes, it's whatever LKM was loaded.
> - I'm using version 1.83 of lpc21isp downloaded from sourceforge.
>
> If I can provide any further information, please do not hesitate to ask.
>
> Many thanks.
>
Update: I am seeing the same behaviour with FlashMagic on a windows box. Examining the memory via FlashMagic, it would appear that the chip is "misprogramming", for want of a better word, several (but not all) bits in my hex file. I'm not sure what this suggests; I expect the issue is similar to what I'm seeing with the lpc21isp tool.
Having trawled around the web a bit, I found several mentions of people resetting the stack pointer prior to calling IAP commands. Does anyone happen to know if this is required? I don't see how it would help in this case as the board does seem to go into ISP mode. The manual I have is from 2009 and bears no mention to this. The following link in particular alludes to an error in the documentation for another board:
http://knowledgebase.nxp.com/showthread.php?t(46
Is this noteworthy or am I on a wild goose chase?
Regards
>
> - I haven't tried it with FlashMagic, no.
> - I will send the log file to you personally as I'm unable to attach it via the mailing list portal.
> - lpc21isp works just fine otherwise (i.e. manually setting the board into ISP mode and flashing)
> - I'm currently using Linux with a 3.2.0-32 kernel (32 bit)
> - It's a FTDI USB interface on board, so far as the PC interface goes, it's whatever LKM was loaded.
> - I'm using version 1.83 of lpc21isp downloaded from sourceforge.
>
> If I can provide any further information, please do not hesitate to ask.
>
> Many thanks.
>
Update: I am seeing the same behaviour with FlashMagic on a windows box. Examining the memory via FlashMagic, it would appear that the chip is "misprogramming", for want of a better word, several (but not all) bits in my hex file. I'm not sure what this suggests; I expect the issue is similar to what I'm seeing with the lpc21isp tool.
Having trawled around the web a bit, I found several mentions of people resetting the stack pointer prior to calling IAP commands. Does anyone happen to know if this is required? I don't see how it would help in this case as the board does seem to go into ISP mode. The manual I have is from 2009 and bears no mention to this. The following link in particular alludes to an error in the documentation for another board:
http://knowledgebase.nxp.com/showthread.php?t(46
Is this noteworthy or am I on a wild goose chase?
Regards
Reply by ●November 26, 20122012-11-26
Hello Conor,
> - I will send the log file to you personally
> as I'm unable to attach it via the mailing list portal.
this shows a CRC error at the end of the logfile...
> "misprogramming", for want of a better word,
> several (but not all) bits in my hex file.
Perhaps a CLK setting, a PLL which is too fast
and must be switched off?
See also chapters 5.2.7, 5.2.9 and 10 in User Manual U10237:
5.2.7 Interrupts during IAP
The on-chip Flash memory is not accessible during erase/write operations. When the user
application code starts executing the interrupt vectors from the user Flash area are active.
The user should either disable interrupts, or ensure that user interrupt vectors are active in
RAM and that the interrupt handlers reside in RAM, before making a Flash erase/write IAP
call. The IAP code does not use or disable interrupts.
...
5.2.9 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
Chapter 10:
The Flash memory is not accessible during a write or erase operation. IAP commands,
which results in a Flash write/erase operation, use 32 bytes of space in the top portion of
the on-chip RAM for execution. The user program should not be use this space if IAP
Flash programming is permitted in the application.
Best regards,
Martin
> - I will send the log file to you personally
> as I'm unable to attach it via the mailing list portal.
this shows a CRC error at the end of the logfile...
> "misprogramming", for want of a better word,
> several (but not all) bits in my hex file.
Perhaps a CLK setting, a PLL which is too fast
and must be switched off?
See also chapters 5.2.7, 5.2.9 and 10 in User Manual U10237:
5.2.7 Interrupts during IAP
The on-chip Flash memory is not accessible during erase/write operations. When the user
application code starts executing the interrupt vectors from the user Flash area are active.
The user should either disable interrupts, or ensure that user interrupt vectors are active in
RAM and that the interrupt handlers reside in RAM, before making a Flash erase/write IAP
call. The IAP code does not use or disable interrupts.
...
5.2.9 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
Chapter 10:
The Flash memory is not accessible during a write or erase operation. IAP commands,
which results in a Flash write/erase operation, use 32 bytes of space in the top portion of
the on-chip RAM for execution. The user program should not be use this space if IAP
Flash programming is permitted in the application.
Best regards,
Martin
Reply by ●November 26, 20122012-11-26
Hello Conor,
> Having trawled around the web a bit,
> I found several mentions of people resetting
> the stack pointer prior to calling IAP commands.
you are using ISP or IAP?
When mentioning ISP in the subject and
also lpc21isp/FlashMagic, i think you are using ISP.
This is something else compared to IAP.
IAP is when an application (on the embedded system)
is calling some routines to do ISP similar thing,
like erasing/preparing/writing a Flash sector.
Best regards,
Martin
> Having trawled around the web a bit,
> I found several mentions of people resetting
> the stack pointer prior to calling IAP commands.
you are using ISP or IAP?
When mentioning ISP in the subject and
also lpc21isp/FlashMagic, i think you are using ISP.
This is something else compared to IAP.
IAP is when an application (on the embedded system)
is calling some routines to do ISP similar thing,
like erasing/preparing/writing a Flash sector.
Best regards,
Martin
Reply by ●November 26, 20122012-11-26
> you are using ISP or IAP?
> When mentioning ISP in the subject and
> also lpc21isp/FlashMagic, i think you are using ISP.
> This is something else compared to IAP.
> IAP is when an application (on the embedded system)
> is calling some routines to do ISP similar thing,
> like erasing/preparing/writing a Flash sector.
>
> Best regards,
>
> Martin
>
Hi Martin,
I'm using the IAP command (57) to reinvoke the bootloader in ISP mode. This is documented in Chapter 30, table 628 in section 10.8 of the user manual (UM10237). I understand the other uses of the IAP commands you mention, but this is something different.
Regards
> When mentioning ISP in the subject and
> also lpc21isp/FlashMagic, i think you are using ISP.
> This is something else compared to IAP.
> IAP is when an application (on the embedded system)
> is calling some routines to do ISP similar thing,
> like erasing/preparing/writing a Flash sector.
>
> Best regards,
>
> Martin
>
Hi Martin,
I'm using the IAP command (57) to reinvoke the bootloader in ISP mode. This is documented in Chapter 30, table 628 in section 10.8 of the user manual (UM10237). I understand the other uses of the IAP commands you mention, but this is something different.
Regards
Reply by ●November 26, 20122012-11-26
--- In l..., "capiman26061973" wrote:
>
> Hello Conor,
>
> > - I will send the log file to you personally
> > as I'm unable to attach it via the mailing list portal.
>
> this shows a CRC error at the end of the logfile...
>
> > "misprogramming", for want of a better word,
> > several (but not all) bits in my hex file.
>
> Perhaps a CLK setting, a PLL which is too fast
> and must be switched off?
>
> See also chapters 5.2.7, 5.2.9 and 10 in User Manual U10237:
>
> 5.2.7 Interrupts during IAP
> The on-chip Flash memory is not accessible during erase/write operations. When the user
> application code starts executing the interrupt vectors from the user Flash area are active.
> The user should either disable interrupts, or ensure that user interrupt vectors are active in
> RAM and that the interrupt handlers reside in RAM, before making a Flash erase/write IAP
> call. The IAP code does not use or disable interrupts.
>
> ...
>
> 5.2.9 RAM used by IAP command handler
> Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
> usage in the user allocated stack space is 128 bytes and it grows downwards.
>
> Chapter 10:
>
> The Flash memory is not accessible during a write or erase operation. IAP commands,
> which results in a Flash write/erase operation, use 32 bytes of space in the top portion of
> the on-chip RAM for execution. The user program should not be use this space if IAP
> Flash programming is permitted in the application.
>
> Best regards,
>
> Martin
>
Hi Martin,
I've read these sections in the manual also, but I'm unsure as to how to act on them. Is it straightforward to disable interrupts? Should they just be disabled prior to the IAP call?
Thanks and regards
>
> Hello Conor,
>
> > - I will send the log file to you personally
> > as I'm unable to attach it via the mailing list portal.
>
> this shows a CRC error at the end of the logfile...
>
> > "misprogramming", for want of a better word,
> > several (but not all) bits in my hex file.
>
> Perhaps a CLK setting, a PLL which is too fast
> and must be switched off?
>
> See also chapters 5.2.7, 5.2.9 and 10 in User Manual U10237:
>
> 5.2.7 Interrupts during IAP
> The on-chip Flash memory is not accessible during erase/write operations. When the user
> application code starts executing the interrupt vectors from the user Flash area are active.
> The user should either disable interrupts, or ensure that user interrupt vectors are active in
> RAM and that the interrupt handlers reside in RAM, before making a Flash erase/write IAP
> call. The IAP code does not use or disable interrupts.
>
> ...
>
> 5.2.9 RAM used by IAP command handler
> Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
> usage in the user allocated stack space is 128 bytes and it grows downwards.
>
> Chapter 10:
>
> The Flash memory is not accessible during a write or erase operation. IAP commands,
> which results in a Flash write/erase operation, use 32 bytes of space in the top portion of
> the on-chip RAM for execution. The user program should not be use this space if IAP
> Flash programming is permitted in the application.
>
> Best regards,
>
> Martin
>
Hi Martin,
I've read these sections in the manual also, but I'm unsure as to how to act on them. Is it straightforward to disable interrupts? Should they just be disabled prior to the IAP call?
Thanks and regards
