Hi All
Quote from the LPC17XX manual - "IAP commands, which result in a FLASH
write/erase operation, use 32 bytes of space in the top portion of the on-chip
RAM for execution. The user program should not use this space if IAP flash
programming is permitted in the application."
Does anyone know which space is being referred to exactly?
The LPC1766 which I use for tests has three SRAM banks:
0x10000000..0x1007ffff
0x2007c000..0x2007ffff
0x20080000..0x20083fff
As an attempt to identify which are it could be I used a debugger and stopped
the code just before an IAP call which was programming FLASH. Then I wrote a
pattern into the last 32 bytes at the very end of each of these 3 SRAM banks.
After the IAP call had returned, and successfully programmed the FLASH, all
three areas had the same pattern, suggesting that none of them were used by the
IAP routine.
Is the information in the user's manual not relevant for this chip or is a
different area used??
Regards
Mark
IAP use of SRAM in the LPC17XX
Started by ●January 23, 2010
Reply by ●January 27, 20102010-01-27
Hi All
Any ideas??
Regards
Mark
--- In l..., "mjbcswitzerland" wrote:
>
> Hi All
>
> Quote from the LPC17XX manual - "IAP commands, which result in a FLASH write/erase operation, use 32 bytes of space in the top portion of the on-chip RAM for execution. The user program should not use this space if IAP flash programming is permitted in the application."
>
> Does anyone know which space is being referred to exactly?
> The LPC1766 which I use for tests has three SRAM banks:
> 0x10000000..0x1007ffff
> 0x2007c000..0x2007ffff
> 0x20080000..0x20083fff
>
> As an attempt to identify which are it could be I used a debugger and stopped the code just before an IAP call which was programming FLASH. Then I wrote a pattern into the last 32 bytes at the very end of each of these 3 SRAM banks.
>
> After the IAP call had returned, and successfully programmed the FLASH, all three areas had the same pattern, suggesting that none of them were used by the IAP routine.
>
> Is the information in the user's manual not relevant for this chip or is a different area used??
>
> Regards
>
> Mark
>
Any ideas??
Regards
Mark
--- In l..., "mjbcswitzerland" wrote:
>
> Hi All
>
> Quote from the LPC17XX manual - "IAP commands, which result in a FLASH write/erase operation, use 32 bytes of space in the top portion of the on-chip RAM for execution. The user program should not use this space if IAP flash programming is permitted in the application."
>
> Does anyone know which space is being referred to exactly?
> The LPC1766 which I use for tests has three SRAM banks:
> 0x10000000..0x1007ffff
> 0x2007c000..0x2007ffff
> 0x20080000..0x20083fff
>
> As an attempt to identify which are it could be I used a debugger and stopped the code just before an IAP call which was programming FLASH. Then I wrote a pattern into the last 32 bytes at the very end of each of these 3 SRAM banks.
>
> After the IAP call had returned, and successfully programmed the FLASH, all three areas had the same pattern, suggesting that none of them were used by the IAP routine.
>
> Is the information in the user's manual not relevant for this chip or is a different area used??
>
> Regards
>
> Mark
>
Reply by ●January 27, 20102010-01-27
Hi Mark
I know you from the MCF5223X from freescale ;)
Maybe the user manual refers to top portion of ram, the first bytes, not the last ones. Just a thought...and probably im wrong.
--- Em qua, 27/1/10, mjbcswitzerland escreveu:
> De: mjbcswitzerland
> Assunto: [lpc2000] Re: IAP use of SRAM in the LPC17XX
> Para: l...
> Data: Quarta-feira, 27 de Janeiro de 2010, 11:33
> Hi All
>
> Any ideas??
>
> Regards
>
> Mark
>
>
> --- In l...,
> "mjbcswitzerland" wrote:
> >
> > Hi All
> >
> > Quote from the LPC17XX manual - "IAP commands, which
> result in a FLASH write/erase operation, use 32 bytes of
> space in the top portion of the on-chip RAM for execution.
> The user program should not use this space if IAP flash
> programming is permitted in the application."
> >
> > Does anyone know which space is being referred to
> exactly?
> > The LPC1766 which I use for tests has three SRAM
> banks:
> > 0x10000000..0x1007ffff
> > 0x2007c000..0x2007ffff
> > 0x20080000..0x20083fff
> >
> > As an attempt to identify which are it could be I used
> a debugger and stopped the code just before an IAP call
> which was programming FLASH. Then I wrote a pattern into the
> last 32 bytes at the very end of each of these 3 SRAM
> banks.
> >
> > After the IAP call had returned, and successfully
> programmed the FLASH, all three areas had the same pattern,
> suggesting that none of them were used by the IAP routine.
> >
> > Is the information in the user's manual not relevant
> for this chip or is a different area used??
> >
> > Regards
> >
> > Mark
> >
>
>
>
>
>
>
>
I know you from the MCF5223X from freescale ;)
Maybe the user manual refers to top portion of ram, the first bytes, not the last ones. Just a thought...and probably im wrong.
--- Em qua, 27/1/10, mjbcswitzerland escreveu:
> De: mjbcswitzerland
> Assunto: [lpc2000] Re: IAP use of SRAM in the LPC17XX
> Para: l...
> Data: Quarta-feira, 27 de Janeiro de 2010, 11:33
> Hi All
>
> Any ideas??
>
> Regards
>
> Mark
>
>
> --- In l...,
> "mjbcswitzerland" wrote:
> >
> > Hi All
> >
> > Quote from the LPC17XX manual - "IAP commands, which
> result in a FLASH write/erase operation, use 32 bytes of
> space in the top portion of the on-chip RAM for execution.
> The user program should not use this space if IAP flash
> programming is permitted in the application."
> >
> > Does anyone know which space is being referred to
> exactly?
> > The LPC1766 which I use for tests has three SRAM
> banks:
> > 0x10000000..0x1007ffff
> > 0x2007c000..0x2007ffff
> > 0x20080000..0x20083fff
> >
> > As an attempt to identify which are it could be I used
> a debugger and stopped the code just before an IAP call
> which was programming FLASH. Then I wrote a pattern into the
> last 32 bytes at the very end of each of these 3 SRAM
> banks.
> >
> > After the IAP call had returned, and successfully
> programmed the FLASH, all three areas had the same pattern,
> suggesting that none of them were used by the IAP routine.
> >
> > Is the information in the user's manual not relevant
> for this chip or is a different area used??
> >
> > Regards
> >
> > Mark
> >
>
>
>
>
>
>
>
Reply by ●January 29, 20102010-01-29
Hi Alexandre
Thanks for the idea - I will give this a try the next time that I am working with the board.
Regards
Mark
--- In l..., Alexandre Kremer wrote:
>
> Hi Mark
>
> I know you from the MCF5223X from freescale ;)
> Maybe the user manual refers to top portion of ram, the first bytes, not the last ones. Just a thought...and probably im wrong.
>
Thanks for the idea - I will give this a try the next time that I am working with the board.
Regards
Mark
--- In l..., Alexandre Kremer wrote:
>
> Hi Mark
>
> I know you from the MCF5223X from freescale ;)
> Maybe the user manual refers to top portion of ram, the first bytes, not the last ones. Just a thought...and probably im wrong.
>
Reply by ●January 30, 20102010-01-30
Hi:
I developed a bootloader for the LPC1752 and leave the last 32 bytes free for the IAP (at 0x10003FE0). I haven't check if the IAP actually uses the memory locations, but the Flash is updated correctly.
Regards,
Alex
--- In l..., "mjbcswitzerland" wrote:
>
> Hi All
>
> Quote from the LPC17XX manual - "IAP commands, which result in a FLASH write/erase operation, use 32 bytes of space in the top portion of the on-chip RAM for execution. The user program should not use this space if IAP flash programming is permitted in the application."
>
> Does anyone know which space is being referred to exactly?
> The LPC1766 which I use for tests has three SRAM banks:
> 0x10000000..0x1007ffff
> 0x2007c000..0x2007ffff
> 0x20080000..0x20083fff
>
> As an attempt to identify which are it could be I used a debugger and stopped the code just before an IAP call which was programming FLASH. Then I wrote a pattern into the last 32 bytes at the very end of each of these 3 SRAM banks.
>
> After the IAP call had returned, and successfully programmed the FLASH, all three areas had the same pattern, suggesting that none of them were used by the IAP routine.
>
> Is the information in the user's manual not relevant for this chip or is a different area used??
>
> Regards
>
> Mark
>
I developed a bootloader for the LPC1752 and leave the last 32 bytes free for the IAP (at 0x10003FE0). I haven't check if the IAP actually uses the memory locations, but the Flash is updated correctly.
Regards,
Alex
--- In l..., "mjbcswitzerland" wrote:
>
> Hi All
>
> Quote from the LPC17XX manual - "IAP commands, which result in a FLASH write/erase operation, use 32 bytes of space in the top portion of the on-chip RAM for execution. The user program should not use this space if IAP flash programming is permitted in the application."
>
> Does anyone know which space is being referred to exactly?
> The LPC1766 which I use for tests has three SRAM banks:
> 0x10000000..0x1007ffff
> 0x2007c000..0x2007ffff
> 0x20080000..0x20083fff
>
> As an attempt to identify which are it could be I used a debugger and stopped the code just before an IAP call which was programming FLASH. Then I wrote a pattern into the last 32 bytes at the very end of each of these 3 SRAM banks.
>
> After the IAP call had returned, and successfully programmed the FLASH, all three areas had the same pattern, suggesting that none of them were used by the IAP routine.
>
> Is the information in the user's manual not relevant for this chip or is a different area used??
>
> Regards
>
> Mark
>
Reply by ●January 30, 20102010-01-30
Hi Alex
Thanks. Since your chip has 16k of RAM the last 32 bytes of that would make sense. This would correspond to the test that I did monitoring 0x10007fe0 in my LPC1766, with 32k system RAM.
None of these were changed when erasing or programming FLASH (the FLASH functions always worked correctly) so you may also find that none of them are being used in your case. Of course leaving space for them will not hurt but the question is, if they are not being used by IAP then what is it using? Is it maybe trashing some bytes somewhere else which we haven't noticed yet...?
Or is it possible that the LPC17XX actually has some dedicated RAM for their IAP routines and therefore we don't need to reserve any space anymore?
Regards
Mark
--- In l..., "alexander_ribero" wrote:
>
> Hi:
>
> I developed a bootloader for the LPC1752 and leave the last 32 bytes free for the IAP (at 0x10003FE0). I haven't check if the IAP actually uses the memory locations, but the Flash is updated correctly.
>
> Regards,
>
> Alex
>
Thanks. Since your chip has 16k of RAM the last 32 bytes of that would make sense. This would correspond to the test that I did monitoring 0x10007fe0 in my LPC1766, with 32k system RAM.
None of these were changed when erasing or programming FLASH (the FLASH functions always worked correctly) so you may also find that none of them are being used in your case. Of course leaving space for them will not hurt but the question is, if they are not being used by IAP then what is it using? Is it maybe trashing some bytes somewhere else which we haven't noticed yet...?
Or is it possible that the LPC17XX actually has some dedicated RAM for their IAP routines and therefore we don't need to reserve any space anymore?
Regards
Mark
--- In l..., "alexander_ribero" wrote:
>
> Hi:
>
> I developed a bootloader for the LPC1752 and leave the last 32 bytes free for the IAP (at 0x10003FE0). I haven't check if the IAP actually uses the memory locations, but the Flash is updated correctly.
>
> Regards,
>
> Alex
>
Reply by ●August 25, 20112011-08-25
Hello,
does anybody have any news here? I did some similar tests on an LPC1768 (32K+16K+16K internal SRAM) and wrote a 32 byte pattern to the following addresses:
0x10000000 - Start of SRAM (size 32K)
0x10007FDF - End of SRAM (-32 bytes)
0x2007C000 - Start of AHB SRAM 1 (size 16K)
0x2007FFDF - End of AHB SRAM 1 (-32 bytes)
0x20080000 - Start of AHB SRAM 2 (size 16K)
0x20083FDF - End of AHB SRAM 2 (-32 bytes)
The IAP functions I used were PREPARE_SECTORS and ERASE_SECTORS. Using JTAG-debugging I verified that the patterns on all addresses from above remain the same before and after the IAP calls.
So where exactly are the "32 bytes of space in the top portion of the on-chip RAM" as UM10360 states in chapter 32? I don't really want to ignore this...
Best regards,
Ralf
--- In l..., "mjbcswitzerland" wrote:
>
> Hi Alexandre
>
> Thanks for the idea - I will give this a try the next time that I am working with the board.
>
> Regards
>
> Mark
>
>
> --- In l..., Alexandre Kremer wrote:
> >
> > Hi Mark
> >
> > I know you from the MCF5223X from freescale ;)
> > Maybe the user manual refers to top portion of ram, the first bytes, not the last ones. Just a thought...and probably im wrong.
>
does anybody have any news here? I did some similar tests on an LPC1768 (32K+16K+16K internal SRAM) and wrote a 32 byte pattern to the following addresses:
0x10000000 - Start of SRAM (size 32K)
0x10007FDF - End of SRAM (-32 bytes)
0x2007C000 - Start of AHB SRAM 1 (size 16K)
0x2007FFDF - End of AHB SRAM 1 (-32 bytes)
0x20080000 - Start of AHB SRAM 2 (size 16K)
0x20083FDF - End of AHB SRAM 2 (-32 bytes)
The IAP functions I used were PREPARE_SECTORS and ERASE_SECTORS. Using JTAG-debugging I verified that the patterns on all addresses from above remain the same before and after the IAP calls.
So where exactly are the "32 bytes of space in the top portion of the on-chip RAM" as UM10360 states in chapter 32? I don't really want to ignore this...
Best regards,
Ralf
--- In l..., "mjbcswitzerland" wrote:
>
> Hi Alexandre
>
> Thanks for the idea - I will give this a try the next time that I am working with the board.
>
> Regards
>
> Mark
>
>
> --- In l..., Alexandre Kremer wrote:
> >
> > Hi Mark
> >
> > I know you from the MCF5223X from freescale ;)
> > Maybe the user manual refers to top portion of ram, the first bytes, not the last ones. Just a thought...and probably im wrong.
>
Reply by ●August 25, 20112011-08-25
Hello Ralf,
i would say the area is from
0x10007FE0 to 0x10007FFF.
Why have you left out the 32 bytes (especially in this area),
when you want explicitely test this area for changed memory ?
> 0x10000000 - Start of SRAM (size 32K)
> 0x10007FDF - End of SRAM (-32 bytes)
0x10000000 - Start of SRAM (size 32K)
0x10007FFF - End of SRAM
It could also be (but i am no expert in IAP, nor do i now
what IAP is exactly internally doing) that the memory is only
used for certain commands. Perhaps some IAP command don't touch
the area at all (e.g. if no data must be stored / prepared for
writing to flash).
Best regards,
Martin
--- In l..., "rfkd07" wrote:
>
>
>
> Hello,
>
> does anybody have any news here? I did some similar tests on an LPC1768 (32K+16K+16K internal SRAM) and wrote a 32 byte pattern to the following addresses:
>
> 0x10000000 - Start of SRAM (size 32K)
> 0x10007FDF - End of SRAM (-32 bytes)
> 0x2007C000 - Start of AHB SRAM 1 (size 16K)
> 0x2007FFDF - End of AHB SRAM 1 (-32 bytes)
> 0x20080000 - Start of AHB SRAM 2 (size 16K)
> 0x20083FDF - End of AHB SRAM 2 (-32 bytes)
>
> The IAP functions I used were PREPARE_SECTORS and ERASE_SECTORS. Using JTAG-debugging I verified that the patterns on all addresses from above remain the same before and after the IAP calls.
>
> So where exactly are the "32 bytes of space in the top portion of the on-chip RAM" as UM10360 states in chapter 32? I don't really want to ignore this...
>
> Best regards,
> Ralf
>
>
> --- In l..., "mjbcswitzerland" wrote:
> >
> > Hi Alexandre
> >
> > Thanks for the idea - I will give this a try the next time that I am working with the board.
> >
> > Regards
> >
> > Mark
> >
> >
> > --- In l..., Alexandre Kremer wrote:
> > >
> > > Hi Mark
> > >
> > > I know you from the MCF5223X from freescale ;)
> > > Maybe the user manual refers to top portion of ram, the first bytes, not the last ones. Just a thought...and probably im wrong.
> > >
>
i would say the area is from
0x10007FE0 to 0x10007FFF.
Why have you left out the 32 bytes (especially in this area),
when you want explicitely test this area for changed memory ?
> 0x10000000 - Start of SRAM (size 32K)
> 0x10007FDF - End of SRAM (-32 bytes)
0x10000000 - Start of SRAM (size 32K)
0x10007FFF - End of SRAM
It could also be (but i am no expert in IAP, nor do i now
what IAP is exactly internally doing) that the memory is only
used for certain commands. Perhaps some IAP command don't touch
the area at all (e.g. if no data must be stored / prepared for
writing to flash).
Best regards,
Martin
--- In l..., "rfkd07" wrote:
>
>
>
> Hello,
>
> does anybody have any news here? I did some similar tests on an LPC1768 (32K+16K+16K internal SRAM) and wrote a 32 byte pattern to the following addresses:
>
> 0x10000000 - Start of SRAM (size 32K)
> 0x10007FDF - End of SRAM (-32 bytes)
> 0x2007C000 - Start of AHB SRAM 1 (size 16K)
> 0x2007FFDF - End of AHB SRAM 1 (-32 bytes)
> 0x20080000 - Start of AHB SRAM 2 (size 16K)
> 0x20083FDF - End of AHB SRAM 2 (-32 bytes)
>
> The IAP functions I used were PREPARE_SECTORS and ERASE_SECTORS. Using JTAG-debugging I verified that the patterns on all addresses from above remain the same before and after the IAP calls.
>
> So where exactly are the "32 bytes of space in the top portion of the on-chip RAM" as UM10360 states in chapter 32? I don't really want to ignore this...
>
> Best regards,
> Ralf
>
>
> --- In l..., "mjbcswitzerland" wrote:
> >
> > Hi Alexandre
> >
> > Thanks for the idea - I will give this a try the next time that I am working with the board.
> >
> > Regards
> >
> > Mark
> >
> >
> > --- In l..., Alexandre Kremer wrote:
> > >
> > > Hi Mark
> > >
> > > I know you from the MCF5223X from freescale ;)
> > > Maybe the user manual refers to top portion of ram, the first bytes, not the last ones. Just a thought...and probably im wrong.
> > >
>
Reply by ●August 25, 20112011-08-25
Hi:
As per the LPC1768 User Manual, Section 32.8:
"The flash memory is not accessible during a write or erase operation. IAP commands, which results in a flash write/erase operation, use 32 bytes of space in the top portion of the on-chip RAM for execution. The user program should not be use this space if IAP flash programming is permitted in the application."
Note the "which results in a flash write/erase operation" clarification.
Regards,
Alex R.
--- In l..., "capiman26061973" wrote:
>
>
>
> Hello Ralf,
>
> i would say the area is from
>
> 0x10007FE0 to 0x10007FFF.
>
> Why have you left out the 32 bytes (especially in this area),
> when you want explicitely test this area for changed memory ?
>
> > 0x10000000 - Start of SRAM (size 32K)
> > 0x10007FDF - End of SRAM (-32 bytes)
>
> 0x10000000 - Start of SRAM (size 32K)
> 0x10007FFF - End of SRAM
>
> It could also be (but i am no expert in IAP, nor do i now
> what IAP is exactly internally doing) that the memory is only
> used for certain commands. Perhaps some IAP command don't touch
> the area at all (e.g. if no data must be stored / prepared for
> writing to flash).
>
> Best regards,
>
> Martin
>
> --- In l..., "rfkd07" wrote:
> >
> >
> >
> > Hello,
> >
> > does anybody have any news here? I did some similar tests on an LPC1768 (32K+16K+16K internal SRAM) and wrote a 32 byte pattern to the following addresses:
> >
> > 0x10000000 - Start of SRAM (size 32K)
> > 0x10007FDF - End of SRAM (-32 bytes)
> > 0x2007C000 - Start of AHB SRAM 1 (size 16K)
> > 0x2007FFDF - End of AHB SRAM 1 (-32 bytes)
> > 0x20080000 - Start of AHB SRAM 2 (size 16K)
> > 0x20083FDF - End of AHB SRAM 2 (-32 bytes)
> >
> > The IAP functions I used were PREPARE_SECTORS and ERASE_SECTORS. Using JTAG-debugging I verified that the patterns on all addresses from above remain the same before and after the IAP calls.
> >
> > So where exactly are the "32 bytes of space in the top portion of the on-chip RAM" as UM10360 states in chapter 32? I don't really want to ignore this...
> >
> > Best regards,
> > Ralf
> >
> >
> > --- In l..., "mjbcswitzerland" wrote:
> > >
> > > Hi Alexandre
> > >
> > > Thanks for the idea - I will give this a try the next time that I am working with the board.
> > >
> > > Regards
> > >
> > > Mark
> > >
> > >
> > > --- In l..., Alexandre Kremer wrote:
> > > >
> > > > Hi Mark
> > > >
> > > > I know you from the MCF5223X from freescale ;)
> > > > Maybe the user manual refers to top portion of ram, the first bytes, not the last ones. Just a thought...and probably im wrong.
> > > >
> > >
>
As per the LPC1768 User Manual, Section 32.8:
"The flash memory is not accessible during a write or erase operation. IAP commands, which results in a flash write/erase operation, use 32 bytes of space in the top portion of the on-chip RAM for execution. The user program should not be use this space if IAP flash programming is permitted in the application."
Note the "which results in a flash write/erase operation" clarification.
Regards,
Alex R.
--- In l..., "capiman26061973" wrote:
>
>
>
> Hello Ralf,
>
> i would say the area is from
>
> 0x10007FE0 to 0x10007FFF.
>
> Why have you left out the 32 bytes (especially in this area),
> when you want explicitely test this area for changed memory ?
>
> > 0x10000000 - Start of SRAM (size 32K)
> > 0x10007FDF - End of SRAM (-32 bytes)
>
> 0x10000000 - Start of SRAM (size 32K)
> 0x10007FFF - End of SRAM
>
> It could also be (but i am no expert in IAP, nor do i now
> what IAP is exactly internally doing) that the memory is only
> used for certain commands. Perhaps some IAP command don't touch
> the area at all (e.g. if no data must be stored / prepared for
> writing to flash).
>
> Best regards,
>
> Martin
>
> --- In l..., "rfkd07" wrote:
> >
> >
> >
> > Hello,
> >
> > does anybody have any news here? I did some similar tests on an LPC1768 (32K+16K+16K internal SRAM) and wrote a 32 byte pattern to the following addresses:
> >
> > 0x10000000 - Start of SRAM (size 32K)
> > 0x10007FDF - End of SRAM (-32 bytes)
> > 0x2007C000 - Start of AHB SRAM 1 (size 16K)
> > 0x2007FFDF - End of AHB SRAM 1 (-32 bytes)
> > 0x20080000 - Start of AHB SRAM 2 (size 16K)
> > 0x20083FDF - End of AHB SRAM 2 (-32 bytes)
> >
> > The IAP functions I used were PREPARE_SECTORS and ERASE_SECTORS. Using JTAG-debugging I verified that the patterns on all addresses from above remain the same before and after the IAP calls.
> >
> > So where exactly are the "32 bytes of space in the top portion of the on-chip RAM" as UM10360 states in chapter 32? I don't really want to ignore this...
> >
> > Best regards,
> > Ralf
> >
> >
> > --- In l..., "mjbcswitzerland" wrote:
> > >
> > > Hi Alexandre
> > >
> > > Thanks for the idea - I will give this a try the next time that I am working with the board.
> > >
> > > Regards
> > >
> > > Mark
> > >
> > >
> > > --- In l..., Alexandre Kremer wrote:
> > > >
> > > > Hi Mark
> > > >
> > > > I know you from the MCF5223X from freescale ;)
> > > > Maybe the user manual refers to top portion of ram, the first bytes, not the last ones. Just a thought...and probably im wrong.
> > > >
> > >
>
Reply by ●September 1, 20112011-09-01
Hello Martin,
> Why have you left out the 32 bytes (especially in this area),
> when you want explicitely test this area for changed memory ?
maybe I was not clear enough. In my former post I described the addresses where I started to write the 32 byte data pattern at. So actually I wrote the pattern from 0x10000000 to 0x10000020, from 0x10007FDF to 0x10007FFF and so on.
Furthermore I did some additional tests with the COPY_RAM_TO_FLASH command - I copied 256 bytes of RAM to the last sector of my LPC1768. Again, the patterns at *ALL* addresses remain unchanged (the IAP function succeeded of course).
Best regards,
Ralf
--- In l..., "capiman26061973" wrote:
>
>
>
> Hello Ralf,
>
> i would say the area is from
>
> 0x10007FE0 to 0x10007FFF.
>
> Why have you left out the 32 bytes (especially in this area),
> when you want explicitely test this area for changed memory ?
>
> > 0x10000000 - Start of SRAM (size 32K)
> > 0x10007FDF - End of SRAM (-32 bytes)
>
> 0x10000000 - Start of SRAM (size 32K)
> 0x10007FFF - End of SRAM
>
> It could also be (but i am no expert in IAP, nor do i now
> what IAP is exactly internally doing) that the memory is only
> used for certain commands. Perhaps some IAP command don't touch
> the area at all (e.g. if no data must be stored / prepared for
> writing to flash).
>
> Best regards,
>
> Martin
>
> --- In l..., "rfkd07" wrote:
> >
> >
> >
> > Hello,
> >
> > does anybody have any news here? I did some similar tests on an LPC1768 (32K+16K+16K internal SRAM) and wrote a 32 byte pattern to the following addresses:
> >
> > 0x10000000 - Start of SRAM (size 32K)
> > 0x10007FDF - End of SRAM (-32 bytes)
> > 0x2007C000 - Start of AHB SRAM 1 (size 16K)
> > 0x2007FFDF - End of AHB SRAM 1 (-32 bytes)
> > 0x20080000 - Start of AHB SRAM 2 (size 16K)
> > 0x20083FDF - End of AHB SRAM 2 (-32 bytes)
> >
> > The IAP functions I used were PREPARE_SECTORS and ERASE_SECTORS. Using JTAG-debugging I verified that the patterns on all addresses from above remain the same before and after the IAP calls.
> >
> > So where exactly are the "32 bytes of space in the top portion of the on-chip RAM" as UM10360 states in chapter 32? I don't really want to ignore this...
> >
> > Best regards,
> > Ralf
> >
> >
> > --- In l..., "mjbcswitzerland" wrote:
> > >
> > > Hi Alexandre
> > >
> > > Thanks for the idea - I will give this a try the next time that I am working with the board.
> > >
> > > Regards
> > >
> > > Mark
> > >
> > >
> > > --- In l..., Alexandre Kremer wrote:
> > > >
> > > > Hi Mark
> > > >
> > > > I know you from the MCF5223X from freescale ;)
> > > > Maybe the user manual refers to top portion of ram, the first bytes, not the last ones. Just a thought...and probably im wrong.
> > > >
> > >
>
> Why have you left out the 32 bytes (especially in this area),
> when you want explicitely test this area for changed memory ?
maybe I was not clear enough. In my former post I described the addresses where I started to write the 32 byte data pattern at. So actually I wrote the pattern from 0x10000000 to 0x10000020, from 0x10007FDF to 0x10007FFF and so on.
Furthermore I did some additional tests with the COPY_RAM_TO_FLASH command - I copied 256 bytes of RAM to the last sector of my LPC1768. Again, the patterns at *ALL* addresses remain unchanged (the IAP function succeeded of course).
Best regards,
Ralf
--- In l..., "capiman26061973" wrote:
>
>
>
> Hello Ralf,
>
> i would say the area is from
>
> 0x10007FE0 to 0x10007FFF.
>
> Why have you left out the 32 bytes (especially in this area),
> when you want explicitely test this area for changed memory ?
>
> > 0x10000000 - Start of SRAM (size 32K)
> > 0x10007FDF - End of SRAM (-32 bytes)
>
> 0x10000000 - Start of SRAM (size 32K)
> 0x10007FFF - End of SRAM
>
> It could also be (but i am no expert in IAP, nor do i now
> what IAP is exactly internally doing) that the memory is only
> used for certain commands. Perhaps some IAP command don't touch
> the area at all (e.g. if no data must be stored / prepared for
> writing to flash).
>
> Best regards,
>
> Martin
>
> --- In l..., "rfkd07" wrote:
> >
> >
> >
> > Hello,
> >
> > does anybody have any news here? I did some similar tests on an LPC1768 (32K+16K+16K internal SRAM) and wrote a 32 byte pattern to the following addresses:
> >
> > 0x10000000 - Start of SRAM (size 32K)
> > 0x10007FDF - End of SRAM (-32 bytes)
> > 0x2007C000 - Start of AHB SRAM 1 (size 16K)
> > 0x2007FFDF - End of AHB SRAM 1 (-32 bytes)
> > 0x20080000 - Start of AHB SRAM 2 (size 16K)
> > 0x20083FDF - End of AHB SRAM 2 (-32 bytes)
> >
> > The IAP functions I used were PREPARE_SECTORS and ERASE_SECTORS. Using JTAG-debugging I verified that the patterns on all addresses from above remain the same before and after the IAP calls.
> >
> > So where exactly are the "32 bytes of space in the top portion of the on-chip RAM" as UM10360 states in chapter 32? I don't really want to ignore this...
> >
> > Best regards,
> > Ralf
> >
> >
> > --- In l..., "mjbcswitzerland" wrote:
> > >
> > > Hi Alexandre
> > >
> > > Thanks for the idea - I will give this a try the next time that I am working with the board.
> > >
> > > Regards
> > >
> > > Mark
> > >
> > >
> > > --- In l..., Alexandre Kremer wrote:
> > > >
> > > > Hi Mark
> > > >
> > > > I know you from the MCF5223X from freescale ;)
> > > > Maybe the user manual refers to top portion of ram, the first bytes, not the last ones. Just a thought...and probably im wrong.
> > > >
> > >
>
