Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

re: read wrong part id of lpc2136

2006-03-27 by Jayasooriah

Hello,

Consider results for LPC2292 I just did to test out your proposition:

The code I used to test this out is as follows:

>         ldr     r1, =0x3fff8000
>         ldr     r0, =0x0401ff13
>         str     r0, [r1, #0]

The part ID for LPC2292 is 0x0401ff13.  The table below gives the max ROM 
and RAM addresses I get when I changed the each of the last two digits of 
part ID as follows:

>Part Id   ROM lim    RAM lim
>
>0401ff13  0003ffff   40003fff
>
>0401ff12  0001ffff   40003fff
>0401ff11  0000ffff   40003fff
>0401ff10  00007fff   40003fff
>
>0401ff03  0003ffff   40001fff

The fist one is with the correct part ID.  The next three show how ROM is 
reduced by changing the last digit.  The last one shows how RAM is reduced 
by changing the last second digit.

--- In lpc2000@yahoogroups.com, "derbaier" <dershu@...> wrote:
 >
 > --- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@> wrote:
 > >
 > > Dave,
 > >
 > > An alternative scenario (that was suggested by a foundry expert I
 > spoke to
 > > when I first discovered this) is more plausible for the following
 > reasons:
 > >
 > > 1/  The boot loader does not select good segment(s) for RAM or ROM.  It
 > > only limits their sizes by reducing the respective bound.  In other
 > words
 > > the boot loader does not set or change the base.
 >
 >
 > That particular assertion would be much more assuring if it was coming
 > from Phillip's.   As for size limiting, of course the FLASH address
 > decoder requires some remapping, but if that is implemented in FLASH
 > itself that is really trivial.

Philips has not commented on this issue when I first raised it.  It was 
left to the rest of us who do not know authoritatively what happens in the 
boot loader to debate on possible scenarios.

 > > 2/  It is very unusual to use this method (of selecting using bound
 > only)
 > > to improve yield.
 >
 > Selecting bounds only would be practically useless, since error
 > segments are randomly located. The FLASH address decoder also needs
 > adjustment. However, remapping FLASH segments during prepackaging
 > tests is a very routine operation.

There seems to be nothing more than just the loading of the part ID to the 
special address that does the trick.  The same pattern for ROM also exists 
for RAM.

Thus I do not think any flash decoder operations are involved.

Regards,

Jaya

Send instant messages to your online friends http://au.messenger.yahoo.com

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.