I just thought I'd close the loop on this, in the event someone finds this thread and is trying to do the same thing. I managed to get the IAP command to reinvoke ISP mode from user code to work.

Here's my function:

void iap_cmd_reinvoke_isp(void) {
// Ensure fast I/O is supported.
SCS |= 1;

// Disconnect PLL.
PLLCON = 0x00;
PLLFEED = 0xAA;
PLLFEED = 0x55;

// Set IRC as the clock source.
CLKSRCSEL = 0x00;
// CCLK divider = 0 (CCLK = 4MHz)
CCLKCFG = 0x00;

__asm("ldr r0, =spval\n\t" /* Set the stack pointer */
"ldr sp, [r0]\n\t" /* to the end of (SRAM - 32) */
"ldr r0, =iapcommand\n\t" /* Enter ISP mode (via IAP) */
"ldr r2, =iapentry\n\t"
"ldr r2, [r2]\n\t"
"bx r2\n\n"
"spval: .word 0x40007FE0\n\t" /* SRAM - 32 */
"iapentry: .word 0x7FFFFFF1\n\t" /* Address of IAP function (Thumb) */
"iapcommand: .word 57"); /* IAP command 57 (Reinvoke ISP) */
}

Thanks again for all the input, guys.

An Engineer's Guide to the LPC2100 Series

Driving P2.10 low means you have to clear the bit.
// Set P2.10 low
FIO2SET = 0x00000400;

Here you are setting the bit ?? or am I missing something ??Don't know about this microcontroller.

Lekha

--- In l..., "boru2600" wrote:
>
> --- In l..., "capiman26061973" wrote:
> >
> >
> >
> > Hello Boru,
> >
> > > Is driving P2.10 low and jumping to address zero enough?
> > > I expect I'm missing something here...
> >
> > i never have tried this way, as you suggested, but in my opinion
> > during a reset all registers are reset to an initial value.
> > (All ?) outputs get inputs. So after you reset the chip,
> > P2.10 is not more an output and is not more driven low anymore.
> > This means you are not entering the bootloader...
> >
> > Best regards,
> >
> > Martin
> > Hi Martin,
>
> I would expect the same after a _hard_ reset, but jumping to address zero isn't really a reset, per se. Basically, the behaviour should be that the bootloader should check P2.10 and, if it is set low, enter ISP mode, or such is my understanding based on what I've read. I'm obviously doing something wrong here, and if my assumptions are incorrect, I would appreciate if someone would correct them. Is there a possibility that this behaviour is only expected after a hard reset?
>
> Regards
>

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

From what I recall, the IAP interface *used* to use programmed delays to
allow for flash programming to complete which required that you provide the
CPU operating frequency. Perhaps this is still relevant. Sounds like the
CPU operating frequency is too fast, if the programmed delays are still in
there, such that the loop ends too quickly and the device isn't cooked
enough (just like my daughter's baked cheesecake yesterday).

There was somebody in this group that took apart the boot loader and found a
number of interesting things, and much heat was generated regarding exactly
what was found on LPC2100-series devices.

http://tech.groups.yahoo.com/group/lpc2000/message/15799

> 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=2846
>
> Is this noteworthy or am I on a wild goose chase?

The stack pointer needs to be kept out of the region of memory that ISP uses
as its workspace. And avoid that memory for everything else yourself... I
believe this is documented in the IAP part of the manual.

Regards,

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com

> I do hope the cheesecake was a success, eventually!

Complete write off.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com

--- In l..., "Paul Curtis" wrote:
>
> > > 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.
>
> From what I recall, the IAP interface *used* to use programmed delays to
> allow for flash programming to complete which required that you provide the
> CPU operating frequency. Perhaps this is still relevant. Sounds like the
> CPU operating frequency is too fast, if the programmed delays are still in
> there, such that the loop ends too quickly and the device isn't cooked
> enough (just like my daughter's baked cheesecake yesterday).
>
> There was somebody in this group that took apart the boot loader and found a
> number of interesting things, and much heat was generated regarding exactly
> what was found on LPC2100-series devices.
>
> http://tech.groups.yahoo.com/group/lpc2000/message/15799
>
> > 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=2846
> >
> > Is this noteworthy or am I on a wild goose chase?
>
> The stack pointer needs to be kept out of the region of memory that ISP uses
> as its workspace. And avoid that memory for everything else yourself... I
> believe this is documented in the IAP part of the manual.
>
> Regards,
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore Development Platform http://www.soldercore.com
>

I'll take a look at my clock settings, and reread this part of the manual again. I'm not writing anything into RAM, so I think I'm safe enough in that regard. I'm otherwise at a bit of a loss as to explain this.

I do hope the cheesecake was a success, eventually!

Regards

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

> 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

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

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