We are a team of designers who have worked for many years on dev boards for
micro-controllers from various manufacturers: Analog Devices, Texas Instruments,
Freescale, Embedded Artists and recently Olimex. In July 2009 we bought a couple
of Olimex LPC-2378STK from the Italian distributor. The boards have been shipped
in identical boxes, bearing the words LPC-2378-STK-A. Inside the box the boards
were marked both as Olimex: LPC-2378-STK (C) 2008 Rev.C. So they looked
identical to us...
We began to develop firmware in late 2009 and early 2010 on one of two boards,
in order to adapt the FreeRTOS porting originally written for the Keil MCB2368
board, modifying it for the Olimex LPC2378-STK board. Mission successful: the
porting works.
Then, as per our policy, we repeated the same procedure on the other board:
nothing to do, exactly the same project was not working. After weeks of failed
attempts and many headaches, we have come to compare the 2 boards, chip by chip,
and then we have found the secret: on one board (the one that doesn't work)
is mounted an LPC2378 rev. '-' (i.e. before rev. 'A') while
on the other board (the one that is working) an LPC2378 rev. 'B'. It
may seem trivial but it is not, as we just discovered checking the document
LPC2378 Erratasheet from NXP
(http://ics.nxp.com/support/documents/microcontrollers/pdf/errata.lpc2378.pdf):
the review '-' has several bugs that were fixed in later revisions (in
2007 NXP has already shipped the 'B' rev., in 2009 the 'D'
rev.) Among the others, the MAC port management and MAM, strength of the LPC2000
series; we cannot use it on the review '-'. In practice, we bought two
different products that are presented as equal by Olimex; on each of them
it's necessary to write different instructions. Furthermore, when
we'll go into production with boards designed by us, we'll have to
rewrite the firmware again, because currently micros that are for sale (Digikey,
Farnell, etc, etc.) are, of course, in rev. 'D' (By the way, why did
we receive one '-' rev. and one 'B' rev. in July 2009 ?)
We asked our Italian reseller to exchange at least the rev. '-' board
with a rev. 'B' board, but the bare support was: "I suggest you apply
directly to Olimex".
The support from Olimex has been:
"We always are among the first who offer development boards with the newest
microcontrollers. This is what our customers expect from us, so we usually
receive among the first ICs which the silicon vendor produce. I hope you will
understand that we and all our distributors can't throw away in the garbage
can all the ICs and products we have each time NXP or somebody else change
revision from - to A, or from A to B. We can't do this nor we can control
what mix of boards are in our stock or in our distributors stock. I hope you
understand that every microcontroller have bugs, be sure even the revision D you
got have bugs and soon there will be revision E on the market.
Best regards
Tsvetan / Olimex"
The support from NXP has been:
"Sorry to hear you had to go through all this time and trouble. From NXP point
of view all i can say is that we try to make our devices bug free. So errata
fixes are always nicely documented and published. From the moment we have a new
revision we never produce or sell older rev parts.
However, It can happen that third party tool vendors and distributors still have
older stuff in stock, which they deliver.
So always check errata sheets and revisions . . ."
Regards,
Paul"
Moreover, having we taught last year the course "Microprocessors and
microcontrollers, SoC ARM", for the Master of Science in Electronic Engineering
at the Universitdegli Studi Roma Tre, we were assuming the use of LPC2378-STK
boards, but after that we can't: the students could receive many boards
mounting different micros.
It's a shame for the NXP Semiconductors; so much effort to bring the
LPC2378 from rev. '-' to rev. 'D', but customers are still
receiving rev. '-'.
Just to be clear, the biggest problem here is not to have the latest version of
the micro: we do not claim that. We just would like to know what we are going to
receive and we just would receive all boards with the same revision. We have
many developers working in a team and we can't afford a project made of
different firmware because of different boards. This is not for joke, it's
a matter of time-to-market.
Regards
eNGSistemi
i...@engsistemi.com
http://www.engsistemi.com
Bad support from Olimex: LPC-2378STK with various rev. micros
Started by ●March 20, 2010
Reply by ●March 20, 20102010-03-20
Hi,
> Just to be clear, the biggest problem here is not to have the latest
> version of the micro: we do not claim that. We just would like to know
> what we are going to receive and we just would receive all boards with
> the same revision. We have many developers working in a team and we
> can't afford a project made of different firmware because of different
> boards. This is not for joke, it's a matter of time-to-market.
I believe you will find that there are still Keil board in the channel
that have rev '-' devices on them. That happened to us last year with a
customer.
ALWAYS CHECK THE SILICON REVISION OF YOUR BOARDS; NEVER ASSUME THE BOARD
YOU ORDER WILL HAVE THE LATEST REVISION OF SILICON.
The guys at lpctools were shipping Keil boards with rev '-' silicon and
then bundling in a free rev 'B' part so you could "just swap them over".
Great for those that can, but I can't do that.
I don't think it's unreasonable of Tsvetan to decline to change the board
as his contract is with the distributor, not you directly; I assume you
did specify the revision of the chip to use in your order? It is up to
the distributor to smooth the situation, if they wish to.
I have a lot of boards that purport to be the same with different chip
revisions on them. Everybody was wanting LPC2300 when they came out and
were delayed, and buggy, and were happy to take rev '-' parts. I believe
the MAM problems were actually exposed in a great piece of detective work
by a group member here. And I've suffered from an errata on the 2148 that
wasn't documented, but is now. Now we specify particular chip revisions
when ordering parts.
You just need to take this stuff on the chin as part of uC life. NXP
would get slated if they didn't work to correct bugs, and because they do,
you have different chip revisions to work with and that are on eval boards
in the channel.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!
> Just to be clear, the biggest problem here is not to have the latest
> version of the micro: we do not claim that. We just would like to know
> what we are going to receive and we just would receive all boards with
> the same revision. We have many developers working in a team and we
> can't afford a project made of different firmware because of different
> boards. This is not for joke, it's a matter of time-to-market.
I believe you will find that there are still Keil board in the channel
that have rev '-' devices on them. That happened to us last year with a
customer.
ALWAYS CHECK THE SILICON REVISION OF YOUR BOARDS; NEVER ASSUME THE BOARD
YOU ORDER WILL HAVE THE LATEST REVISION OF SILICON.
The guys at lpctools were shipping Keil boards with rev '-' silicon and
then bundling in a free rev 'B' part so you could "just swap them over".
Great for those that can, but I can't do that.
I don't think it's unreasonable of Tsvetan to decline to change the board
as his contract is with the distributor, not you directly; I assume you
did specify the revision of the chip to use in your order? It is up to
the distributor to smooth the situation, if they wish to.
I have a lot of boards that purport to be the same with different chip
revisions on them. Everybody was wanting LPC2300 when they came out and
were delayed, and buggy, and were happy to take rev '-' parts. I believe
the MAM problems were actually exposed in a great piece of detective work
by a group member here. And I've suffered from an errata on the 2148 that
wasn't documented, but is now. Now we specify particular chip revisions
when ordering parts.
You just need to take this stuff on the chin as part of uC life. NXP
would get slated if they didn't work to correct bugs, and because they do,
you have different chip revisions to work with and that are on eval boards
in the channel.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!
Reply by ●March 20, 20102010-03-20
Greetings all,
You got my attention by mentioning LPC2148. What's the clue to
matching revision numbers with errata sheets?
I've been experiencing problems recently with LPC2148 chips that have
one or two bad pin functions and don't know if it's our handling
processes or bad chips.
Thanks,
DaveS
On Sat, Mar 20, 2010 at 3:15 AM, Paul Curtis wrote:
> Hi,
>
>> Just to be clear, the biggest problem here is not to have the latest
>> version of the micro: we do not claim that. We just would like to know
>> what we are going to receive and we just would receive all boards with
>> the same revision. We have many developers working in a team and we
>> can't afford a project made of different firmware because of different
>> boards. This is not for joke, it's a matter of time-to-market.
>
> I believe you will find that there are still Keil board in the channel
> that have rev '-' devices on them. That happened to us last year with a
> customer.
>
> ALWAYS CHECK THE SILICON REVISION OF YOUR BOARDS; NEVER ASSUME THE BOARD
> YOU ORDER WILL HAVE THE LATEST REVISION OF SILICON.
>
> The guys at lpctools were shipping Keil boards with rev '-' silicon and
> then bundling in a free rev 'B' part so you could "just swap them over".
> Great for those that can, but I can't do that.
>
> I don't think it's unreasonable of Tsvetan to decline to change the board
> as his contract is with the distributor, not you directly; I assume you
> did specify the revision of the chip to use in your order? It is up to
> the distributor to smooth the situation, if they wish to.
>
> I have a lot of boards that purport to be the same with different chip
> revisions on them. Everybody was wanting LPC2300 when they came out and
> were delayed, and buggy, and were happy to take rev '-' parts. I believe
> the MAM problems were actually exposed in a great piece of detective work
> by a group member here. And I've suffered from an errata on the 2148 that
> wasn't documented, but is now. Now we specify particular chip revisions
> when ordering parts.
>
> You just need to take this stuff on the chin as part of uC life. NXP
> would get slated if they didn't work to correct bugs, and because they do,
> you have different chip revisions to work with and that are on eval boards
> in the channel.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!
>
You got my attention by mentioning LPC2148. What's the clue to
matching revision numbers with errata sheets?
I've been experiencing problems recently with LPC2148 chips that have
one or two bad pin functions and don't know if it's our handling
processes or bad chips.
Thanks,
DaveS
On Sat, Mar 20, 2010 at 3:15 AM, Paul Curtis wrote:
> Hi,
>
>> Just to be clear, the biggest problem here is not to have the latest
>> version of the micro: we do not claim that. We just would like to know
>> what we are going to receive and we just would receive all boards with
>> the same revision. We have many developers working in a team and we
>> can't afford a project made of different firmware because of different
>> boards. This is not for joke, it's a matter of time-to-market.
>
> I believe you will find that there are still Keil board in the channel
> that have rev '-' devices on them. That happened to us last year with a
> customer.
>
> ALWAYS CHECK THE SILICON REVISION OF YOUR BOARDS; NEVER ASSUME THE BOARD
> YOU ORDER WILL HAVE THE LATEST REVISION OF SILICON.
>
> The guys at lpctools were shipping Keil boards with rev '-' silicon and
> then bundling in a free rev 'B' part so you could "just swap them over".
> Great for those that can, but I can't do that.
>
> I don't think it's unreasonable of Tsvetan to decline to change the board
> as his contract is with the distributor, not you directly; I assume you
> did specify the revision of the chip to use in your order? It is up to
> the distributor to smooth the situation, if they wish to.
>
> I have a lot of boards that purport to be the same with different chip
> revisions on them. Everybody was wanting LPC2300 when they came out and
> were delayed, and buggy, and were happy to take rev '-' parts. I believe
> the MAM problems were actually exposed in a great piece of detective work
> by a group member here. And I've suffered from an errata on the 2148 that
> wasn't documented, but is now. Now we specify particular chip revisions
> when ordering parts.
>
> You just need to take this stuff on the chin as part of uC life. NXP
> would get slated if they didn't work to correct bugs, and because they do,
> you have different chip revisions to work with and that are on eval boards
> in the channel.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!
>
Reply by ●March 20, 20102010-03-20
On Sat, 20 Mar 2010 10:34:38 -0000, David Smead
wrote:
> Greetings all,
>
> You got my attention by mentioning LPC2148. What's the clue to
> matching revision numbers with errata sheets?
The errata sheets tell you how to identify which chip revision you have
from the markings on the chip.
Unfortunately, there's no guaranteed method to detect chip revision from
software.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!
wrote:
> Greetings all,
>
> You got my attention by mentioning LPC2148. What's the clue to
> matching revision numbers with errata sheets?
The errata sheets tell you how to identify which chip revision you have
from the markings on the chip.
Unfortunately, there's no guaranteed method to detect chip revision from
software.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!
Reply by ●March 20, 20102010-03-20
Hi Paul,
--- In l..., "Paul Curtis" wrote:
> ALWAYS CHECK THE SILICON REVISION OF YOUR BOARDS; NEVER ASSUME THE BOARD
> YOU ORDER WILL HAVE THE LATEST REVISION OF SILICON.
I just asked Farnell about Olimex rev. boards. They can't guarantee anything about revision of micros. It's always a surprise !
> The guys at lpctools were shipping Keil boards with rev '-' silicon and
> then bundling in a free rev 'B' part so you could "just swap them over".
> Great for those that can, but I can't do that.
Good to know, we are going to do that buying micros on DigiKey.
> I assume you
> did specify the revision of the chip to use in your order?
No we didn't, that's our fault.
Thanks for your suggestions.
We'll follow them.
Nicola
--- In l..., "Paul Curtis" wrote:
> ALWAYS CHECK THE SILICON REVISION OF YOUR BOARDS; NEVER ASSUME THE BOARD
> YOU ORDER WILL HAVE THE LATEST REVISION OF SILICON.
I just asked Farnell about Olimex rev. boards. They can't guarantee anything about revision of micros. It's always a surprise !
> The guys at lpctools were shipping Keil boards with rev '-' silicon and
> then bundling in a free rev 'B' part so you could "just swap them over".
> Great for those that can, but I can't do that.
Good to know, we are going to do that buying micros on DigiKey.
> I assume you
> did specify the revision of the chip to use in your order?
No we didn't, that's our fault.
Thanks for your suggestions.
We'll follow them.
Nicola
Reply by ●March 20, 20102010-03-20
I guess I missed something! How is it "Bad support from Olimex"? They buy some
chips, build some boards and send them down the pipeline. They buy some more
chips, build some more boards and send them along as well. That NXP changes the
chip revision level is hardly the fault of Olimex and Olimex could hardly
justify trying to purchase 'down-level' chips just to maintain
backwards compatibility.
If the chips were right in the first place, there wouldn't be so many revisions. It seems to me the problems are created by NXP in their rush to market.
Let me phrase the problem differently: why would anybody design in a rev '-' chip when they can predict with near certainty that there will be a rev 'D' in the near future? That's the whole problem with 'bleeding edge' technology. Let the chip mature in the marketplace by a year or so. Let other developers discover the glitches.
If it weren't for Olimex boards, I wouldn't be able to play with any of this technology. It certainly isn't feasible to build one-off PCBs for each of the various devices of interest.
Richard
If the chips were right in the first place, there wouldn't be so many revisions. It seems to me the problems are created by NXP in their rush to market.
Let me phrase the problem differently: why would anybody design in a rev '-' chip when they can predict with near certainty that there will be a rev 'D' in the near future? That's the whole problem with 'bleeding edge' technology. Let the chip mature in the marketplace by a year or so. Let other developers discover the glitches.
If it weren't for Olimex boards, I wouldn't be able to play with any of this technology. It certainly isn't feasible to build one-off PCBs for each of the various devices of interest.
Richard
Reply by ●March 20, 20102010-03-20
--- In l..., "rtstofer" wrote:
>
> I guess I missed something!
May be...
> They buy some chips, build some boards and send them down the pipeline.
Yes, and we suppose they received all micros at the same rev. level. So, they could mark their boards with a unique rev. ID.
> They buy some more chips, build some more boards and send them along as well.
Ok, if they just changed the boards rev. ID, all customers could know that.
>Let the chip mature in the marketplace by a year or so. Let other developers discover the glitches.
Let's do a brief calculus: from 2007 (B rev. from NXP) to 2009 (Olimex boards sold to us), that is... 2 years !
Is it enough time to receive B rev. micros ?
> If it weren't for Olimex boards, I wouldn't be able to play with any of this technology.
We were used to buy from many other vendors. Never found these problems: we need clear documentation and transparency.
As we do for our customers; they too expect from us repeatable products, not a mixture of features.
engsistemi
>
> I guess I missed something!
May be...
> They buy some chips, build some boards and send them down the pipeline.
Yes, and we suppose they received all micros at the same rev. level. So, they could mark their boards with a unique rev. ID.
> They buy some more chips, build some more boards and send them along as well.
Ok, if they just changed the boards rev. ID, all customers could know that.
>Let the chip mature in the marketplace by a year or so. Let other developers discover the glitches.
Let's do a brief calculus: from 2007 (B rev. from NXP) to 2009 (Olimex boards sold to us), that is... 2 years !
Is it enough time to receive B rev. micros ?
> If it weren't for Olimex boards, I wouldn't be able to play with any of this technology.
We were used to buy from many other vendors. Never found these problems: we need clear documentation and transparency.
As we do for our customers; they too expect from us repeatable products, not a mixture of features.
engsistemi
Reply by ●March 20, 20102010-03-20
On Sat, Mar 20, 2010 at 6:37 PM, Eng wrote:
> --- In l... , "rtstofer"
> wrote:
> >
> > I guess I missed something!
> May be...
>
> > They buy some chips, build some boards and send them down the pipeline.
> Yes, and we suppose they received all micros at the same rev. level. So,
> they could mark their boards with a unique rev. ID.
>
I had the exact same problem with Olimex in September last year, when I
ordered two STR-E912 boards from them, and they sent one with an obsolete
STR912FW44 chip (quite a buggy silicon) instead of the current, in
production revision (STR912FAW44). One could probably argue that I didn't
ask for a specific version of the chip, but I must admit that I didn't even
consider that they'll use a chip declared obsolete by the manufacturer. So,
you're not the only one with this problem ...
Best,
Bogdan
> --- In l... , "rtstofer"
> wrote:
> >
> > I guess I missed something!
> May be...
>
> > They buy some chips, build some boards and send them down the pipeline.
> Yes, and we suppose they received all micros at the same rev. level. So,
> they could mark their boards with a unique rev. ID.
>
I had the exact same problem with Olimex in September last year, when I
ordered two STR-E912 boards from them, and they sent one with an obsolete
STR912FW44 chip (quite a buggy silicon) instead of the current, in
production revision (STR912FAW44). One could probably argue that I didn't
ask for a specific version of the chip, but I must admit that I didn't even
consider that they'll use a chip declared obsolete by the manufacturer. So,
you're not the only one with this problem ...
Best,
Bogdan
Reply by ●March 20, 20102010-03-20
--- In l..., "Eng" wrote:
>
> We were used to buy from many other vendors. Never found these problems: we need clear documentation and transparency.
> As we do for our customers; they too expect from us repeatable products, not a mixture of features.
>
> engsistemi
>
If your other vendors don't have these issues, why are you buying from Olimex and/or NXP? This has come up before with many suggestions to use other chip manufacturers. Personally, I don't believe for a minute that another manufacturer is any better but I haven't tried them all.
An Olimex board revision level doesn't necessarily imply a chip revision. Nor does a change in chip revision necessarily imply a board revision. In my view they are separate issues.
But how hard is it to look at the chip and see the revision letter?
What is really funny is that, given the hundreds of registers in a chip, there isn't one where you can easily get revision information and make the software adaptive. How hard can it be?
You're right about the revision calculus. So why are you using a chip that is less than 5 years old? Of course, if you wait for the final revision you will also receive the end-of-life notice.
Everybody wants to be on the 'bleeding-edge' but nobody wants to bleed!
Richard
>
> We were used to buy from many other vendors. Never found these problems: we need clear documentation and transparency.
> As we do for our customers; they too expect from us repeatable products, not a mixture of features.
>
> engsistemi
>
If your other vendors don't have these issues, why are you buying from Olimex and/or NXP? This has come up before with many suggestions to use other chip manufacturers. Personally, I don't believe for a minute that another manufacturer is any better but I haven't tried them all.
An Olimex board revision level doesn't necessarily imply a chip revision. Nor does a change in chip revision necessarily imply a board revision. In my view they are separate issues.
But how hard is it to look at the chip and see the revision letter?
What is really funny is that, given the hundreds of registers in a chip, there isn't one where you can easily get revision information and make the software adaptive. How hard can it be?
You're right about the revision calculus. So why are you using a chip that is less than 5 years old? Of course, if you wait for the final revision you will also receive the end-of-life notice.
Everybody wants to be on the 'bleeding-edge' but nobody wants to bleed!
Richard
Reply by ●March 20, 20102010-03-20
On Sat, 20 Mar 2010 17:33:49 -0000, rtstofer wrote:
> Everybody wants to be on the 'bleeding-edge' but nobody wants to bleed!
Absolutely--spot on! Well said.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!
> Everybody wants to be on the 'bleeding-edge' but nobody wants to bleed!
Absolutely--spot on! Well said.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!
