Reply by Mark November 24, 20112011-11-24
Hi

I have removed all unnecessary stuff to test a very small project but there is no different. I didn't see any incompatibilities with the IAP interface (maybe there is a bit of new functionality but that shouldn't be important).

Also I have tested at 120MHz (the power boost is used from 100MHz) and also at 12MHz (without power boost and without PLL) and the ersulst have always been the same.

The project does operate correctly as long as I don't run it after a reset from a particular debugger so I believe that the IAP is generally OK (I have no problems after a power on with disconnected debugger or generally with a different debugger attached).

What I do know in addition is that the IAP generaly fails when a certain AHB bus matrix setting is used with TFT in operation. This can be shown consistently as described here: http://tech.groups.yahoo.com/group/lpc2000/message/55806
In this case the debugger doesn't play a role and it is the same (always good with one setting and always bad with another setting) when tested with different compiler images and different debuggers. In this case the LCD controller needs to be running otherwise it is also OK.

It may give a hint to what the debugger may be influencing also, but essentially the project is fully operational as long as I don't use that particulare matrix priority setting and don't try to debug at the same time with a certain debugger.

Regards

Mark

--- In l..., "capiman26061973" wrote:
>
> Hello Mark,
>
> I think you already checked for differences of the user manual of
> LPC1768 and LPC1788 (convert both to text and compare both
> for text changes).
>
> Was there perhaps a change / extension of the RAM area
> which IAP used internally ?
>
> Is there perhaps a different ROM version (perhaps can be seen
> by booter (ISP) version, not sure on this ??? Or dump the area
> and look for differences in dumped binary ?
> LPC1788 is a newer chip, perhaps also newer ROM code ?
>
> You have written you had to change a lot to go to LPC1788.
> Could you perhaps reduce your code to a much more simpler code
> (just main, which writes something to flash via IAP),
> so every other peripheral not needed (like Ethernet,
> display interface) could be remain switched off.
> Is it perhaps then possible to use completely the same software
> (binary) on both controllers ?
>
> There seems to be a new "Power boost" feature:
> (quote from user manual of LPC1788)
>
> > A Power boost feature allows operation above 100 MHz,
> > to the upper limit for this device of 120 MHz.
> > This boost is on by default when user code
> > begins after a chip reset. Power can be saved
> > by turning of this mode when operation will be
> > at 100 MHz or lower.
>
> Because is it on by default and perhaps influences the speed:
> Can you perhaps switch it off and try again ?
>
> Best regards,
>
> Martin
> --- In l..., "Phil Young" wrote:
> >
> > Hi don,
> >
> >
> >
> > Leon is an embedded implementation of the SPARC processor by Giri Gaisler,
> > we used it on the NX1 / NX2 GPS chipsets at NemeriX.
> >
> >
> >
> > Phil.
> >
> >
> >
> > From: l... [mailto:l...] On Behalf Of
> > Donald H
> > Sent: 24 November 2011 04:35
> > To: l...
> > Subject: [lpc2000] Re: LPC1788 - IAP Issue- IAP_EraseSectors returns busy
> >
> >
> >
> >
> >
> >
> >
> > --- In l... , "Phil
> > Young" wrote:
> >
> > > I have also had this problem on the Leon.
> > >
> >
> > What is "the Leon" ??
> >
> > don
> >
> >
> >
> >
> >
> >
>

An Engineer's Guide to the LPC2100 Series

Reply by dowlingeoin November 24, 20112011-11-24
Hi,

Thanks for your response. Sorry for the delayed feedback. I havent seen the debugger make any difference...

A reset prior to starting the burn utility seems to clear whatever is causing the IAP_EraseSectors to be in a busy state. Implementing a reset handler to manage the state.

1) Copy firmware image to a temp location.
2) Reset. On reset copy flash upgrade utility to internal SRAM and Jump to the utility.
3) Burn the firmware to flash and reset.
Best regards,

Eoin
--- In l..., "Mark" wrote:
>
> 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
>

Reply by arma...@mini-amd.org November 24, 20112011-11-24
Oops, wrong button sorry :(

BR,

Armand

On Thu, 24 Nov 2011 09:58:02 +0100, wrote:
> On Thu, 24 Nov 2011 04:35:29 -0000, "Donald H"

> wrote:
>> --- In l..., "Phil Young" wrote:
>>
>>> I have also had this problem on the Leon.
>>> What is "the Leon" ??
>>
>> don
Reply by arma...@mini-amd.org November 24, 20112011-11-24
On Thu, 24 Nov 2011 04:35:29 -0000, "Donald H"
wrote:
> --- In l..., "Phil Young" wrote:
>
>> I have also had this problem on the Leon.
>> What is "the Leon" ??
>
> don
Reply by capiman26061973 November 24, 20112011-11-24
Hello Mark,

I think you already checked for differences of the user manual of
LPC1768 and LPC1788 (convert both to text and compare both
for text changes).

Was there perhaps a change / extension of the RAM area
which IAP used internally ?

Is there perhaps a different ROM version (perhaps can be seen
by booter (ISP) version, not sure on this ??? Or dump the area
and look for differences in dumped binary ?
LPC1788 is a newer chip, perhaps also newer ROM code ?

You have written you had to change a lot to go to LPC1788.
Could you perhaps reduce your code to a much more simpler code
(just main, which writes something to flash via IAP),
so every other peripheral not needed (like Ethernet,
display interface) could be remain switched off.
Is it perhaps then possible to use completely the same software
(binary) on both controllers ?

There seems to be a new "Power boost" feature:
(quote from user manual of LPC1788)

> A Power boost feature allows operation above 100 MHz,
> to the upper limit for this device of 120 MHz.
> This boost is on by default when user code
> begins after a chip reset. Power can be saved
> by turning of this mode when operation will be
> at 100 MHz or lower.

Because is it on by default and perhaps influences the speed:
Can you perhaps switch it off and try again ?

Best regards,

Martin
--- In l..., "Phil Young" wrote:
>
> Hi don,
>
>
>
> Leon is an embedded implementation of the SPARC processor by Giri Gaisler,
> we used it on the NX1 / NX2 GPS chipsets at NemeriX.
>
>
>
> Phil.
>
>
>
> From: l... [mailto:l...] On Behalf Of
> Donald H
> Sent: 24 November 2011 04:35
> To: l...
> Subject: [lpc2000] Re: LPC1788 - IAP Issue- IAP_EraseSectors returns busy
>
>
>
>
>
> --- In l... , "Phil
> Young" wrote:
>
> > I have also had this problem on the Leon.
> > What is "the Leon" ??
>
> don
>
>
>

Reply by Phil Young November 24, 20112011-11-24
Hi don,

Leon is an embedded implementation of the SPARC processor by Giri Gaisler,
we used it on the NX1 / NX2 GPS chipsets at NemeriX.

Phil.

From: l... [mailto:l...] On Behalf Of
Donald H
Sent: 24 November 2011 04:35
To: l...
Subject: [lpc2000] Re: LPC1788 - IAP Issue- IAP_EraseSectors returns busy

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

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

What is "the Leon" ??

don



Reply by Donald H November 24, 20112011-11-24
--- In l..., "Phil Young" wrote:

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

What is "the Leon" ??

don

Reply by Phil Young November 22, 20112011-11-22
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
> > >
> >
> >
> >
> >
> >
>
>
Reply by Mark November 22, 20112011-11-22
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...
> > >

Reply by Frank November 22, 20112011-11-22
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
> > >
> >
> >
> >
> >
> >
>
>