Hi All,

I have used IAP previously on LPC2000 family. I have an interesting issue with using IAP on the LPC1788. I know its relatively new just wondering has anyone else has had similar issues..

I trying to implement a firmware upgrade utility. I am using an RTOS with multiple tasks. At the current point I am just concerned with erasing and reprogramming a block of the internal flash running from the one of the tasks.

I use the intrinsic function __disable_irq(); to disable all interrupts before starting IAP application. The processor is in Privileged mode and the PRIMASK reg is set before I start the IAP.

The IAP application operates fine until I have a serial application task running which is communicating on UART1 or UART2 prior to the jump. What I *think* is the issue, is a pending interrupt on one of the UARTs, prior to disabling interrupts and jump to my IAP application; Then the IAP app fails.

The fail condition results as IAP_EraseSectors() procedure always returns busy; Even though the IAP_PrepareSectors() works...

I dont think a pending interrupt should affect IAP if interrupts are disabled. So I am not convinced.. there must be some other explaination. I would like to get the IAP code. Has anyone ever got this from NXP?

I can work around the issue by suspending the application task from running before I do the jump. But I am concerned that something else may cause a similar condition.

Any advice would be appreciated.

Best regards,

Eoin Dowling

Start a New Thread

I use FreeRTOS on an LPC2106, and the IAP functions for one-sector-at-a-time erase/write. Interrupts disabled before calling. No issues.
Hi All,
>
>I have used IAP previously on LPC2000 family. I have an interesting issue with using IAP on the LPC1788. I know its relatively new just wondering has anyone else has had similar issues..
>
>I trying to implement a firmware upgrade utility. I am using an RTOS with multiple tasks. At the current point I am just concerned with erasing and reprogramming a block of the internal flash running from the one of the tasks.
>
>I use the intrinsic function __disable_irq(); to disable all interrupts before starting IAP application. The processor is in Privileged mode and the PRIMASK reg is set before I start the IAP.
>
>The IAP application operates fine until I have a serial application task running which is communicating on UART1 or UART2 prior to the jump. What I *think* is the issue, is a pending interrupt on one of the UARTs, prior to disabling interrupts and jump to my IAP application; Then the IAP app fails.
>
>The fail condition results as IAP_EraseSectors() procedure always returns busy; Even though the IAP_PrepareSectors() works...
>
>I dont think a pending interrupt should affect IAP if interrupts are disabled. So I am not convinced.. there must be some other explaination. I would like to get the IAP code. Has anyone ever got this from NXP?
>
>I can work around the issue by suspending the application task from running before I do the jump. But I am concerned that something else may cause a similar condition.
>
>Any advice would be appreciated.
>
>Best regards,
>
>Eoin Dowling
>
>
Start a New Thread

Hi Eoin

Did you make any progress on this? I have just started using the LPC1788 (IAR LPC1788 board with SDRAM and TFT) and have big problems with the IAP.

There are a lot of differences between the LPC1768 (which I have used quite a lot) and the LPC1788 and I worked through these to get the board working with the TFT display, UART and Ethernet with TCP/IP stack. Then I tried saving web pages to the file system in internal Flash and it crashed. Debugging showed that the IAP routine to write the first block of data to the Flash (at address 0x20000 to be precise, which is blank) was being entered as normal (with interrupts disabled) but it was failing and the hard fault was being hit.

With the debugger I could step into the IAP code (starting at 0x1fff1ff1) but the debugger had problems with this - it shows the instructions - which look reasonable - but it seems to be doing something that is not exactly according to the disassembled instructions; however it does look to be basically working since I can see it loading the IAP command to a register and calling its own sub-routines with the stack pointer being changed and stack being used. After stepping for maybe 20..30 instruction steps (although I think that sub-routine calls may have been taken without these being correctly counted) it hits the hard fault.

What is stange is that I use the identical code in various NXP projects on the LPC2103, LPC2016, PC2148, LPC2368, LPC2478 and LPC1768 without any problems (on the older LPC2xxx for several years and the newer LPC1768 also for around 2 years now). The user's manual doesn't point to any differences in its use and the errate to the chip doesn't mention anything. The CPU is operating at 120MHz but all Flash wait states etc. are set up correctly and the LPC1788 board otherwise runs for hours without any problems.

I stepped very carefully into the IAP in assember and monitored the the stack content and the passed values [0x32 (50 dec) for the "prepare for write" command, followed by the sector start and end numbers (both 0x12 - or 18 hex, corresponding to the address 0x20000)]. All is exactly as expected so I can't explain why the IAP should effectively crash.

This is not the same problem as you have reported but I am wondering whether maybe the IAP code in the boot area is corrupted for it to fail like this...?

However I then had a surprise. I built the program with a different compiler/debugger and I found that it worked. I could also step well in the IAP disassember code, but when I studied the assember code I didn't see any real difference to the other one. What I did notice is that the IAP code was starting at address 0x1fff1ff0 whereby the other debuggger was showing the code to start at 0x1fff1ff4 (shifted by 4 bytes but still it seemed to jump into the code).

So loaded the code from the other IDE and tested the board again (without debugging - made a power cycle to be sure) and the file system was working (!!!???). I connected the debugger and the IAP code looked good (starting at the correct location), so I put a break point and tried stepping into it again. As soon as the file system code hit the break point and started stepping the IAP code was again shifted by 4 bytes to 0x1fff1ff4 and the IAP call crashed...

What I slowley worked out was the following:
- If I loaded the code and kept the debugger connected the IAP would always crash.
- If I loaded the code and removed the debugger (power cycle) all worked perfectly.
- As soon as I connected the debugger again (physically connected was no problem but connected to the IDE was fatal) the IAP calls would fail.
- The other IDE didn't have this problem on its own, but, when the 'interfering IDE' was used and then the IDE swapped without power cycling the same effect was observed - that is, the IAP would again fail.

So the conclusion is - without debugger everything is working well.
With certain debugger IAP can not be used.

This is new - never had the effect before - but at least the effect is clear and it can be worked around.

Regards

Mark

P.S. If you put a break point at the IAP call 0x1fff1ff0 you will be able to step into the code and also do a disassemble of it. Thsi is not as good as C-source code but may help you understand your problem if you don't mind exploring disassembled code for a few hours...

--- In l..., "dowlingeoin" wrote:
>
> Hi All,
>
> I have used IAP previously on LPC2000 family. I have an interesting issue with using IAP on the LPC1788. I know its relatively new just wondering has anyone else has had similar issues..
>
> I trying to implement a firmware upgrade utility. I am using an RTOS with multiple tasks. At the current point I am just concerned with erasing and reprogramming a block of the internal flash running from the one of the tasks.
>
> I use the intrinsic function __disable_irq(); to disable all interrupts before starting IAP application. The processor is in Privileged mode and the PRIMASK reg is set before I start the IAP.
>
>
> The IAP application operates fine until I have a serial application task running which is communicating on UART1 or UART2 prior to the jump. What I *think* is the issue, is a pending interrupt on one of the UARTs, prior to disabling interrupts and jump to my IAP application; Then the IAP app fails.
>
> The fail condition results as IAP_EraseSectors() procedure always returns busy; Even though the IAP_PrepareSectors() works...
>
> I dont think a pending interrupt should affect IAP if interrupts are disabled. So I am not convinced.. there must be some other explaination. I would like to get the IAP code. Has anyone ever got this from NXP?
>
> I can work around the issue by suspending the application task from running before I do the jump. But I am concerned that something else may cause a similar condition.
>
> Any advice would be appreciated.
>
> Best regards,
>
> Eoin Dowling
>

Start a New Thread

I've seen this sort of problem sometimes with the Keil debugger, caused by
the debugger performing background accesses to update the display whilst the
CPU is running.

In Keil it's an option to have periodic updates when the CPU is running, and
also there may be accesses if semi-hosting is enabled, it's under View -
Periodic Window Update.

Disabling these feature generally solves this problem, i.e. build without
semi-hosting and stop periodic window updates.

Regards

Phil.

From: l... [mailto:l...] On Behalf Of
Mark
Sent: 22 November 2011 01:33
To: l...
Subject: [lpc2000] Re: LPC1788 - IAP Issue- IAP_EraseSectors returns busy

Hi Eoin

Did you make any progress on this? I have just started using the LPC1788
(IAR LPC1788 board with SDRAM and TFT) and have big problems with the IAP.

There are a lot of differences between the LPC1768 (which I have used quite
a lot) and the LPC1788 and I worked through these to get the board working
with the TFT display, UART and Ethernet with TCP/IP stack. Then I tried
saving web pages to the file system in internal Flash and it crashed.
Debugging showed that the IAP routine to write the first block of data to
the Flash (at address 0x20000 to be precise, which is blank) was being
entered as normal (with interrupts disabled) but it was failing and the hard
fault was being hit.

With the debugger I could step into the IAP code (starting at 0x1fff1ff1)
but the debugger had problems with this - it shows the instructions - which
look reasonable - but it seems to be doing something that is not exactly
according to the disassembled instructions; however it does look to be
basically working since I can see it loading the IAP command to a register
and calling its own sub-routines with the stack pointer being changed and
stack being used. After stepping for maybe 20..30 instruction steps
(although I think that sub-routine calls may have been taken without these
being correctly counted) it hits the hard fault.

What is stange is that I use the identical code in various NXP projects on
the LPC2103, LPC2016, PC2148, LPC2368, LPC2478 and LPC1768 without any
problems (on the older LPC2xxx for several years and the newer LPC1768 also
for around 2 years now). The user's manual doesn't point to any differences
in its use and the errate to the chip doesn't mention anything. The CPU is
operating at 120MHz but all Flash wait states etc. are set up correctly and
the LPC1788 board otherwise runs for hours without any problems.

I stepped very carefully into the IAP in assember and monitored the the
stack content and the passed values [0x32 (50 dec) for the "prepare for
write" command, followed by the sector start and end numbers (both 0x12 - or
18 hex, corresponding to the address 0x20000)]. All is exactly as expected
so I can't explain why the IAP should effectively crash.

This is not the same problem as you have reported but I am wondering whether
maybe the IAP code in the boot area is corrupted for it to fail like
this...?

However I then had a surprise. I built the program with a different
compiler/debugger and I found that it worked. I could also step well in the
IAP disassember code, but when I studied the assember code I didn't see any
real difference to the other one. What I did notice is that the IAP code was
starting at address 0x1fff1ff0 whereby the other debuggger was showing the
code to start at 0x1fff1ff4 (shifted by 4 bytes but still it seemed to jump
into the code).

So loaded the code from the other IDE and tested the board again (without
debugging - made a power cycle to be sure) and the file system was working
(!!!???). I connected the debugger and the IAP code looked good (starting at
the correct location), so I put a break point and tried stepping into it
again. As soon as the file system code hit the break point and started
stepping the IAP code was again shifted by 4 bytes to 0x1fff1ff4 and the IAP
call crashed...

What I slowley worked out was the following:
- If I loaded the code and kept the debugger connected the IAP would always
crash.
- If I loaded the code and removed the debugger (power cycle) all worked
perfectly.
- As soon as I connected the debugger again (physically connected was no
problem but connected to the IDE was fatal) the IAP calls would fail.
- The other IDE didn't have this problem on its own, but, when the
'interfering IDE' was used and then the IDE swapped without power cycling
the same effect was observed - that is, the IAP would again fail.

So the conclusion is - without debugger everything is working well.
With certain debugger IAP can not be used.

This is new - never had the effect before - but at least the effect is clear
and it can be worked around.

Regards

Mark

P.S. If you put a break point at the IAP call 0x1fff1ff0 you will be able to
step into the code and also do a disassemble of it. Thsi is not as good as
C-source code but may help you understand your problem if you don't mind
exploring disassembled code for a few hours...

--- In l... ,
"dowlingeoin" wrote:
>
> Hi All,
>
> I have used IAP previously on LPC2000 family. I have an interesting issue
with using IAP on the LPC1788. I know its relatively new just wondering has
anyone else has had similar issues..
>
> I trying to implement a firmware upgrade utility. I am using an RTOS with
multiple tasks. At the current point I am just concerned with erasing and
reprogramming a block of the internal flash running from the one of the
tasks.
>
> I use the intrinsic function __disable_irq(); to disable all interrupts
before starting IAP application. The processor is in Privileged mode and the
PRIMASK reg is set before I start the IAP.
> The IAP application operates fine until I have a serial application task
running which is communicating on UART1 or UART2 prior to the jump. What I
*think* is the issue, is a pending interrupt on one of the UARTs, prior to
disabling interrupts and jump to my IAP application; Then the IAP app fails.

>
> The fail condition results as IAP_EraseSectors() procedure always returns
busy; Even though the IAP_PrepareSectors() works...
>
> I dont think a pending interrupt should affect IAP if interrupts are
disabled. So I am not convinced.. there must be some other explaination. I
would like to get the IAP code. Has anyone ever got this from NXP?
>
> I can work around the issue by suspending the application task from
running before I do the jump. But I am concerned that something else may
cause a similar condition.
>
> Any advice would be appreciated.
>
> Best regards,
>
> Eoin Dowling
>



Start a New Thread

I just finished up my bootloader using the Keil tools. I have periodic
updates turned on and did lots of debugging with no problems. The only
times I had problems were because of bugs in my code. I can step through
all my flashing routines, even the ones that get relocated to ram, just
fine.

On Tue, Nov 22, 2011 at 12:33 AM, Phil Young wrote:

> **
> I've seen this sort of problem sometimes with the Keil debugger, caused by
> the debugger performing background accesses to update the display whilst
> the
> CPU is running.
>
> In Keil it's an option to have periodic updates when the CPU is running,
> and
> also there may be accesses if semi-hosting is enabled, it's under View -
> Periodic Window Update.
>
> Disabling these feature generally solves this problem, i.e. build without
> semi-hosting and stop periodic window updates.
>
> Regards
>
> Phil.
>
> From: l... [mailto:l...] On Behalf
> Of
> Mark
> Sent: 22 November 2011 01:33
> To: l...
> Subject: [lpc2000] Re: LPC1788 - IAP Issue- IAP_EraseSectors returns busy
> Hi Eoin
>
> Did you make any progress on this? I have just started using the LPC1788
> (IAR LPC1788 board with SDRAM and TFT) and have big problems with the IAP.
>
> There are a lot of differences between the LPC1768 (which I have used quite
> a lot) and the LPC1788 and I worked through these to get the board working
> with the TFT display, UART and Ethernet with TCP/IP stack. Then I tried
> saving web pages to the file system in internal Flash and it crashed.
> Debugging showed that the IAP routine to write the first block of data to
> the Flash (at address 0x20000 to be precise, which is blank) was being
> entered as normal (with interrupts disabled) but it was failing and the
> hard
> fault was being hit.
>
> With the debugger I could step into the IAP code (starting at 0x1fff1ff1)
> but the debugger had problems with this - it shows the instructions - which
> look reasonable - but it seems to be doing something that is not exactly
> according to the disassembled instructions; however it does look to be
> basically working since I can see it loading the IAP command to a register
> and calling its own sub-routines with the stack pointer being changed and
> stack being used. After stepping for maybe 20..30 instruction steps
> (although I think that sub-routine calls may have been taken without these
> being correctly counted) it hits the hard fault.
>
> What is stange is that I use the identical code in various NXP projects on
> the LPC2103, LPC2016, PC2148, LPC2368, LPC2478 and LPC1768 without any
> problems (on the older LPC2xxx for several years and the newer LPC1768 also
> for around 2 years now). The user's manual doesn't point to any differences
> in its use and the errate to the chip doesn't mention anything. The CPU is
> operating at 120MHz but all Flash wait states etc. are set up correctly and
> the LPC1788 board otherwise runs for hours without any problems.
>
> I stepped very carefully into the IAP in assember and monitored the the
> stack content and the passed values [0x32 (50 dec) for the "prepare for
> write" command, followed by the sector start and end numbers (both 0x12 -
> or
> 18 hex, corresponding to the address 0x20000)]. All is exactly as expected
> so I can't explain why the IAP should effectively crash.
>
> This is not the same problem as you have reported but I am wondering
> whether
> maybe the IAP code in the boot area is corrupted for it to fail like
> this...?
>
> However I then had a surprise. I built the program with a different
> compiler/debugger and I found that it worked. I could also step well in the
> IAP disassember code, but when I studied the assember code I didn't see any
> real difference to the other one. What I did notice is that the IAP code
> was
> starting at address 0x1fff1ff0 whereby the other debuggger was showing the
> code to start at 0x1fff1ff4 (shifted by 4 bytes but still it seemed to jump
> into the code).
>
> So loaded the code from the other IDE and tested the board again (without
> debugging - made a power cycle to be sure) and the file system was working
> (!!!???). I connected the debugger and the IAP code looked good (starting
> at
> the correct location), so I put a break point and tried stepping into it
> again. As soon as the file system code hit the break point and started
> stepping the IAP code was again shifted by 4 bytes to 0x1fff1ff4 and the
> IAP
> call crashed...
>
> What I slowley worked out was the following:
> - If I loaded the code and kept the debugger connected the IAP would always
> crash.
> - If I loaded the code and removed the debugger (power cycle) all worked
> perfectly.
> - As soon as I connected the debugger again (physically connected was no
> problem but connected to the IDE was fatal) the IAP calls would fail.
> - The other IDE didn't have this problem on its own, but, when the
> 'interfering IDE' was used and then the IDE swapped without power cycling
> the same effect was observed - that is, the IAP would again fail.
>
> So the conclusion is - without debugger everything is working well.
> With certain debugger IAP can not be used.
>
> This is new - never had the effect before - but at least the effect is
> clear
> and it can be worked around.
>
> Regards
>
> Mark
>
> P.S. If you put a break point at the IAP call 0x1fff1ff0 you will be able
> to
> step into the code and also do a disassemble of it. Thsi is not as good as
> C-source code but may help you understand your problem if you don't mind
> exploring disassembled code for a few hours...
>
> --- In l... ,
>
> "dowlingeoin" wrote:
> >
> > Hi All,
> >
> > I have used IAP previously on LPC2000 family. I have an interesting issue
> with using IAP on the LPC1788. I know its relatively new just wondering has
> anyone else has had similar issues..
> >
> > I trying to implement a firmware upgrade utility. I am using an RTOS with
> multiple tasks. At the current point I am just concerned with erasing and
> reprogramming a block of the internal flash running from the one of the
> tasks.
> >
> > I use the intrinsic function __disable_irq(); to disable all interrupts
> before starting IAP application. The processor is in Privileged mode and
> the
> PRIMASK reg is set before I start the IAP.
> >
> >
> > The IAP application operates fine until I have a serial application task
> running which is communicating on UART1 or UART2 prior to the jump. What I
> *think* is the issue, is a pending interrupt on one of the UARTs, prior to
> disabling interrupts and jump to my IAP application; Then the IAP app
> fails.
>
> >
> > The fail condition results as IAP_EraseSectors() procedure always returns
> busy; Even though the IAP_PrepareSectors() works...
> >
> > I dont think a pending interrupt should affect IAP if interrupts are
> disabled. So I am not convinced.. there must be some other explaination. I
> would like to get the IAP code. Has anyone ever got this from NXP?
> >
> > I can work around the issue by suspending the application task from
> running before I do the jump. But I am concerned that something else may
> cause a similar condition.
> >
> > Any advice would be appreciated.
> >
> > Best regards,
> >
> > Eoin Dowling
> >
>
>
>


Start a New Thread

It depends on what you have displayed in the peripherals, watch, and memory
windows.

When it caused me the biggest problem was with a memory window that was not
actually visible but was being refreshed.
In this case the memory window update was stealing too many cycles and
causing an ISR to overrun.

In another case I had a local pointer to a UART on LPC1768, this was
expanded in the watch window so it was reading the UART data register, as a
result I was missing occasional characters.

The bottom line is that the behaviour is dependent on what you are doing at
the time, but it is something that people need to consider.

Debugger accesses steal bus cycles and can have side effects that are not
immediately obvious.

This is not just with the ARM, I've seen this on many different processors
over the years.

Regards

Phil.

-----Original Message-----
From: l... [mailto:l...] On Behalf Of
Frank
Sent: 22 November 2011 14:50
To: l...
Subject: Re: [lpc2000] Re: LPC1788 - IAP Issue- IAP_EraseSectors returns
busy

I just finished up my bootloader using the Keil tools. I have periodic
updates turned on and did lots of debugging with no problems. The only
times I had problems were because of bugs in my code. I can step through
all my flashing routines, even the ones that get relocated to ram, just
fine.

On Tue, Nov 22, 2011 at 12:33 AM, Phil Young
wrote:

> **
> I've seen this sort of problem sometimes with the Keil debugger, caused by
> the debugger performing background accesses to update the display whilst
> the
> CPU is running.
>
> In Keil it's an option to have periodic updates when the CPU is running,
> and
> also there may be accesses if semi-hosting is enabled, it's under View -
> Periodic Window Update.
>
> Disabling these feature generally solves this problem, i.e. build without
> semi-hosting and stop periodic window updates.
>
> Regards
>
> Phil.
>
> From: l... [mailto:l...] On Behalf
> Of
> Mark
> Sent: 22 November 2011 01:33
> To: l...
> Subject: [lpc2000] Re: LPC1788 - IAP Issue- IAP_EraseSectors returns busy
> Hi Eoin
>
> Did you make any progress on this? I have just started using the LPC1788
> (IAR LPC1788 board with SDRAM and TFT) and have big problems with the IAP.
>
> There are a lot of differences between the LPC1768 (which I have used
quite
> a lot) and the LPC1788 and I worked through these to get the board working
> with the TFT display, UART and Ethernet with TCP/IP stack. Then I tried
> saving web pages to the file system in internal Flash and it crashed.
> Debugging showed that the IAP routine to write the first block of data to
> the Flash (at address 0x20000 to be precise, which is blank) was being
> entered as normal (with interrupts disabled) but it was failing and the
> hard
> fault was being hit.
>
> With the debugger I could step into the IAP code (starting at 0x1fff1ff1)
> but the debugger had problems with this - it shows the instructions -
which
> look reasonable - but it seems to be doing something that is not exactly
> according to the disassembled instructions; however it does look to be
> basically working since I can see it loading the IAP command to a register
> and calling its own sub-routines with the stack pointer being changed and
> stack being used. After stepping for maybe 20..30 instruction steps
> (although I think that sub-routine calls may have been taken without these
> being correctly counted) it hits the hard fault.
>
> What is stange is that I use the identical code in various NXP projects on
> the LPC2103, LPC2016, PC2148, LPC2368, LPC2478 and LPC1768 without any
> problems (on the older LPC2xxx for several years and the newer LPC1768
also
> for around 2 years now). The user's manual doesn't point to any
differences
> in its use and the errate to the chip doesn't mention anything. The CPU is
> operating at 120MHz but all Flash wait states etc. are set up correctly
and
> the LPC1788 board otherwise runs for hours without any problems.
>
> I stepped very carefully into the IAP in assember and monitored the the
> stack content and the passed values [0x32 (50 dec) for the "prepare for
> write" command, followed by the sector start and end numbers (both 0x12 -
> or
> 18 hex, corresponding to the address 0x20000)]. All is exactly as expected
> so I can't explain why the IAP should effectively crash.
>
> This is not the same problem as you have reported but I am wondering
> whether
> maybe the IAP code in the boot area is corrupted for it to fail like
> this...?
>
> However I then had a surprise. I built the program with a different
> compiler/debugger and I found that it worked. I could also step well in
the
> IAP disassember code, but when I studied the assember code I didn't see
any
> real difference to the other one. What I did notice is that the IAP code
> was
> starting at address 0x1fff1ff0 whereby the other debuggger was showing the
> code to start at 0x1fff1ff4 (shifted by 4 bytes but still it seemed to
jump
> into the code).
>
> So loaded the code from the other IDE and tested the board again (without
> debugging - made a power cycle to be sure) and the file system was working
> (!!!???). I connected the debugger and the IAP code looked good (starting
> at
> the correct location), so I put a break point and tried stepping into it
> again. As soon as the file system code hit the break point and started
> stepping the IAP code was again shifted by 4 bytes to 0x1fff1ff4 and the
> IAP
> call crashed...
>
> What I slowley worked out was the following:
> - If I loaded the code and kept the debugger connected the IAP would
always
> crash.
> - If I loaded the code and removed the debugger (power cycle) all worked
> perfectly.
> - As soon as I connected the debugger again (physically connected was no
> problem but connected to the IDE was fatal) the IAP calls would fail.
> - The other IDE didn't have this problem on its own, but, when the
> 'interfering IDE' was used and then the IDE swapped without power cycling
> the same effect was observed - that is, the IAP would again fail.
>
> So the conclusion is - without debugger everything is working well.
> With certain debugger IAP can not be used.
>
> This is new - never had the effect before - but at least the effect is
> clear
> and it can be worked around.
>
> Regards
>
> Mark
>
> P.S. If you put a break point at the IAP call 0x1fff1ff0 you will be able
> to
> step into the code and also do a disassemble of it. Thsi is not as good as
> C-source code but may help you understand your problem if you don't mind
> exploring disassembled code for a few hours...
>
> --- In l... ,
>
> "dowlingeoin" wrote:
> >
> > Hi All,
> >
> > I have used IAP previously on LPC2000 family. I have an interesting
issue
> with using IAP on the LPC1788. I know its relatively new just wondering
has
> anyone else has had similar issues..
> >
> > I trying to implement a firmware upgrade utility. I am using an RTOS
with
> multiple tasks. At the current point I am just concerned with erasing and
> reprogramming a block of the internal flash running from the one of the
> tasks.
> >
> > I use the intrinsic function __disable_irq(); to disable all interrupts
> before starting IAP application. The processor is in Privileged mode and
> the
> PRIMASK reg is set before I start the IAP.
> >
> >
> > The IAP application operates fine until I have a serial application task
> running which is communicating on UART1 or UART2 prior to the jump. What I
> *think* is the issue, is a pending interrupt on one of the UARTs, prior to
> disabling interrupts and jump to my IAP application; Then the IAP app
> fails.
>
> >
> > The fail condition results as IAP_EraseSectors() procedure always
returns
> busy; Even though the IAP_PrepareSectors() works...
> >
> > I dont think a pending interrupt should affect IAP if interrupts are
> disabled. So I am not convinced.. there must be some other explaination. I
> would like to get the IAP code. Has anyone ever got this from NXP?
> >
> > I can work around the issue by suspending the application task from
> running before I do the jump. But I am concerned that something else may
> cause a similar condition.
> >
> > Any advice would be appreciated.
> >
> > Best regards,
> >
> > Eoin Dowling
> >
>
>
>


Start a New Thread

For ISRs, yes, the debugger can cause problems. Note that this is not
specific to Keil. I can reproduce bad behavior with GDB.

However, I don't see how this applies here. He's talking about his IAP
calls failing. Interrupts should be disabled while calling into the IAP.
The Keil debugger works perfectly fine stepping through code that calls IAP
functions.

On Tue, Nov 22, 2011 at 9:25 AM, Phil Young wrote:

> **
> It depends on what you have displayed in the peripherals, watch, and memory
> windows.
>
> When it caused me the biggest problem was with a memory window that was not
> actually visible but was being refreshed.
> In this case the memory window update was stealing too many cycles and
> causing an ISR to overrun.
>
> In another case I had a local pointer to a UART on LPC1768, this was
> expanded in the watch window so it was reading the UART data register, as a
> result I was missing occasional characters.
>
> The bottom line is that the behaviour is dependent on what you are doing at
> the time, but it is something that people need to consider.
>
> Debugger accesses steal bus cycles and can have side effects that are not
> immediately obvious.
>
> This is not just with the ARM, I've seen this on many different processors
> over the years.
>
> Regards
>
> Phil.
> -----Original Message-----
> From: l... [mailto:l...] On Behalf
> Of
> Frank
> Sent: 22 November 2011 14:50
> To: l...
> Subject: Re: [lpc2000] Re: LPC1788 - IAP Issue- IAP_EraseSectors returns
> busy
>
> I just finished up my bootloader using the Keil tools. I have periodic
> updates turned on and did lots of debugging with no problems. The only
> times I had problems were because of bugs in my code. I can step through
> all my flashing routines, even the ones that get relocated to ram, just
> fine.
>
> On Tue, Nov 22, 2011 at 12:33 AM, Phil Young
> wrote:
>
> > **
>
> >
> >
> > I've seen this sort of problem sometimes with the Keil debugger, caused
> by
> > the debugger performing background accesses to update the display whilst
> > the
> > CPU is running.
> >
> > In Keil it's an option to have periodic updates when the CPU is running,
> > and
> > also there may be accesses if semi-hosting is enabled, it's under View -
> > Periodic Window Update.
> >
> > Disabling these feature generally solves this problem, i.e. build without
> > semi-hosting and stop periodic window updates.
> >
> > Regards
> >
> > Phil.
> >
> > From: l... [mailto:l...] On Behalf
> > Of
> > Mark
> > Sent: 22 November 2011 01:33
> > To: l...
> > Subject: [lpc2000] Re: LPC1788 - IAP Issue- IAP_EraseSectors returns busy
> >
> >
> > Hi Eoin
> >
> > Did you make any progress on this? I have just started using the LPC1788
> > (IAR LPC1788 board with SDRAM and TFT) and have big problems with the
> IAP.
> >
> > There are a lot of differences between the LPC1768 (which I have used
> quite
> > a lot) and the LPC1788 and I worked through these to get the board
> working
> > with the TFT display, UART and Ethernet with TCP/IP stack. Then I tried
> > saving web pages to the file system in internal Flash and it crashed.
> > Debugging showed that the IAP routine to write the first block of data to
> > the Flash (at address 0x20000 to be precise, which is blank) was being
> > entered as normal (with interrupts disabled) but it was failing and the
> > hard
> > fault was being hit.
> >
> > With the debugger I could step into the IAP code (starting at 0x1fff1ff1)
> > but the debugger had problems with this - it shows the instructions -
> which
> > look reasonable - but it seems to be doing something that is not exactly
> > according to the disassembled instructions; however it does look to be
> > basically working since I can see it loading the IAP command to a
> register
> > and calling its own sub-routines with the stack pointer being changed and
> > stack being used. After stepping for maybe 20..30 instruction steps
> > (although I think that sub-routine calls may have been taken without
> these
> > being correctly counted) it hits the hard fault.
> >
> > What is stange is that I use the identical code in various NXP projects
> on
> > the LPC2103, LPC2016, PC2148, LPC2368, LPC2478 and LPC1768 without any
> > problems (on the older LPC2xxx for several years and the newer LPC1768
> also
> > for around 2 years now). The user's manual doesn't point to any
> differences
> > in its use and the errate to the chip doesn't mention anything. The CPU
> is
> > operating at 120MHz but all Flash wait states etc. are set up correctly
> and
> > the LPC1788 board otherwise runs for hours without any problems.
> >
> > I stepped very carefully into the IAP in assember and monitored the the
> > stack content and the passed values [0x32 (50 dec) for the "prepare for
> > write" command, followed by the sector start and end numbers (both 0x12 -
> > or
> > 18 hex, corresponding to the address 0x20000)]. All is exactly as
> expected
> > so I can't explain why the IAP should effectively crash.
> >
> > This is not the same problem as you have reported but I am wondering
> > whether
> > maybe the IAP code in the boot area is corrupted for it to fail like
> > this...?
> >
> > However I then had a surprise. I built the program with a different
> > compiler/debugger and I found that it worked. I could also step well in
> the
> > IAP disassember code, but when I studied the assember code I didn't see
> any
> > real difference to the other one. What I did notice is that the IAP code
> > was
> > starting at address 0x1fff1ff0 whereby the other debuggger was showing
> the
> > code to start at 0x1fff1ff4 (shifted by 4 bytes but still it seemed to
> jump
> > into the code).
> >
> > So loaded the code from the other IDE and tested the board again (without
> > debugging - made a power cycle to be sure) and the file system was
> working
> > (!!!???). I connected the debugger and the IAP code looked good (starting
> > at
> > the correct location), so I put a break point and tried stepping into it
> > again. As soon as the file system code hit the break point and started
> > stepping the IAP code was again shifted by 4 bytes to 0x1fff1ff4 and the
> > IAP
> > call crashed...
> >
> > What I slowley worked out was the following:
> > - If I loaded the code and kept the debugger connected the IAP would
> always
> > crash.
> > - If I loaded the code and removed the debugger (power cycle) all worked
> > perfectly.
> > - As soon as I connected the debugger again (physically connected was no
> > problem but connected to the IDE was fatal) the IAP calls would fail.
> > - The other IDE didn't have this problem on its own, but, when the
> > 'interfering IDE' was used and then the IDE swapped without power cycling
> > the same effect was observed - that is, the IAP would again fail.
> >
> > So the conclusion is - without debugger everything is working well.
> > With certain debugger IAP can not be used.
> >
> > This is new - never had the effect before - but at least the effect is
> > clear
> > and it can be worked around.
> >
> > Regards
> >
> > Mark
> >
> > P.S. If you put a break point at the IAP call 0x1fff1ff0 you will be able
> > to
> > step into the code and also do a disassemble of it. Thsi is not as good
> as
> > C-source code but may help you understand your problem if you don't mind
> > exploring disassembled code for a few hours...
> >
> > --- In l... ,
> >
> > "dowlingeoin" wrote:
> > >
> > > Hi All,
> > >
> > > I have used IAP previously on LPC2000 family. I have an interesting
> issue
> > with using IAP on the LPC1788. I know its relatively new just wondering
> has
> > anyone else has had similar issues..
> > >
> > > I trying to implement a firmware upgrade utility. I am using an RTOS
> with
> > multiple tasks. At the current point I am just concerned with erasing and
> > reprogramming a block of the internal flash running from the one of the
> > tasks.
> > >
> > > I use the intrinsic function __disable_irq(); to disable all interrupts
> > before starting IAP application. The processor is in Privileged mode and
> > the
> > PRIMASK reg is set before I start the IAP.
> > >
> > >
> > > The IAP application operates fine until I have a serial application
> task
> > running which is communicating on UART1 or UART2 prior to the jump. What
> I
> > *think* is the issue, is a pending interrupt on one of the UARTs, prior
> to
> > disabling interrupts and jump to my IAP application; Then the IAP app
> > fails.
> >
> > >
> > > The fail condition results as IAP_EraseSectors() procedure always
> returns
> > busy; Even though the IAP_PrepareSectors() works...
> > >
> > > I dont think a pending interrupt should affect IAP if interrupts are
> > disabled. So I am not convinced.. there must be some other explaination.
> I
> > would like to get the IAP code. Has anyone ever got this from NXP?
> > >
> > > I can work around the issue by suspending the application task from
> > running before I do the jump. But I am concerned that something else may
> > cause a similar condition.
> > >
> > > Any advice would be appreciated.
> > >
> > > Best regards,
> > >
> > > Eoin Dowling
> > >
> >
> >
> >
> >
> >
>
> Start a New Thread

Hi

Yes, register watch windows can be a source of problems when debugging, especially when they read from FIFO registers or cause (interrupt) flags to be reset due to the register read access.

Presently I am working with the IDE manufacturer to see whether they can find out what is the problem in this case: with one IDE I never have the problem and with the other all works as long as the IDE debugger is connected "after" the board has been started - when the board is started by the IDE's debugger re-start command it always fails as explained. Since it is very reproducable (100% as far as my tests have shown) I am quite certain that the debugger is having an influence (somehow) on the IAP's operation. This will be repeated on a second board as soon as it arrives.

Depending on the outcome I'll report back if there is anything interesting. If the debugger influence can be identified and corrected I suppose the subject can be put-to-bed.

Regards

Mark

--- In l..., Frank wrote:
>
> For ISRs, yes, the debugger can cause problems. Note that this is not
> specific to Keil. I can reproduce bad behavior with GDB.
>
> However, I don't see how this applies here. He's talking about his IAP
> calls failing. Interrupts should be disabled while calling into the IAP.
> The Keil debugger works perfectly fine stepping through code that calls IAP
> functions.
>
> On Tue, Nov 22, 2011 at 9:25 AM, Phil Young wrote:
>
> > **
> >
> >
> > It depends on what you have displayed in the peripherals, watch, and memory
> > windows.
> >
> > When it caused me the biggest problem was with a memory window that was not
> > actually visible but was being refreshed.
> > In this case the memory window update was stealing too many cycles and
> > causing an ISR to overrun.
> >
> > In another case I had a local pointer to a UART on LPC1768, this was
> > expanded in the watch window so it was reading the UART data register, as a
> > result I was missing occasional characters.
> >
> > The bottom line is that the behaviour is dependent on what you are doing at
> > the time, but it is something that people need to consider.
> >
> > Debugger accesses steal bus cycles and can have side effects that are not
> > immediately obvious.
> >
> > This is not just with the ARM, I've seen this on many different processors
> > over the years.
> >
> > Regards
> >
> > Phil.
> >
> >
> > -----Original Message-----
> > From: l... [mailto:l...] On Behalf
> > Of
> > Frank
> > Sent: 22 November 2011 14:50
> > To: l...
> > Subject: Re: [lpc2000] Re: LPC1788 - IAP Issue- IAP_EraseSectors returns
> > busy
> >
> > I just finished up my bootloader using the Keil tools. I have periodic
> > updates turned on and did lots of debugging with no problems. The only
> > times I had problems were because of bugs in my code. I can step through
> > all my flashing routines, even the ones that get relocated to ram, just
> > fine.
> >
> > On Tue, Nov 22, 2011 at 12:33 AM, Phil Young
> > wrote:
> >
> > > **
> >
> > >
> > >
> > > I've seen this sort of problem sometimes with the Keil debugger, caused
> > by
> > > the debugger performing background accesses to update the display whilst
> > > the
> > > CPU is running.
> > >
> > > In Keil it's an option to have periodic updates when the CPU is running,
> > > and
> > > also there may be accesses if semi-hosting is enabled, it's under View -
> > > Periodic Window Update.
> > >
> > > Disabling these feature generally solves this problem, i.e. build without
> > > semi-hosting and stop periodic window updates.
> > >
> > > Regards
> > >
> > > Phil.
> > >
> > > From: l... [mailto:l...] On Behalf
> > > Of
> > > Mark
> > > Sent: 22 November 2011 01:33
> > > To: l...
> > > Subject: [lpc2000] Re: LPC1788 - IAP Issue- IAP_EraseSectors returns busy
> > >
> > >
> > > Hi Eoin
> > >
> > > Did you make any progress on this? I have just started using the LPC1788
> > > (IAR LPC1788 board with SDRAM and TFT) and have big problems with the
> > IAP.
> > >
> > > There are a lot of differences between the LPC1768 (which I have used
> > quite
> > > a lot) and the LPC1788 and I worked through these to get the board
> > working
> > > with the TFT display, UART and Ethernet with TCP/IP stack. Then I tried
> > > saving web pages to the file system in internal Flash and it crashed.
> > > Debugging showed that the IAP routine to write the first block of data to
> > > the Flash (at address 0x20000 to be precise, which is blank) was being
> > > entered as normal (with interrupts disabled) but it was failing and the
> > > hard
> > > fault was being hit.
> > >
> > > With the debugger I could step into the IAP code (starting at 0x1fff1ff1)
> > > but the debugger had problems with this - it shows the instructions -
> > which
> > > look reasonable - but it seems to be doing something that is not exactly
> > > according to the disassembled instructions; however it does look to be
> > > basically working since I can see it loading the IAP command to a
> > register
> > > and calling its own sub-routines with the stack pointer being changed and
> > > stack being used. After stepping for maybe 20..30 instruction steps
> > > (although I think that sub-routine calls may have been taken without
> > these
> > > being correctly counted) it hits the hard fault.
> > >
> > > What is stange is that I use the identical code in various NXP projects
> > on
> > > the LPC2103, LPC2016, PC2148, LPC2368, LPC2478 and LPC1768 without any
> > > problems (on the older LPC2xxx for several years and the newer LPC1768
> > also
> > > for around 2 years now). The user's manual doesn't point to any
> > differences
> > > in its use and the errate to the chip doesn't mention anything. The CPU
> > is
> > > operating at 120MHz but all Flash wait states etc. are set up correctly
> > and
> > > the LPC1788 board otherwise runs for hours without any problems.
> > >
> > > I stepped very carefully into the IAP in assember and monitored the the
> > > stack content and the passed values [0x32 (50 dec) for the "prepare for
> > > write" command, followed by the sector start and end numbers (both 0x12 -
> > > or
> > > 18 hex, corresponding to the address 0x20000)]. All is exactly as
> > expected
> > > so I can't explain why the IAP should effectively crash.
> > >
> > > This is not the same problem as you have reported but I am wondering
> > > whether
> > > maybe the IAP code in the boot area is corrupted for it to fail like
> > > this...?
> > >
> > > However I then had a surprise. I built the program with a different
> > > compiler/debugger and I found that it worked. I could also step well in
> > the
> > > IAP disassember code, but when I studied the assember code I didn't see
> > any
> > > real difference to the other one. What I did notice is that the IAP code
> > > was
> > > starting at address 0x1fff1ff0 whereby the other debuggger was showing
> > the
> > > code to start at 0x1fff1ff4 (shifted by 4 bytes but still it seemed to
> > jump
> > > into the code).
> > >
> > > So loaded the code from the other IDE and tested the board again (without
> > > debugging - made a power cycle to be sure) and the file system was
> > working
> > > (!!!???). I connected the debugger and the IAP code looked good (starting
> > > at
> > > the correct location), so I put a break point and tried stepping into it
> > > again. As soon as the file system code hit the break point and started
> > > stepping the IAP code was again shifted by 4 bytes to 0x1fff1ff4 and the
> > > IAP
> > > call crashed...
> > >
> > > What I slowley worked out was the following:
> > > - If I loaded the code and kept the debugger connected the IAP would
> > always
> > > crash.
> > > - If I loaded the code and removed the debugger (power cycle) all worked
> > > perfectly.
> > > - As soon as I connected the debugger again (physically connected was no
> > > problem but connected to the IDE was fatal) the IAP calls would fail.
> > > - The other IDE didn't have this problem on its own, but, when the
> > > 'interfering IDE' was used and then the IDE swapped without power cycling
> > > the same effect was observed - that is, the IAP would again fail.
> > >
> > > So the conclusion is - without debugger everything is working well.
> > > With certain debugger IAP can not be used.
> > >
> > > This is new - never had the effect before - but at least the effect is
> > > clear
> > > and it can be worked around.
> > >
> > > Regards
> > >
> > > Mark
> > >
> > > P.S. If you put a break point at the IAP call 0x1fff1ff0 you will be able
> > > to
> > > step into the code and also do a disassemble of it. Thsi is not as good
> > as
> > > C-source code but may help you understand your problem if you don't mind
> > > exploring disassembled code for a few hours...
> > >

Start a New Thread

When programming generic flash devices it can cause failure, not sure what
their algorithm is for embedded flash, but you must be careful not to
perform read accesses to the flash during certain phases of programming.
I have also had this problem on the Leon.

If you have a debugger window viewing the flash to see that it has been
programmed this can certainly cause problems if a debugger refresh occurs
during programming.
-----Original Message-----
From: l... [mailto:l...] On Behalf Of
Frank
Sent: 22 November 2011 16:57
To: l...
Subject: Re: [lpc2000] Re: LPC1788 - IAP Issue- IAP_EraseSectors returns
busy

For ISRs, yes, the debugger can cause problems. Note that this is not
specific to Keil. I can reproduce bad behavior with GDB.

However, I don't see how this applies here. He's talking about his IAP
calls failing. Interrupts should be disabled while calling into the IAP.
The Keil debugger works perfectly fine stepping through code that calls IAP
functions.

On Tue, Nov 22, 2011 at 9:25 AM, Phil Young
wrote:

> **
> It depends on what you have displayed in the peripherals, watch, and
memory
> windows.
>
> When it caused me the biggest problem was with a memory window that was
not
> actually visible but was being refreshed.
> In this case the memory window update was stealing too many cycles and
> causing an ISR to overrun.
>
> In another case I had a local pointer to a UART on LPC1768, this was
> expanded in the watch window so it was reading the UART data register, as
a
> result I was missing occasional characters.
>
> The bottom line is that the behaviour is dependent on what you are doing
at
> the time, but it is something that people need to consider.
>
> Debugger accesses steal bus cycles and can have side effects that are not
> immediately obvious.
>
> This is not just with the ARM, I've seen this on many different processors
> over the years.
>
> Regards
>
> Phil.
> -----Original Message-----
> From: l... [mailto:l...] On Behalf
> Of
> Frank
> Sent: 22 November 2011 14:50
> To: l...
> Subject: Re: [lpc2000] Re: LPC1788 - IAP Issue- IAP_EraseSectors returns
> busy
>
> I just finished up my bootloader using the Keil tools. I have periodic
> updates turned on and did lots of debugging with no problems. The only
> times I had problems were because of bugs in my code. I can step through
> all my flashing routines, even the ones that get relocated to ram, just
> fine.
>
> On Tue, Nov 22, 2011 at 12:33 AM, Phil Young
> wrote:
>
> > **
>
> >
> >
> > I've seen this sort of problem sometimes with the Keil debugger, caused
> by
> > the debugger performing background accesses to update the display whilst
> > the
> > CPU is running.
> >
> > In Keil it's an option to have periodic updates when the CPU is running,
> > and
> > also there may be accesses if semi-hosting is enabled, it's under View -
> > Periodic Window Update.
> >
> > Disabling these feature generally solves this problem, i.e. build
without
> > semi-hosting and stop periodic window updates.
> >
> > Regards
> >
> > Phil.
> >
> > From: l... [mailto:l...] On Behalf
> > Of
> > Mark
> > Sent: 22 November 2011 01:33
> > To: l...
> > Subject: [lpc2000] Re: LPC1788 - IAP Issue- IAP_EraseSectors returns
busy
> >
> >
> > Hi Eoin
> >
> > Did you make any progress on this? I have just started using the LPC1788
> > (IAR LPC1788 board with SDRAM and TFT) and have big problems with the
> IAP.
> >
> > There are a lot of differences between the LPC1768 (which I have used
> quite
> > a lot) and the LPC1788 and I worked through these to get the board
> working
> > with the TFT display, UART and Ethernet with TCP/IP stack. Then I tried
> > saving web pages to the file system in internal Flash and it crashed.
> > Debugging showed that the IAP routine to write the first block of data
to
> > the Flash (at address 0x20000 to be precise, which is blank) was being
> > entered as normal (with interrupts disabled) but it was failing and the
> > hard
> > fault was being hit.
> >
> > With the debugger I could step into the IAP code (starting at
0x1fff1ff1)
> > but the debugger had problems with this - it shows the instructions -
> which
> > look reasonable - but it seems to be doing something that is not exactly
> > according to the disassembled instructions; however it does look to be
> > basically working since I can see it loading the IAP command to a
> register
> > and calling its own sub-routines with the stack pointer being changed
and
> > stack being used. After stepping for maybe 20..30 instruction steps
> > (although I think that sub-routine calls may have been taken without
> these
> > being correctly counted) it hits the hard fault.
> >
> > What is stange is that I use the identical code in various NXP projects
> on
> > the LPC2103, LPC2016, PC2148, LPC2368, LPC2478 and LPC1768 without any
> > problems (on the older LPC2xxx for several years and the newer LPC1768
> also
> > for around 2 years now). The user's manual doesn't point to any
> differences
> > in its use and the errate to the chip doesn't mention anything. The CPU
> is
> > operating at 120MHz but all Flash wait states etc. are set up correctly
> and
> > the LPC1788 board otherwise runs for hours without any problems.
> >
> > I stepped very carefully into the IAP in assember and monitored the the
> > stack content and the passed values [0x32 (50 dec) for the "prepare for
> > write" command, followed by the sector start and end numbers (both 0x12
-
> > or
> > 18 hex, corresponding to the address 0x20000)]. All is exactly as
> expected
> > so I can't explain why the IAP should effectively crash.
> >
> > This is not the same problem as you have reported but I am wondering
> > whether
> > maybe the IAP code in the boot area is corrupted for it to fail like
> > this...?
> >
> > However I then had a surprise. I built the program with a different
> > compiler/debugger and I found that it worked. I could also step well in
> the
> > IAP disassember code, but when I studied the assember code I didn't see
> any
> > real difference to the other one. What I did notice is that the IAP code
> > was
> > starting at address 0x1fff1ff0 whereby the other debuggger was showing
> the
> > code to start at 0x1fff1ff4 (shifted by 4 bytes but still it seemed to
> jump
> > into the code).
> >
> > So loaded the code from the other IDE and tested the board again
(without
> > debugging - made a power cycle to be sure) and the file system was
> working
> > (!!!???). I connected the debugger and the IAP code looked good
(starting
> > at
> > the correct location), so I put a break point and tried stepping into it
> > again. As soon as the file system code hit the break point and started
> > stepping the IAP code was again shifted by 4 bytes to 0x1fff1ff4 and the
> > IAP
> > call crashed...
> >
> > What I slowley worked out was the following:
> > - If I loaded the code and kept the debugger connected the IAP would
> always
> > crash.
> > - If I loaded the code and removed the debugger (power cycle) all worked
> > perfectly.
> > - As soon as I connected the debugger again (physically connected was no
> > problem but connected to the IDE was fatal) the IAP calls would fail.
> > - The other IDE didn't have this problem on its own, but, when the
> > 'interfering IDE' was used and then the IDE swapped without power
cycling
> > the same effect was observed - that is, the IAP would again fail.
> >
> > So the conclusion is - without debugger everything is working well.
> > With certain debugger IAP can not be used.
> >
> > This is new - never had the effect before - but at least the effect is
> > clear
> > and it can be worked around.
> >
> > Regards
> >
> > Mark
> >
> > P.S. If you put a break point at the IAP call 0x1fff1ff0 you will be
able
> > to
> > step into the code and also do a disassemble of it. Thsi is not as good
> as
> > C-source code but may help you understand your problem if you don't mind
> > exploring disassembled code for a few hours...
> >
> > --- In l... ,
> >
> > "dowlingeoin" wrote:
> > >
> > > Hi All,
> > >
> > > I have used IAP previously on LPC2000 family. I have an interesting
> issue
> > with using IAP on the LPC1788. I know its relatively new just wondering
> has
> > anyone else has had similar issues..
> > >
> > > I trying to implement a firmware upgrade utility. I am using an RTOS
> with
> > multiple tasks. At the current point I am just concerned with erasing
and
> > reprogramming a block of the internal flash running from the one of the
> > tasks.
> > >
> > > I use the intrinsic function __disable_irq(); to disable all
interrupts
> > before starting IAP application. The processor is in Privileged mode and
> > the
> > PRIMASK reg is set before I start the IAP.
> > >
> > >
> > > The IAP application operates fine until I have a serial application
> task
> > running which is communicating on UART1 or UART2 prior to the jump. What
> I
> > *think* is the issue, is a pending interrupt on one of the UARTs, prior
> to
> > disabling interrupts and jump to my IAP application; Then the IAP app
> > fails.
> >
> > >
> > > The fail condition results as IAP_EraseSectors() procedure always
> returns
> > busy; Even though the IAP_PrepareSectors() works...
> > >
> > > I dont think a pending interrupt should affect IAP if interrupts are
> > disabled. So I am not convinced.. there must be some other explaination.
> I
> > would like to get the IAP code. Has anyone ever got this from NXP?
> > >
> > > I can work around the issue by suspending the application task from
> > running before I do the jump. But I am concerned that something else may
> > cause a similar condition.
> > >
> > > Any advice would be appreciated.
> > >
> > > Best regards,
> > >
> > > Eoin Dowling
> > >
> >
> >
> >
> >
> >
>
> Start a New Thread

--- In l..., "Phil Young" wrote:

> I have also had this problem on the Leon.
>

What is "the Leon" ??

don

Start a New Thread