> 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. :)
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 An Schwob in USA●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 bob●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 Mike Harrison●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 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 George Neuner●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 Elde...@yahoo.com●July 1, 20092009-07-01
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.