Connecting many LPC11C24s to CAN bus - ACK loading problem

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

Connecting many LPC11C24s to CAN bus - ACK loading problem

5,239 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by LyraElectronics on Wed Feb 04 06:04:26 MST 2015
Hello all,

I have an application where strips of high powered RGB LEDs are each controlled by an LPC11C24, and they are all remotely controlled over a CAN bus.

At the other end of the CAN bus I have an LPC1768-based board with a TI transceiver to control all of the LED boards. There's proper termination at each end of the bus.

The problem I have is that as I add more boards into the daisy-chain of the CAN bus, I get more and more error frames.

Scoping this, it seems that the ACK signal gets stronger and stronger and pulls the levels of the CAN bus itself beyond its common-mode range.

I can prove it by pulling the STB high (to make them silent) on all the boards except the last one. When I re-run in this configuration I never see a single error frame.

Has anyone seen anything similar, or know how to overcome this without using an LPC11C14 + external transceiver?

Thanks,
Mike
Labels (1)
0 Kudos
Reply
14 Replies

5,136 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by R2D2 on Tue Feb 17 03:41:49 MST 2015

Quote: LyraElectronics
0x00070004 is the hex value supplied by NXP in their example can.h file.



:D

Probably a good example which should show how to[color=#f00] not[/color] setup CAN...

Usually a sample point at about 75% is a good point to start  :)
0 Kudos
Reply

5,136 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by LyraElectronics on Tue Feb 17 03:31:30 MST 2015
Yes, that's probably a better solution. I'll give it a go.

0x00070004 is the hex value supplied by NXP in their example can.h file.

I understand that every application is different, and that these values are to be altered accordingly (as I've found), but It's naughty that they provide example code with SJW set to 0 and such a late sample point. (I realise that the SJW is actually "+1", but still..) I would have expected a more generically robust example value.

Hey ho. I'm just relieved that it's working. Thanks again.
0 Kudos
Reply

5,136 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by R2D2 on Tue Feb 17 02:07:29 MST 2015

Quote: LyraElectronics
The change that worked for me was to modify the example code settings in the 'h' file from:

#define BITRATE500K25MHZ    0x00070004


to

#define BITRATE500K25MHZ    0x00344004




I'm not sure which LPC11C24 baudrate settings you are using...

0x0007... is late, but 0x0034 is a little bit early 

Did you try something like 0x0025... ?


0 Kudos
Reply

5,136 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by LyraElectronics on Tue Feb 17 00:48:25 MST 2015
Thanks to all who have offered advice, especially R2D2. I think I've now solved this problem.

The logic levels were an issue, but not the root cause. Changing to an MCP2551 CAN transceiver powered from 5V makes the logic levels look like textbook traces, which will undoubtedly help with noise immunity.

To get the processors to all play happily together I had to change the bit timings of the LPC1768 CAN.

The change that worked for me was to modify the example code settings in the 'h' file from:

#define BITRATE500K25MHZ    0x00070004


to

#define BITRATE500K25MHZ    0x00344004


This shifts the bit sample point and increases the SJW.

This works for me, it may not work for you but I hope it helps someone out there.
0 Kudos
Reply

5,136 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by starblue on Mon Feb 09 02:38:41 MST 2015
Is the ground connection for the CAN transceiver OK (I think that would be Pin 21)? Is the 5V power supply OK (not too high)?

The integrated transceiver is a TJA1051
http://www.lpcware.com/content/forum/electrical-specification-canrxd-and-cantxd

The only thing I see where the transceiver is out of spec is Vdom(TX)sym = VCC-VCANH-VCANL, which should be close to zero (+-400mV).  In your case it loooks more like 1.75V.
0 Kudos
Reply

5,136 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by R2D2 on Fri Feb 06 11:48:00 MST 2015
I've a couple of LPC1768 with SN65HVD232 and LPC11C24 (all with Split Termination) here  :)

I'm not quite sure how many 1768 / 11C24 are required to generate your problem  :quest:

But anyway, it's important to use the same CAN setup here as in your projects...

So whenever you post the problem generating projects, I'm ready  :)
0 Kudos
Reply

5,136 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by LyraElectronics on Fri Feb 06 11:24:47 MST 2015
That's very kind - thank you.

I'm working on other projects now until the end of next week, so I won't be posting for a little while. In the meantime I'm sending my customer a few boards with the MCP2551 transceivers on to try out. (As is always the case in the real world, the customer's site where this is happening is a couple of hundred miles away).

I came to the conclusion that it's the LPC11C24's internal transceiver since they never transmit a message, they only acknowledge others, and when I make them silent I never see a single error frame and it all works perfectly because the other LPC1768s are acknowledging. The scope traces kind of supported the idea. I'm prepared to be wrong though!

Thanks again,
Mike
0 Kudos
Reply

5,136 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by R2D2 on Fri Feb 06 07:43:55 MST 2015

Quote: LyraElectronics
Does anyone have any thoughts?



Hi again,

I'm not sure if your ACK is the problem at all...

Can you reduce your (LPCXpresso-) projects to the basic CAN stuff and post them?

I could try a few things here (LPC11C14, different SN65HVD23x) and debug them...


0 Kudos
Reply

5,135 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by LyraElectronics on Fri Feb 06 06:04:19 MST 2015
Hi R2D2,

Unfortunately, changing the LPC11C24 is about the only option I don't have, as they have been built into the final application and are on their way out to customers. (Admittedly I may still have to if I can't get them to work, but that's a very last option).

Stripping this down further, I now have one LPC1768 board and one LPC11C24 board, sat next to each other in the office, all powered off a bench supply.
The LPC1768 is transmitting a message, the LPC11C24 acknowledging it.

The SN65HVD232 is a 3v3 device and the LPC11C24 has 5V for its CAN interface.
Attached is a scope trace of one message SCR02.gif - note the voltage levels and the ACK bit at the end.
As you can imagine, this doesn't get any prettier with 18x LPC11C24s all driving this ACK.


I do have the option of changing the driver on the LPC1768 board, so I did. I swapped it for a Microchip MCP2551 powered from 5V rather than 3v3.

Scope trace SCR03.gif of the resulting signal (attached). The whole thing looks more symmetrical about 2.5V, but the 'pulling up' of the ACK signal is still there. There is no Canalyser (or anything else) on the bus, just pins 6&7 of the MCP2551 with a 120R resistor and pins 18 & 19 of the LPC11C24 with a resistor.

I'm starting to think this may be a genuine NXP issue. Does anyone have any thoughts?

Thanks,
Mike
0 Kudos
Reply

5,135 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by R2D2 on Thu Feb 05 13:04:49 MST 2015
A nice test would be to change the LPC11C24 with a LPC11C14 + SN65HVD23x...
0 Kudos
Reply

5,135 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by LyraElectronics on Thu Feb 05 06:05:08 MST 2015
Hi R2D2,

I have tried a few things to shed light on this.

I have cut back my setup to be 5 x LPC1768 with SN65HVD232 transceivers and a single LPC11C24.

These are laid out as:
4x LPC1768 boards which send a single CAN message every second, one on 0x600, one on 0x601, one on 0x602 and one on 0x0603.

A 'LED board controller' LPC1768 listens to these massages and sends out messages intended for the LED LPC11C24 boards on 0x700, 0x701 etc. These are every 10ms.

Just the one LPC11C24 board on the bus, when its ACK is enabled (i.e. not in silent mode) there are error frames immediately following the 0x600-0x603 messages. Almost as if the arbitration is trashing the bus.

When I make the single LPC11C24 'silent', all is fine.

Any observations would be appreciated.
Mike
0 Kudos
Reply

5,135 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by R2D2 on Wed Feb 04 11:32:39 MST 2015

Quote: LyraElectronics
The transceiver is an SN65HVD232D...(I've also tried the 'full' 60R+60R+10nF termination: same result.)



'Split termination' is usually the better choice  :)


Quote: LyraElectronics
...never had so many on one bus.



Ho many are we talking about? Are they all LPC11C24 (+ LPC1768 & SN65HVD23x)?


0 Kudos
Reply

5,135 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by LyraElectronics on Wed Feb 04 10:56:23 MST 2015
Hi R2D2,

Thanks for your response.

The transceiver is an SN65HVD232D, and there is a 120R resistor at the LP1768 end, and a 120R resistor physically at the other end of the bus.
(I've also tried the 'full' 60R+60R+10nF termination: same result.)

The entire system is powered from the same supply, so there's a common ground. All the CAN wiring is twisted, there are no stubs at all as the boards are daisy-chained.

We've used these micros extensively in other products, but never had so many on one bus.

Mike
0 Kudos
Reply

5,135 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by R2D2 on Wed Feb 04 10:35:30 MST 2015

Quote: LyraElectronics
... board with a TI transceiver...



:quest: ...TI transceiver...  :quest:


Quote: LyraElectronics
...proper termination at each end of the bus.



What is your 'proper termination'  :quest:
0 Kudos
Reply