LPCXpresso54618/54628 CAN-FD RTOS Integration

[Neolinga]

Hello!

I have a question regarding the LPCXpresso 54628 in combination with the "Channel CAN FD" board.

I tried to integrate the sending of one message into a RTOS for cyclic message sending. Standalone everything worked. I tried to go through it step by step. In first cycle i goes through but no message is detected on bus. In second cycle the kstatus went to TxBusy everytime. How can i release this again or know how to setup? I tried,  Non-blocking, no callback; Non-blocking with callback and Blocking sending functions. But no message on bus detected. Attached is my project. As a bus sniffer i have a Raspi+shield.

Passage -> always busy

I still do not know why there is no message on the bus. Maybe one of you experts can support me - kindly asked

Thanks!

Nils

[frank_m]

> I still do not know why there is no message on the bus. Maybe one of you experts can support me - kindly asked

CAN is a message-arbitrated bus, i.e. you cannot send a message directly. It is written to a Tx buffer, and sent autonomously by the CAN peripheral unit when the bus is free.

Your (physical) bus setup might be not correct. In order to successfully send a message, there must be a second device on the bus. Which in turn means, if there is no other device in your setup, you cannot send any message.

A common issue is to have CANH and CANL swapped, which does no harm but blocks all communication.

Check the Tx error counter (which each CAN peripheral has). Usually, it is a register in the CAN-FD block. A device goes into passive or off mode when too much consecutive send (or receive) errors happen.

As a quick fix, you could connect both devices directly at "TTL" level, bypassing the CAN transceivers. Just connect Rx to Tx and vice versa, and GND.

[Neolinga]

Hello Frank

thanks a lot for your response. The physical connection i can confirm it is working. All the examples are working fine in this combination. It is just the combination of the FreeRTOS example and the CAN-FD examples. I also compared the files eg. pin_mux etc. 

I am also a bit experienced with the CAN stack but I never implemented one in a MCU. Just analyzed with CANoe etc. 

Any advice on program level i can consider? I also tried the blocking method etc. 

[frank_m]

While I work a lot with "normal" CAN, I have no experience with CAN-FD, to be honest.

I would first try to observe the ECR register while sending. The TEC value going up (or being at the limit)  would point to hardware or config issues.

Sometimes it is useful to debug unknown code down to (peripheral) register access level, perhaps even in the assembly view.

Perhaps you can try reception, with a CAN-FD capable PC dongle.

If I remember correctly, there are at least two revisions (HW versions) of the CAN-FD standard, with devices are not fully compatible to each other.

I'm going out on a limb here, CAN-FD is not really my field of expertise.

> It is just the combination of the FreeRTOS example and the CAN-FD examples

RTOSes use to grab certain interrupts for themselves, thus handlers often need special adaptation.

[Neolinga]

Hello Frank,

thanks - i guess your last assumption is right with the adaption of the handler at any time. This is what i really do not know  

The sniffing tool is fine and can handle the Error frames or bus interferences. Used it also in lab and in parallel to the normal vector tools. I use it now cause currently i have no access to the VN-Devices since i am on vacation. I also use it in parallel with wireshark to see any levels on the bus.

Hmmm i guess i need to learn this step by step by myself then right now - or do we have any buyable support here on nxp site?

Anyway i try it on my own otherwise i need to switch back to my arduino and raspberry based solutions - without RTOS.

Thanks!

[frank_m]

> ... or do we have any buyable support here on nxp site?

I suppose. But many poster, including me, are just regular users, and have no direct association with NXP.

But NXP staff is present, and usually responsive.

> i guess your last assumption is right with the adaption of the handler at any time.

I would check the source code, what the send function is actually expected to achieve.

According to my (superficial) understanding, writing the respective transmit buffer memory, and trigger the write with setting the appropriate TXBAR bit (see chapter 35 of the MCU user manual). Interrupts are usually not involved at this stage.

The function then supposedly waits for the respective flag bit in TXBRP to clear.

Perhaps something with you buffer/queue configuration does not add up.

[Neolinga]

Hello XiangJun Rong,

thank you for the hint. Yes i also tried this without step by step and with Breakpoints after and before. Also without any Debugbreak.

My SW timers are working fine, but the sending process is not happening. This is my SWtimer in 1000ms cycle. Above is the program i used but i am still working continously on it.

[xiangjun_rong]

Hi,

The nonBlocking transfer uses interrupt mode, if you execute code in step by step mode, interrupt can not be fired, so you can NOT execute in step by step mode, you have to set a break point, and click "RUN".

Hope it can help you

BR

XiangJun Rong

[Neolinga]

Hello XiangJun Rong,

thank you for the hint. Yes i also tried this without step by step and with Breakpoints after and before. Also without any Debugbreak.

My SW timers are working fine, but the sending process is not happening. This is my SWtimer in 1000ms cycle. Above is the program i used but i am still working continously on it.

I hope you can support me.

Best regards,

Nils

[xiangjun_rong]

Hi,

First of all, as you see that the CAN bus needs hand-shaking signal, so you have to connect two CAN nodes via CAN transceiver, and the ID  between transmitter and receiver must match.

Secondly, the 64 bytes length is only supported by CAN-FD, I suggest you transfer at most 8 bytes as standard CAN message.

Hope it can help you

BR

XiangJun Rong

[Neolinga]

Hi

yes i have a general CAN-FD sniffer connected to the CAN sending port. Baudrate (Data and nominal) are matching. 2000000DBaud and 500000nominal Baud.

So CAN-FD is setup on both nodes. I have a sender (Just the LPC with trying to send one message in the SWtimer cycle) and one receiver -> sniffing toll with Rapsberry Pi and shield. Example is working with this setup fine. Also Resistors are applied. I guess i just miss some declarations in the programm itself. Setup should be fine.

[xiangjun_rong]

Hi,

Pls check if the CAN sniffer receiver ID is matched with the transmitter message ID, which is set up as msg1.id = 0x100;

Secondly, there is CAN example in SDK, pls try to use the SDK example to have the sniffer transmit/receive message.

BR

XiangJun Rong

[frank_m]

> yes i have a general CAN-FD sniffer connected to the CAN sending port. Baudrate (Data and nominal) are matching. 2000000DBaud and 500000nominal Baud.

I would not rely on sniffers alone, don't know how they deal with errors or aborted messages.

I would connect a scope as well.

[frank_m]

> yes i have a general CAN-FD sniffer connected to the CAN sending port. Baudrate (Data and nominal) are matching. 2000000DBaud and 500000nominal Baud.

I would not rely on sniffers alone, don't know how they deal with errors or aborted messages.

I would connect a scope as well.