EmbeddedRelated.com
Forums

LPC 2458 ISP Mode from User Code

Started by boru2600 November 22, 2012
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.

An Engineer's Guide to the LPC2100 Series

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

If you are waiting for the watchdog to fire and reset your device, and for
that to trigger ISP entry, I believe this will be unsuccessful. If the WDT
triggers *and* there is valid user code, ISP will never be entered, it will
bypass the ISP checks and go directly to user code to handle the watchdog
timeout.

The way to enter ISP is call ISP directly after mapping the ROM back in and
calling location 0.

So, replace this:

> // This is working fine.
> watchdog_reset_timeout(ticks);

With a call to:

void and_reset(void)
{
void (*reset_vector)(void) = 0;
reset_vector();
}

You seem to be doing most of what is required, but section 3 of this shows
you the way forward:

http://www.nxp.com/documents/application_note/AN10356.pdf

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

> > If you are waiting for the watchdog to fire and reset your device, and
> > for that to trigger ISP entry, I believe this will be unsuccessful.
> > If the WDT triggers *and* there is valid user code, ISP will never be
> > entered, it will bypass the ISP checks and go directly to user code to
> > handle the watchdog timeout.
> >
> > The way to enter ISP is call ISP directly after mapping the ROM back
> > in and calling location 0.
> >
> > So, replace this:
> >
> > > // This is working fine.
> > > watchdog_reset_timeout(ticks);
> >
> > With a call to:
> >
> > void and_reset(void)
> > {
> > void (*reset_vector)(void) = 0;
> > reset_vector();
> > }
> >
> > You seem to be doing most of what is required, but section 3 of this
> > shows you the way forward:
> >
> > http://www.nxp.com/documents/application_note/AN10356.pdf
> >
> > --
> > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> > SolderCore Development Platform http://www.soldercore.com
> >
>
> Hi Paul,
>
> Thank you for your reply. I'm not sure if removing the call to set up the
> watchdog timer is the solution. I need a mechanism for leaving ISP mode
> after flashing. I understand what you mean regarding the jump to address
> zero - I had tried this but to no end.
>
> > > // Set P2.10 low
> > > FIO2SET = 0x00000400;
>
> This should be key; If P2.10 is driven low after jumping to address zero,
> it should enter ISP mode or am I grossly mistaken?

Well, if you're using ISP, and you want to reset the device, you can do this
by writing a small program into the internal RAM of the LPC2400 and using an
ISP command to execute it and cause a reset. Surely this is more preferable
than setting up the watchdog?

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

> Well, if you're using ISP, and you want to reset the device, you can do
> this by writing a small program into the internal RAM of the LPC2400 and
> using an ISP command to execute it and cause a reset. Surely this is more
> preferable than setting up the watchdog?

To clarify: you'd use the Write to RAM ISP command to write the program to
internal RAM and then use the Go ISP command to execute it to cause a reset.

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

> To clarify: you'd use the Write to RAM ISP command to write the program to
> internal RAM and then use the Go ISP command to execute it to cause a reset.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore Development Platform http://www.soldercore.com
>

(Sorry for the double post)

That would solve the reset issue, indeed -- and be a more elegant solution than guesstimating the timeout value for the watchdog. However, I'm still having an issue entering ISP mode in the meantime.

Is driving P2.10 low and jumping to address zero enough? I expect I'm missing something here...

> If you are waiting for the watchdog to fire and reset your device, and for
> that to trigger ISP entry, I believe this will be unsuccessful. If the WDT
> triggers *and* there is valid user code, ISP will never be entered, it will
> bypass the ISP checks and go directly to user code to handle the watchdog
> timeout.
>
> The way to enter ISP is call ISP directly after mapping the ROM back in and
> calling location 0.
>
> So, replace this:
>
> > // This is working fine.
> > watchdog_reset_timeout(ticks);
>
> With a call to:
>
> void and_reset(void)
> {
> void (*reset_vector)(void) = 0;
> reset_vector();
> }
>
> You seem to be doing most of what is required, but section 3 of this shows
> you the way forward:
>
> http://www.nxp.com/documents/application_note/AN10356.pdf
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore Development Platform http://www.soldercore.com
>

Hi Paul,

Thank you for your reply. I'm not sure if removing the call to set up the watchdog timer is the solution. I need a mechanism for leaving ISP mode after flashing. I understand what you mean regarding the jump to address zero - I had tried this but to no end.

> > // Set P2.10 low
> > FIO2SET = 0x00000400;

This should be key; If P2.10 is driven low after jumping to address zero, it should enter ISP mode or am I grossly mistaken?

--- In l..., "Paul Curtis" 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?
>
> If you are waiting for the watchdog to fire and reset your device, and for
> that to trigger ISP entry, I believe this will be unsuccessful. If the WDT
> triggers *and* there is valid user code, ISP will never be entered, it will
> bypass the ISP checks and go directly to user code to handle the watchdog
> timeout.
>
> The way to enter ISP is call ISP directly after mapping the ROM back in and
> calling location 0.
>
> So, replace this:
>
> > // This is working fine.
> > watchdog_reset_timeout(ticks);
>
> With a call to:
>
> void and_reset(void)
> {
> void (*reset_vector)(void) = 0;
> reset_vector();
> }
>
> You seem to be doing most of what is required, but section 3 of this shows
> you the way forward:
>
> http://www.nxp.com/documents/application_note/AN10356.pdf
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore Development Platform http://www.soldercore.com
>

Hi Paul,

Thank you for the response. I'm not sure replacing the call to setting the watchdog timer will work. I need to do this to get back out of ISP mode. I did try the jump to address zero, but this hasn't been successful.

> > // Set P2.10 low
> > FIO2SET = 0x00000400;

This should be key; If P2.10 is driven low at reset, it should enter ISP mode, or am I grossly mistaken?

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

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

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

ah, yes, i agree. But at address 0, is there really the bootloader?
How was it in non-Cortex-Mx architecture? Too long ago.
There is a jump at location 0 to your startup?
Look into your map and list files.

Bootloader is somewhere in ROM, at a different address.
(i can't remember, something like 0xFFFF0000 or so,
perhaps mapable to 0???).

Best regards,

Martin