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

Start a New Thread

> 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

Start a New Thread

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

Start a New Thread

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
>

Start a New Thread

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.

Start a New Thread