I have measured the time it takes for the IAP to erase one 4kB sector and it was 400ms. The processor is being clocked with a 14.74MHz chrystal, 1x multiplier, no MAM. No interrupts whatsoever. Activating the PLL and MAM made no difference. I configured the CCLK to 4x and then the delay dropped to 100ms (note: the CCLK argument to IAP was changed accordingly). Then I changed the CCLK argument passed to the IAP to a fraction of the real value and it worked up to around 1/50th of CCLK and the delay dropped to around 8 ms. Using CCLK/20 makes the delay to be 20ms which is seems much more reasonable to me than 400ms to erase a block. However it is a workaround and I am not sure I can leave it like this. Writing 4kB of data to the same block takes 22ms. I tested it with two differenc uC, LPC2136 and LPC2138 with the very same results. Using IAR EWB 4.20A. Boot code is 0x20B for the LPC2138 and 0x20C for the LPC2136. What could I be missing? I carefully inspected the code (it was written by another person) and the relevant parts comply with the manual. The manual does not say anything about IAP timings and how it measures timings. Thanks for listening and thanks in advance for any hint.
LPC21xx IAP erase time too long
Started by ●July 1, 2009
Reply by ●July 1, 20092009-07-01
On Wed, 1 Jul 2009 10:17:24 -0700 (PDT), "Elder Costa ih8sp4m@yahoo.com" <ih8sp4m@yahoo.com> wrote:>I have measured the time it takes for the IAP to erase one 4kB sector >and it was 400ms. The processor is being clocked with a 14.74MHz >chrystal, 1x multiplier, no MAM. No interrupts whatsoever. Activating >the PLL and MAM made no difference. > >I configured the CCLK to 4x and then the delay dropped to 100ms (note: >the CCLK argument to IAP was changed accordingly). Then I changed the >CCLK argument passed to the IAP to a fraction of the real value and it >worked up to around 1/50th of CCLK and the delay dropped to around 8 >ms. Using CCLK/20 makes the delay to be 20ms which is seems much more >reasonable to me than 400ms to erase a block. However it is a >workaround and I am not sure I can leave it like this. Writing 4kB of >data to the same block takes 22ms.Can you read it back with no errors?>I tested it with two differenc uC, LPC2136 and LPC2138 with the very >same results. Using IAR EWB 4.20A. Boot code is 0x20B for the LPC2138 >and 0x20C for the LPC2136. > >What could I be missing?That you may be violating the specs of the flash memory chip. The datasheet for the LPC21xx family cites a 400ms sector erase time. I haven't used these chips so I don't know if it's safe to meddle with the flash memory timing.>I carefully inspected the code (it was >written by another person) and the relevant parts comply with the >manual. The manual does not say anything about IAP timings and how it >measures timings. > >Thanks for listening and thanks in advance for any hint.George
Reply by ●July 1, 20092009-07-01
On Jul 1, 2:59=A0pm, George Neuner <gneun...@comcast.net> wrote:> Can you read it back with no errors?Yes.> > That you may be violating the specs of the flash memory chip. =A0The > datasheet for the LPC21xx family cites a 400ms sector erase time. >That's it! I completely missed it. Now that you told it I could find the information in that cr@appy data sheet (the chip is also cr@appy IMO). I did not expect to find relevant information in the introductory section that would be missing the the technical ones as introductions usally have marketing yaga yaga. And the user manual completely omits such an important information (@#$%&*!). I will recomend future designs keep away from these chips. Thank you very much. My best regars. Elder.
Reply by ●July 1, 20092009-07-01
On Wed, 1 Jul 2009 11:12:16 -0700 (PDT), ih8sp4m@yahoo.com wrote:>On Jul 1, 2:59�pm, George Neuner <gneun...@comcast.net> wrote: >> Can you read it back with no errors? >Yes. > >> >> That you may be violating the specs of the flash memory chip. �The >> datasheet for the LPC21xx family cites a 400ms sector erase time. >> > >That's it! I completely missed it. Now that you told it I could find >the information in that cr@appy data sheet (the chip is also cr@appy >IMO). I did not expect to find relevant information in the >introductory section that would be missing the the technical ones as >introductions usally have marketing yaga yaga. And the user manual >completely omits such an important information (@#$%&*!). I will >recomend future designs keep away from these chips. > >Thank you very much. > >My best regars. > >Elder.The chips are generally fine, but the datasheets & user manuals need very careful reading - in general everything is there but typically only precisely once, and not always in the most obvious place and not always cross-referenced from other places where it may be relevant . Docs for later chips seem a little better, e.g. the LPC2478 UM has a section at the start of peripheral chapters indicating register bits elsewhere that can affect that peripheral (e.g. powerdown bits)
Reply by ●July 2, 20092009-07-02
On Wed, 01 Jul 2009 23:44:26 +0100, Mike Harrison <mike@whitewing.co.uk> wrote:>On Wed, 1 Jul 2009 11:12:16 -0700 (PDT), ih8sp4m@yahoo.com wrote: > >>On Jul 1, 2:59�pm, George Neuner <gneun...@comcast.net> wrote: >>> Can you read it back with no errors? >>Yes. >> >>> >>> That you may be violating the specs of the flash memory chip. �The >>> datasheet for the LPC21xx family cites a 400ms sector erase time. >>>How large of a sector in this case ?>> >>That's it! I completely missed it. Now that you told it I could find >>the information in that cr@appy data sheet (the chip is also cr@appy >>IMO). I did not expect to find relevant information in the >>introductory section that would be missing the the technical ones as >>introductions usally have marketing yaga yaga. And the user manual >>completely omits such an important information (@#$%&*!). I will >>recomend future designs keep away from these chips. >> >>Thank you very much. >> >>My best regars. >> >>Elder. > >The chips are generally fine, but the datasheets & user manuals need very careful reading - in >general everything is there but typically only precisely once, and not always in the most obvious >place and not always cross-referenced from other places where it may be relevant . >Docs for later chips seem a little better, e.g. the LPC2478 UM has a section at the start of >peripheral chapters indicating register bits elsewhere that can affect that peripheral (e.g. >powerdown bits) > >Huh ? These are vey good parts actually (IMHO :) Who doesn't have documentation that could be better, though ? I find that the info is in the UM... Just gotta beware that it is there, somewhere and read very carefully. These are very complicated parts. (as parts these days can be) My product is user software updatable... The part updates in not too long of time, actually. The flash erasure seems fairly respectable to me. I tell you.... They're a LOT faster to program than the PSOCs which I hated to have to program (about 1 and 1/2 minute for 32K of flash) boB>
Reply by ●July 4, 20092009-07-04
On Jul 1, 11:12=A0am, ih8s...@yahoo.com wrote:> On Jul 1, 2:59=A0pm, George Neuner <gneun...@comcast.net> wrote:> Can you=read it back with no errors?> > Yes.Don't count on it for a long time as you are violating the spec!> > That you may be violating the specs of the flash memory chip. =A0The > > datasheet for the LPC21xx family cites a 400ms sector erase time. > > That's it! I completely missed it. Now that you told it I could find > the information in that cr@appy data sheet (the chip is also cr@appy > IMO).Relevant information is relative. If you are a hardware designer, all relevant information is in the datasheet, if you are a firmware programmer all relevant information is in the User's Manual at least that is the idea behind dividing them up in two separate documents. I did not expect to find relevant information in the> introductory section that would be missing the the technical ones as > introductions usally have marketing yaga yaga.Introduction sections contain so called key values, sometimes also called marketing yaga yaga :-)> And the user manual > completely omits such an important information (@#$%&*!). I will > recomend future designs keep away from these chips. > > Thank you very much. > > My best regars. > > Elder.You are upset because you missed some information that was not written in the particular chapter that you expected it to be. A simple google with the text "LPC2138 flash erase time" http://www.google.com/search?q=3DL= PC2138+flash+erase+time would have given all the information you need, so do not be mad about others, try to stay cool and think about all the options the internet and you pal Google provide to you. The LPC2000 family parts are rather nice, they are high performance within the ARM7 implementations, they are good price/performance and sometimes one or another engineer struggles with the documentation as you do with other devices as well. Try to see all the fun programming such nice MCUs and be happy! Cheers, An Schwob http://www.lpc2000.com
Reply by ●July 6, 20092009-07-06
On Jul 4, 2:46=A0am, An Schwob in USA <schwo...@aol.com> wrote:> Don't count on it for a long time as you are violating the spec!I will not. I will have to find a way to work around this (IMO serious) limitation by other means in my firmware and recommend future designs based on this chip (if any) use an external EEPROM or serial flash. We have had problems with this chip in the EMC (immunity related) camp so my annoyance is not only related to the docs and poor firmware (IMO) design.> Relevant information is relative. If you are a hardware designer, all > relevant information is in the datasheet, if you are a firmware > programmer all relevant information is in the User's Manual at least > that is the idea behind dividing them up in two separate documents.Try finding this particular information in the User's Manual, where it belongs IMO. :)> would have given all the information you need, so do not be mad about > others, try to stay cool and think about all the options the internet > and you pal Google provide to you.Still one cannot find where it should be. :) And again it should be in more than one place so that the hardware guys would be aware of the limitation (hopefully) and design the hw in a way the sw guys would not to make miracles for it to work well (though in this regard I have to admit I wanting too much ;-) .)> > The LPC2000 family parts are rather nice, they are high performance > within the ARM7 implementations, they are good price/performance and > sometimes one or another engineer struggles with the documentation as > you do with other devices as well.Agreed (partially.) :)
Reply by ●July 6, 20092009-07-06
On Jul 6, 2:30 pm, ih8s...@yahoo.com wrote:> On Jul 4, 2:46 am, An Schwob in USA <schwo...@aol.com> wrote:> Don't count on it for a long time as you are violating the spec! > > > Try finding this particular information in the User's Manual, where it > belongs IMO. :)It is mentioned in the User Manual. See page 3. http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/user.manual.lpc2131.lpc2132.lpc2134.lpc2136.lpc2138.pdf
