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