S32GのトピックRe: S32G274A LLCE CAN

S32G274A LLCE CAN

JACK_Q — Sun, 23 Nov 2025 07:33:57 GMT

I encountered an issue when using llce can. Sometimes the CAN device connected to my end would reboot or reconnect physically, which would result in fewer termination resistors on the bus. As a result, the program I was running would continuously trigger ack errors, causing it to run abnormally.I would like to ask if there is any way to solve the above problem.Could you provide the relevant files for the LLCE CAN driver?

Re: S32G274A LLCE CAN

chenyin_h — Mon, 24 Nov 2025 03:09:40 GMT

Hello, @JACK_Q

Thanks for your post.

Would you mind sharing more details?

1. RDB2 or custom board is used?

2. All LLCE-CAN interface would meet such issues or only specific channel?

3. Which version RTD and LLCE software are used in your case?

4. Could the issue be reproduced only with your custom software or could also be produced within samples provisioned by NXP?

Besides, if you want to find the driver source of LLCE CAN, it could be found from your NXP account or you may apply it from the LINK

Chenyin

Re: S32G274A LLCE CAN

JACK_Q — Tue, 25 Nov 2025 08:57:55 GMT

@chenyin_h

Thank you for your reply.

At the very beginning, I used hardware: the RDB2 board, and the software was as shown in Figure 1. It ran without any abnormalities on the S32DS3.5, and there was no abnormality in the operation when the connection to the opposite CAN device was disconnected.

Figure 1

Later, when the software was modified to run on VxWorks and the hardware was a custom motherboard, there was a problem where the opposite device disconnected. After the firmware detected the error, it would continuously report notifications (ackerr). Eventually, the software ended abnormally.

I attempted to look for a solution to similar problems in the provided sample project Can_Llce_DS_Loopback_S32G274A_M7, but found that the project did not have a specific solution for the ackerr issue. It seemed that only a stub function was written, leaving an interface for the upper layer to notify of errors.

Figure 2

I would like to know how the ACK exception is handled on LLCE1_0_9. This way, I can refer to it to see if the same solution can be applied to my VxWorks system as well.

Re: S32G274A LLCE CAN

chenyin_h — Wed, 26 Nov 2025 03:05:30 GMT

Hello, @JACK_Q

Thanks for your reply.

I assume that you are working with Vxworks on A53 cores? and porting these M7 cores based demo code to Vxworks?

I feel sorry that we do not have formal supports for vxworks, since the M7 demos are based on RTD, and stub functions usually need to actually implemented in the AUTOSAR, there may be some incompatible parts from software view and you may need to implement them yourselves.

Chenyin

Re: S32G274A LLCE CAN

JACK_Q — Wed, 26 Nov 2025 07:29:05 GMT

@chenyin_h

Thank you for your reply.

I saw the LLCE CAN register SR in the "LLCE_firmware_user_guide.pdf" of LLCE1_0_9.

The picture shows that the eighth bit of SR is used to indicate whether an ackerr occurs. There should be some commands to handle the ackerr issue, but I haven't found more information in the documentation. Could you provide me with more details? My ultimate goal is to understand how the RTD resolves the ackerr problem so that I can refer to it and solve this issue in my environment.

Re: S32G274A LLCE CAN

chenyin_h — Thu, 27 Nov 2025 08:05:39 GMT

Hello, @JACK_Q

Thanks for your reply.

From my understanding, the ACKERR you mentioned is BCAN protocol errors. which is for informative purpose, These do not signal a LLCE software issue, they are present for debug purposes and in some cases it's advisable to disable them in order not to hide other critical errors by flooding the output.

I remember that it is only recorded to the controller statistics in some of the implementations, you may reference it or implement your own method according to your custom requirement.

Chenyin