The NXP site suggests that only the /01 versions of the part have Fast IO
(FIO)and Fractional Baud Rate Generator(FBRG) included.
http://www.nxp.com/#/pip/pip=[pip=LPC2131_32_34_36_38_4]|pp=[t=pip,i=LPC2131_32_34_36_38_4]
I have a non /01 part LPC2138FBD64 - Datecode 0634 Rev C - and it does seem to
have FIO and FBRG functional.
Does anyone know just when the features were added to the silicon, and if -
although they appear to function on this part - perhaps they are potentially
buggy or unreliable.
(I have no reason to suspect this - except general wariness of undocumented
features)
A lot of boards you can buy for the 2138 are populated with the older part! Not
many manufacturers make the /01 distinction!
R
LPC2138 /01 and Non/01 versions
Started by ●January 30, 2010
Reply by ●January 31, 20102010-01-31
Greetings:
Take a look at the LPC2138 errata sheet.
As I recall there was a problem with the power on reset function
within the pre /01 version which resulted in the need for an external
POR chip.
--
Best Regards,
Tom Alldread
t...@telus.net
Take a look at the LPC2138 errata sheet.
As I recall there was a problem with the power on reset function
within the pre /01 version which resulted in the need for an external
POR chip.
--
Best Regards,
Tom Alldread
t...@telus.net
Reply by ●February 2, 20102010-02-02
Thanks Tom,
Its not an issue of the Errata - where the function doesn't meet the data sheet, its sort of the opposite, where the silicon has stuff the data sheet doesn't admit to.
For the 2138 - Errata sheets show Rev A,B,C,D for the non /01 part.
The /01 Errata sheet shows Rev D,E for the /01 Part.
The point is - I have a Rev C part - which has the /01 Peripherals functional??
Significance of this, is that a lot of boards available on the market have 'old' chips in them, but how old is 'too old'.
I currently use a commercial board with LPC2294 on it - and have to change out the processor to get FIO, Frac BaudRate and Enhanced SSP.
I expect - from the chip markings that I would have to do this for the LPC2138 as well - but seem not need to.
Has anyone else had this experience, or have people just "not noticed" the lack of /01 marking?
- If anyone from NXP is monitoring, could you comment?
R
Its not an issue of the Errata - where the function doesn't meet the data sheet, its sort of the opposite, where the silicon has stuff the data sheet doesn't admit to.
For the 2138 - Errata sheets show Rev A,B,C,D for the non /01 part.
The /01 Errata sheet shows Rev D,E for the /01 Part.
The point is - I have a Rev C part - which has the /01 Peripherals functional??
Significance of this, is that a lot of boards available on the market have 'old' chips in them, but how old is 'too old'.
I currently use a commercial board with LPC2294 on it - and have to change out the processor to get FIO, Frac BaudRate and Enhanced SSP.
I expect - from the chip markings that I would have to do this for the LPC2138 as well - but seem not need to.
Has anyone else had this experience, or have people just "not noticed" the lack of /01 marking?
- If anyone from NXP is monitoring, could you comment?
R
Reply by ●February 2, 20102010-02-02
> Thanks Tom,
>
> Its not an issue of the Errata - where the function doesn't meet the data sheet, its sort of the opposite, where the silicon has stuff the data sheet doesn't admit to.
>
> For the 2138 - Errata sheets show Rev A,B,C,D for the non /01 part.
> The /01 Errata sheet shows Rev D,E for the /01 Part.
>
> The point is - I have a Rev C part - which has the /01 Peripherals functional??
>
> Significance of this, is that a lot of boards available on the market have 'old' chips in them, but how old is 'too old'.
>
> I currently use a commercial board with LPC2294 on it - and have to change out the processor to get FIO, Frac BaudRate and Enhanced SSP.
> I expect - from the chip markings that I would have to do this for the LPC2138 as well - but seem not need to.
>
> Has anyone else had this experience, or have people just "not noticed" the lack of /01 marking?
> - If anyone from NXP is monitoring, could you comment?
>
> R
>
Let me give it a shot,
there are bills of materials out there that specify a LPC2138 to be used and there are other bills of materials out there that specify a LPC2138/01 to be used in another application. Here is what MIGHT have happened.
It does not make any sense at all for NXP to produce an older somewhat buggy silicon if a newer, much better die is available. So, inside the LPC2138 you will find the same silicon that is inside the LPC2138/01 because NXP tested compatibility exhaustively and did not find a reason why not to replace the old silicon with a better one.
If this internal switch happened and when, who am I to know?
I am not from NXP just knowledgeable how these things are handled in the industry.
Bob
>
> Its not an issue of the Errata - where the function doesn't meet the data sheet, its sort of the opposite, where the silicon has stuff the data sheet doesn't admit to.
>
> For the 2138 - Errata sheets show Rev A,B,C,D for the non /01 part.
> The /01 Errata sheet shows Rev D,E for the /01 Part.
>
> The point is - I have a Rev C part - which has the /01 Peripherals functional??
>
> Significance of this, is that a lot of boards available on the market have 'old' chips in them, but how old is 'too old'.
>
> I currently use a commercial board with LPC2294 on it - and have to change out the processor to get FIO, Frac BaudRate and Enhanced SSP.
> I expect - from the chip markings that I would have to do this for the LPC2138 as well - but seem not need to.
>
> Has anyone else had this experience, or have people just "not noticed" the lack of /01 marking?
> - If anyone from NXP is monitoring, could you comment?
>
> R
>
Let me give it a shot,
there are bills of materials out there that specify a LPC2138 to be used and there are other bills of materials out there that specify a LPC2138/01 to be used in another application. Here is what MIGHT have happened.
It does not make any sense at all for NXP to produce an older somewhat buggy silicon if a newer, much better die is available. So, inside the LPC2138 you will find the same silicon that is inside the LPC2138/01 because NXP tested compatibility exhaustively and did not find a reason why not to replace the old silicon with a better one.
If this internal switch happened and when, who am I to know?
I am not from NXP just knowledgeable how these things are handled in the industry.
Bob
Reply by ●February 2, 20102010-02-02
What I am getting at is - there are several possible development paths that
might have taken place, e.g.
Rev A : Initial Release
Rev B : Fixed some defects
Rev C : Added prototype /01 Silicon - All buggy /01 features not released - Fixed some /00 defects
Rev D : Altered /01 Silicon still not to Spec /01 features not released - fixed some more /00 Defects
-- Announce /01 Part
Rev E : /01 Functions now stable and ready for release as /01 marked part - fixed some more /00 Defects
Rev F : Fixed some more problems
-OR-
Rev A : Initial Release
Rev B : Fixed some defects
Rev C : Added prototype /01 Silicon 100% functional, Fixed some /00 defects
Rev D : Fixed some more /00 Defects
-- Announce /01 Part
Rev E : /01 Functions released - fixed some more /00 Defects
Rev F : Fixed some more problems
In the first case - using the features that certainly exist in a RevC part would not be wise. In the second case one would be more comfortable.
I guess I was looking for any stories of people getting away with it - or getting bitten.
I presume NXP would be playing it safe and saying that code used in a non /01 part should not try and access extra functionality of the /01
- (No Brainer really!)
R
Rev A : Initial Release
Rev B : Fixed some defects
Rev C : Added prototype /01 Silicon - All buggy /01 features not released - Fixed some /00 defects
Rev D : Altered /01 Silicon still not to Spec /01 features not released - fixed some more /00 Defects
-- Announce /01 Part
Rev E : /01 Functions now stable and ready for release as /01 marked part - fixed some more /00 Defects
Rev F : Fixed some more problems
-OR-
Rev A : Initial Release
Rev B : Fixed some defects
Rev C : Added prototype /01 Silicon 100% functional, Fixed some /00 defects
Rev D : Fixed some more /00 Defects
-- Announce /01 Part
Rev E : /01 Functions released - fixed some more /00 Defects
Rev F : Fixed some more problems
In the first case - using the features that certainly exist in a RevC part would not be wise. In the second case one would be more comfortable.
I guess I was looking for any stories of people getting away with it - or getting bitten.
I presume NXP would be playing it safe and saying that code used in a non /01 part should not try and access extra functionality of the /01
- (No Brainer really!)
R
Reply by ●February 2, 20102010-02-02
--- In l..., "technicalimages" wrote:
>
> I guess I was looking for any stories of people getting away with it - or getting bitten.
>
> I presume NXP would be playing it safe and saying that code used in a non /01 part should not try and access extra functionality of the /01
> - (No Brainer really!)
>
Agreed. The knowledge that *some* had "got away with it" would not convince me it was safe. If some had "got bitten" that would convince me it was unsafe. The net conclusion is that if I wanted to play safe then I would not try and access the extra functionality,
Regards,
Chris
--
Chris Burrows
Armaide: LPCxxxx Development for Pascal Programmers
http://www.armaide.com
>
> I guess I was looking for any stories of people getting away with it - or getting bitten.
>
> I presume NXP would be playing it safe and saying that code used in a non /01 part should not try and access extra functionality of the /01
> - (No Brainer really!)
>
Agreed. The knowledge that *some* had "got away with it" would not convince me it was safe. If some had "got bitten" that would convince me it was unsafe. The net conclusion is that if I wanted to play safe then I would not try and access the extra functionality,
Regards,
Chris
--
Chris Burrows
Armaide: LPCxxxx Development for Pascal Programmers
http://www.armaide.com
Reply by ●February 3, 20102010-02-03
I've used a number of Olimex LPC2106 boards. I tried to find from them or a
stocking distributor boards built with a /01 rev chip to get the the
edge-triggered I/O pin interrupt, and other capabilities. It seems Olimex
hasn't done a build of these in years. I couldn't find such.
--- In l..., "cfbsoftware1" wrote:
>
> --- In l..., "technicalimages" wrote:
> >
> > I guess I was looking for any stories of people getting away with it - or getting bitten.
> >
> > I presume NXP would be playing it safe and saying that code used in a non /01 part should not try and access extra functionality of the /01
> > - (No Brainer really!)
> > Agreed. The knowledge that *some* had "got away with it" would not convince me it was safe. If some had "got bitten" that would convince me it was unsafe. The net conclusion is that if I wanted to play safe then I would not try and access the extra functionality,
>
> Regards,
> Chris
>
> --
> Chris Burrows
> Armaide: LPCxxxx Development for Pascal Programmers
> http://www.armaide.com
>
--- In l..., "cfbsoftware1" wrote:
>
> --- In l..., "technicalimages" wrote:
> >
> > I guess I was looking for any stories of people getting away with it - or getting bitten.
> >
> > I presume NXP would be playing it safe and saying that code used in a non /01 part should not try and access extra functionality of the /01
> > - (No Brainer really!)
> > Agreed. The knowledge that *some* had "got away with it" would not convince me it was safe. If some had "got bitten" that would convince me it was unsafe. The net conclusion is that if I wanted to play safe then I would not try and access the extra functionality,
>
> Regards,
> Chris
>
> --
> Chris Burrows
> Armaide: LPCxxxx Development for Pascal Programmers
> http://www.armaide.com
>
Reply by ●February 3, 20102010-02-03
--- In l..., "stevec" wrote:
> I've used a number of Olimex LPC2106 boards. I tried to find from them or a stocking distributor boards built with a /01 rev chip to get the the edge-triggered I/O pin interrupt, and other capabilities. It seems Olimex hasn't done a build of these in years. I couldn't find such.
Steve,
that is not an exception, rather the rule. When a MCU is new everybody wants evaluation boards and there are not enough chips and boards. So the board vendor e.g. Olimex does everything to get their hands on chips early in the game. Suddenly the market is saturated and e.g. Olimex is sitting there with hundreds of boards with an older version of the chip. They will sell them over a long period of time and not manufacture a new batch because they are stranded with the boards hosting the old chips.
Unfortunately such is life.
Bob
> I've used a number of Olimex LPC2106 boards. I tried to find from them or a stocking distributor boards built with a /01 rev chip to get the the edge-triggered I/O pin interrupt, and other capabilities. It seems Olimex hasn't done a build of these in years. I couldn't find such.
Steve,
that is not an exception, rather the rule. When a MCU is new everybody wants evaluation boards and there are not enough chips and boards. So the board vendor e.g. Olimex does everything to get their hands on chips early in the game. Suddenly the market is saturated and e.g. Olimex is sitting there with hundreds of boards with an older version of the chip. They will sell them over a long period of time and not manufacture a new batch because they are stranded with the boards hosting the old chips.
Unfortunately such is life.
Bob
Reply by ●February 3, 20102010-02-03
On 03/02/2010 04:58, stevec wrote:
>
> I've used a number of Olimex LPC2106 boards. I tried to find from them or a stocking distributor boards built with a /01 rev chip to get the the edge-triggered I/O pin interrupt, and other capabilities. It seems Olimex hasn't done a build of these in years. I couldn't find such.
You could swap the chip for a new one. Chip Quik works very well for
removing chips without damaging the board.
Leon
>
> I've used a number of Olimex LPC2106 boards. I tried to find from them or a stocking distributor boards built with a /01 rev chip to get the the edge-triggered I/O pin interrupt, and other capabilities. It seems Olimex hasn't done a build of these in years. I couldn't find such.
You could swap the chip for a new one. Chip Quik works very well for
removing chips without damaging the board.
Leon
Reply by ●February 3, 20102010-02-03
Hi,
I've ported my bootloader from the LPC24xx family to the LPC17xx family
and encounter strange problems with uVision 4:
In my bootloader I check if the application (located at 0x6000) is ok
and jump to it as follows:
#define APP_START_ADDR 0x6000
typedef void (*APP_MAIN)(void);
static APP_MAIN app_main;
int main(void)
{
:
// checking app data area at 6000
:
if (app_data_ok)
{
app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
app_main();
}
}
This seems to work as expected (the application is build with a scatter
file loading all flash data at 0x6000, so the Reset_Handler in the
vector table at 0x6000 can be found on 0x6004) but I'm unable to debug
my application (I was able to do that with the LPC24xx where I directly
could jump to 0x6000).
When loading the application project, going into the debugger and
setting a breakpoint to main() and starting the application by pressing
the run button, the debugger stops at main() shortly and terminates the
debug session immediately then by returning to the normal compile mode.
If I set the option "Load Application at Startup" in the "Options for
Target 'Debug'" I see exactly the same behaviour.
Does anybody have a idea how to debug my LPC17xx application ??
Any help is highly appreciated!
Best regards
Herbert
I've ported my bootloader from the LPC24xx family to the LPC17xx family
and encounter strange problems with uVision 4:
In my bootloader I check if the application (located at 0x6000) is ok
and jump to it as follows:
#define APP_START_ADDR 0x6000
typedef void (*APP_MAIN)(void);
static APP_MAIN app_main;
int main(void)
{
:
// checking app data area at 6000
:
if (app_data_ok)
{
app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
app_main();
}
}
This seems to work as expected (the application is build with a scatter
file loading all flash data at 0x6000, so the Reset_Handler in the
vector table at 0x6000 can be found on 0x6004) but I'm unable to debug
my application (I was able to do that with the LPC24xx where I directly
could jump to 0x6000).
When loading the application project, going into the debugger and
setting a breakpoint to main() and starting the application by pressing
the run button, the debugger stops at main() shortly and terminates the
debug session immediately then by returning to the normal compile mode.
If I set the option "Load Application at Startup" in the "Options for
Target 'Debug'" I see exactly the same behaviour.
Does anybody have a idea how to debug my LPC17xx application ??
Any help is highly appreciated!
Best regards
Herbert
