LPC1517 Bad CAN message responses

[gregwilson-lind]

I'm working on a system that has (currently) 10 LPC15 nodes on the CAN bus (running at 100K baud) controlled by a RaspberryPi3 & CanBerry board with CanFestival.

At start up of the RPi program we download a couple of hundred OD's for each node to configure the boards. At times I've gotten some strange responses from the LPC15 CAN Rom API. In the following trace taken with PCanView I get a request to write to an OD and the node responds with success, there is other traffic on the bus, and then another request comes across to write to the next OD on the board and I see 2 abort responses for the previous write.

;   Message Number 
;   |         Time Offset (ms) 
;   |         |          ID (hex) 
;   |         |          |     Data Length 
;   |         |          |     |   Data Bytes (hex) ... 
;   |         |          |     |   | 
;---+--   ----+----  ----+---  +  -+ -- -- -- -- -- -- --  
37229)    855399.2      058A  8  60 11 14 04 00 00 00 00   
37230)    855400.4      0604  8  2B 11 14 05 00 00 00 00   
37231)    855401.8      0605  8  2B 11 14 05 00 00 00 00 --- Request  
37232)    855403.0      0584  8  60 11 14 05 00 00 00 00   
37233)    855404.2      0585  8  60 11 14 05 00 00 00 00 <---Response  
37234)    855405.4      0607  8  2B 11 14 05 00 00 00 00   
37235)    855406.8      0608  8  2B 11 14 05 00 00 00 00   
37236)    855408.0      0587  8  60 11 14 05 00 00 00 00   
37237)    855409.2      0588  8  60 11 14 05 00 00 00 00   
37238)    855410.4      0609  8  2B 11 14 05 00 00 00 00   
37239)    855411.8      0601  8  2F 12 14 00 05 00 00 00   
37240)    855413.1      0589  8  60 11 14 05 00 00 00 00   
37241)    855414.3      0581  8  60 12 14 00 00 00 00 00   
37242)    855415.5      0602  8  2F 12 14 00 05 00 00 00   
37243)    855416.0      0708  1  7F   
37244)    855417.3      060A  8  2B 11 14 05 00 00 00 00   
37245)    855418.5      0582  8  60 12 14 00 00 00 00 00   
37246)    855419.7      058A  8  60 11 14 05 00 00 00 00   
37247)    855420.9      0604  8  2F 12 14 00 05 00 00 00   
37248)    855422.3      0584  8  60 12 14 00 00 00 00 00   
37249)    855423.5      0605  8  2F 12 14 00 05 00 00 00  -  New Request  
37250)    855424.1      0080  0    
37251)    855425.3      0585  8  80 11 14 05 01 00 04 05 === Abort Response for previous request  
37252)    855426.5      0585  8  80 11 14 05 01 00 04 05 === 2nd Abort Response for previous request

The error code 05040001 'Command specifier not valid', is not one that is generated by any of my code, 
so must come from the LPC CAN Rom API. 
And also, as can be seen, it is sent twice.

Does anybody have any idea what could cause the LPC CAN Rom API to generate this kind of response?

[gregwilson-lind]

I just realized that in a number of other cases where I've had a request and not received a response from the controller I've had a SYNC message immediately after the write request as happened in the case posted here.

Does the LPC15 have some kind of an issue with receiving a SYNC while processing a message?

[soledad]

Hi Greg,

Please check the comments below, I hope this helps.

The error code 05040001 should be generated by CAN ROM API, not generated by user. But for the detail meaning, because the ROM API don't provide inside detail description, it's also difficault to have an definition idea for this. I searched in UM, even cannot get the  error code 05040001, also for SDO_ABORT_UNKNOWN_COMMAND. So here I only can give some normal suggestion:

1. Try to test it under only two node, to see whether have this problem also.

2. Try  use external OSC

3. Because the error code shows "'Command specifier not valid'", maybe need check or change the command data type to test, in case it caused by SW data definition not compatible.

Have a great day,
Sol

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[gregwilson-lind]

I did close to the only two nodes test the other day, I had changed the cdcf file for one of my nodes and therefore that nodes configuration needed to be updated and the others didn't. While the host was downloading the new configuration data, the host sent out an NMT message to enable one of the other nodes. In CANOpen NMT messages are sent out to CAN-ID 0 and are received by all nodes and then the data determines who it is destined for. This is a close simulation of what is happening with the SYNC commands. In this case the node never responded to the first message at all.

For suggestion 2, what do you mean use an external oscillator. We are using an external oscillator to drive the clock of the LPC1517 that we have on our board.

For 3,we have done the downloads of configuration data hundreds of times involving tens of thousands of OD entry writes, the error only occurs if there is a second message that is received very shortly after the first message. The data is the same across the various tries. The error occurred more frequently when we were updating the configuration on all of the nodes every time we started up, and had enabled NMT SYNC messages while the OD configuration was happening. We have since turned off the SYNC messages during the configuration process and we don't get the bad message response, unless there is some other NMT message going out. In fact, if you look at the trace included in the original message, other nodes received exactly the same message and processed it correctly.

[soledad]

Hi,

Does it possible to fulfill this function with add a shortly delay between the first message and second message?

Regards

Sol

[gregwilson-lind]

Hi Sol,

I don't control the timing. So, no I can't insert a delay between the messages.

Greg

[soledad]

Hi,

We are checking this issue internally, I will be back as soon I have an answer.

Regards

Sol