Errata situation for CAN on LPC4350 Revision ESD1148ZRY?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Errata situation for CAN on LPC4350 Revision ESD1148ZRY?

465 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by starblue on Mon Aug 27 07:06:49 MST 2012
I have a Keil MCB4350 board with an LPC4350 device with marking ESD1148ZRY, and as the next step I need to work on CAN.
Now from the various errata sheets I gather that CAN is currently rather broken.

For revision A (but it doesn't seem to apply to my chip?) I could use CAN1,
because I only need ADC and DAC of the peripherals CAN is in conflict with.

Now for revision A the errata sheets for LPC43x0 and LPC18x0 are almost identical.
I also found the LPC18x0 errata for revision '-' (which doesn't fit my revision number either?), where CAN1 is completely missing.
So if this would apply to my LPC4350 I'd have to use CAN0 and see whether anything happens to DAC/ADC.


I'd be grateful if somebody could shed more light on this.

Is there an errata sheet specifically for the revision marked ZRY?

Is there a more detailed description of the problem or how to work around it (e.g. which addresses are in conflict)?


Jürgen
Labels (1)
0 Kudos
7 Replies

450 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by starblue on Tue Mar 04 06:18:01 MST 2014
Are there any news when this issue will be fixed?

Background: We will need both CAN interfaces on one of our two LPC4357 controllers (the one responsible for communication).  It also needs to monitor some voltages, so there is a conflict between ADC0/1 and C_CAN0.

(Above I was talking about the other controller doing process control, which is happy with one CAN interface.)
0 Kudos

450 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by lgentili on Fri Feb 08 05:23:00 MST 2013
That will work for me. I can wait, is important to have the 2 CAN channels working, many people have selected this MCU because of that.
0 Kudos

450 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bavarian on Fri Feb 08 02:12:01 MST 2013
There is a plan to update the FLASH versions of LPC4300 and LPC1800, but I don't expect to see chips before Q3/2013.
They will be drop-in replacements for the current chip versions, so if you can live with the current version for
another few months, then you can easily switch to the new version when it is available.


Best regards,
NXP Technical Support Team

0 Kudos

450 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by starblue on Fri Jan 25 02:48:07 MST 2013
Are there any news when the CAN issue will be fixed, in particular for LPC4357?
0 Kudos

450 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by starblue on Thu Sep 13 08:00:15 MST 2012
Thanks for the clarification.

At the moment my plan is to use CAN1, and to leave the other peripherals on APB1 disabled, so that should avoid the issue with writes to CAN registers.
From those peripherals the only one we might want to use is MOTOR PWM, but I hope I can get by with some other timer.

Is there any indication or experience how long it will take until this problem is fixed in a subsequent revision?
(Actually we are interested in the parts containing flash, since we intend to use those in the final product.)
0 Kudos

450 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bavarian on Thu Sep 13 06:33:39 MST 2012
Hello,

to finally clarify this chip revision issue:

1) Rev '-' is an earlier version of LPC1850, e.g. CAN_1 was not working at all (but it also includes the bug from the A version)
2) The marking ESD1148ZRY is a marking error, in fact this device is an LPC4350 Rev A, the errata for this version includes the CAN problem

Unfortunately there is no waterproof workaround for the problem, if you change a register in the CAN block then the respective register (same offset from the block base address) from the other peripheral blocks will change as well.
The only workaround I could think of is using semaphores and use only one block at a time. Before every usage you then need to initialise the registers again to make sure they contain the correct values, after the task is finished it would be good style to disable the peripheral to reduce the risk of side effect if the registers change by dealing with the CAN registers.

Best regards.
0 Kudos

450 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by starblue on Tue Aug 28 05:28:53 MST 2012
After seeing <a href="http://www.lpcware.com/content/forum/lpc1850-revision-history#comment-1564">this post</a> I suppose I got a revision A chip.
0 Kudos