CAN Errata on LPC4337

[lpcware]

Content originally posted in LPCWare by otscherw on Wed Aug 06 08:33:19 MST 2014
Hi,

I have a board with an LPC4337FET256 / ESD13450- and have currently some difficulties on getting the CAN1 interface running.
As I understand the Errata Sheet for Revision '-', CAN0 and CAN1 should work reliably, as long as you don't access the conflicting peripherals as DAC, ADC0, ADC1 etc. Is this correct?
Currently I don't use any of those peripherals so I should be safe.

I have a test firmware using LPCopen v2.09  that can send and receive on CAN0, but when I'm trying to switch the same code from CAN0 to CAN1 I still can send messages, but don't receive anything. A receive interrupt is triggered, RXOK bit 4 in status reg is set, but the expected bit in the interrupt register is not set, although message object 2 was set up for receiving (and this works on CAN0).

So I suspect some issue with message filtering. Could of course be some bug in my FW, but before I continue debugging I just wanted to clarify that what I'm trying to do actually works. Or is there some kind of other errata that can explain this behaviour?

EDIT: my code is running from DRAM, if this should be relevant.

And finally, what are NXP's plan for fixing this errata, i.e. when do you ship a new silicon revision?

Regards,
Oliver

[lpcware]

Content originally posted in LPCWare by starblue on Thu Aug 07 08:26:37 MST 2014

---

Quote: otscherw
So just to go sure, a BASE_APB1_CLK of 102 MHz is safe, as long as divided by CLKDIV results in <= 50 MHz?

---

I think so, since that is what is written in the user manual.
And it now works reliably with our 200 MHz base clock.

We had some trouble when we didn't divide it down:
http://www.lpcware.com/content/forum/problems-ccan-bt-configuration#comment-1023290

Jürgen

[lpcware]

Content originally posted in LPCWare by otscherw on Thu Aug 07 07:41:41 MST 2014
Thank you Jürgen!
That was the problem. I didn't realize that there is an new UM.

So just to go sure, a BASE_APB1_CLK of 102 MHz is safe, as long as divided by CLKDIV results in <= 50 MHz?

BTW: The sentence "Remark: Use of C_CAN controller excludes operation of all other peripherals connected to the same bus bridge. See the LPC43xx errata." doesn't sound as NXP is going to fix this errata.

Regards,
Oliver

[lpcware]

Content originally posted in LPCWare by starblue on Thu Aug 07 05:39:51 MST 2014
Maybe you are overclocking the CAN unit, as that could cause this kind of problems.

CLKDIV should be set so that CAN_CLK is 50MHz or less (see the latest UM).

Jürgen

[lpcware]

Content originally posted in LPCWare by otscherw on Thu Aug 07 04:10:20 MST 2014
OK, I made some more tests and think that something regarding the message filtering on CAN1 interface is broken.

What I want is to set up one receive object to receive all standard IDs. For that I hacked the Chip_CCAN_SetMsgObject() function to include a "mask" parameter so that I can specify mask as 0 instead of the default CCAN_MSG_ID_STD_MASK (0x7FF) to receive all IDs. Additionally I set MXTD bit to only receive standard and no extended messages (with this bit cleared also extended messages are received).

pCCAN->IF[IFSel].MSK2 = CCAN_IF_MASK2_MXTD | CCAN_IF_MASK2_MDIR(dir) | (rxmask << 2);
pCCAN->IF[IFSel].MSK1 = 0x0000;

This all works on CAN0 as expected.
When switching to CAN1 strange things happen.
If I set one message object with ID = 0 and mask = 0, I receive nothing. When I set two identical message objects, it works, I don't care which message object received the message. OK, good, at least a workaround.

When I try to set multiple msg objects for specific IDs (with mask 0x7FF) some do receive messages, some don't. I haven't found a pattern though.