S32K1 RTD 2.0.0 in S32DS v3.5

[AdithyaJayaram1996]

We are using the below RTD version in our existing project.

NXP RTD AUTOSAR 4.7. Build version: S32K1_RTD_2_0_0_D2308_ASR_REL_4_7_REV_0000_20230804

We have requirement to pass a message from one CAN channel to other CAN channel as per below image without do any processing or decoding of the message. We observed maximum of 500us time delay between passing the data from one channel to other (we are handling it in interrupt based). Is there a way to reduce this delay? Or is there any specific buffer mechanism implement in RTD to take this much time. Current we are facing problem that, some of the data are not passed to CAN2 as we are getting continuous data input from CAN0. This particular behaviour is not observed when we used the SDK (RTM 3.0.2)

Controller that we're using is  S32K148

And Also I've attached CAN configuration 

please let me know if you need any other informations from my end 

[AdithyaJayaram1996]

To assist in debugging, we will be sharing the following:

• C Sample generated files
• CAN stack configuration
• CAN DSO readings (capturing the timeout issue)
• Flashing process details
• Added Logs for both the C sample(930) and B sample(921) Logs So please check for Identifier 72 and 73
  
  let me know if anything else needed from my end

[Senlent]

Hi@AdithhyJayaram1996

Can you provide a project that can reproduce the problem, or a method and steps that can allow us to reproduce your problem, so that we can give some reasonable suggestions.

[AdithyaJayaram1996]

We are currently facing a persistent timeout issue while flashing the HALO application using UDS Transfer Data in our C Sample software, which is based on RTD 4.4 and free-rtos(10.0.) The same flashing process works fine on the B Sample software, which was based on NXP SDK and free-rtos. We would appreciate your help in diagnosing and resolving this issue.

Issue Description:

• The issue occurs only during the flashing of the HALO software.
• Flashing of LUX and Animation software works without any problems.
• The timeout occurs during the Transfer Data phase of UDS flashing, where the ECU is expected to receive and process CAN frames continuously.
• The timeout happens at random points in the flashing process, but always within the Transfer Data phase.
• When the timeout occurs, the ECU stops responding, leading to an unsuccessful flash.
• The issue is not present in the previous B Sample software, which was running stable with the SDK CAN driver and OSIF.

Observations and Debugging Steps Taken:

1. CAN Bus Load Verification:

   • We checked the CAN bus load, and it is well within acceptable limits. No excessive traffic or frame loss was observed.

2. CAN FD Baud Rate Configuration:

   • We applied the exact baud rate settings suggested by the NXP team. However, the timeout issue persists.

3. CAN Callback Function Handling:

   • All three FlexCAN instances currently use the same callback function (CAN_callbackLld()).
   • This was the same approach used in the SDK-based B Sample software, where flashing worked without issues.
   • We have not yet tested using separate callback functions for each CAN instance but can consider it if needed.

4. FlexCAN Interrupt Priority Adjustment:

   • We increased the interrupt priorities of CAN2 and CAN0 above other interrupts.
   • Despite this, the flashing timeout issue remains unchanged.

5. Potential Issue in  CAN_RX_messageQueue():

   • We identified a while loop in the CAN_RX_messageQueue() function, which could have led to blocking behavior.
   • We modified this loop to a for loop and tested again, but the timeout issue persisted.

6. FIFO Error Interrupt Handling:

   • We have not yet implemented explicit FIFO error interrupt handling.
   • We suspect that the CAN FIFO might not be processed in time, leading to message loss or unresponsiveness during flashing.
   • We would like guidance on how to correctly configure and monitor FIFO error interrupts.

Request for Assistance:

Given that flashing worked fine in the SDK-based software (B Sample) but fails in the RTD-based software (C Sample), we suspect an issue with how the RTD CAN driver handles transmission and reception, especially under high load scenarios like UDS Transfer Data.

To assist in debugging, we will be sharing the following:

• C Sample generated files
• CAN stack configuration
• CAN DSO readings (capturing the timeout issue)
• Flashing process details
• Added Logs for both the C sample(930) and B sample(921) Logs So please check for Identifier 72 and 73
• And also I've attached the UDS flow
  
  

Could you please review our implementation and help us identify potential issues or missing configurations in the RTD CAN driver? Also, any recommendations for debugging FIFO processing and ensuring message reliability during high-rate CAN transfers would be greatly appreciated.

Looking forward to your insights and support.

[AdithyaJayaram1996]

Hi @Senlet is it possible to delete the cmd prompt image from this question?

[Senlent]

Hi@AdithyaJayaram1996

Could you please check it again, i have delected the picture in your reply.

[Senlent]

Hi@AdithyaJayaram1996

In fact, I have read all the files you provided. You have a similar case, and the above suggestions also come from me.

For us, we cannot reproduce your problem. The UDS protocol services and FreeRTOS you provided are not within the scope of our support.

Unless you can provide a basic project that does not involve your protocol stack or FreeRTOS, we can help you locate and analyze the cause of the problem.

[AdithyaJayaram1996]

I've attached the package for SDK version SW, and in this we don't see such issues , so your end please check this once and let me know if you're able to find out anything 
and also attached configuration difference between both DK and RTD based SW 

[AdithyaJayaram1996]

Hi Could you please look at our concern, it's a blocker for our SW release , we would need your support.

[Senlent]

Hi@AdithyaJayaram1996

I compared the FlexCAN configuration you provided, and I think there is no difference.

Here are some possibilities I can think of

1. Is it possible that the interrupt of FlexCAN is not handled in time, resulting in the missing frame of reception or transmission, which leads to no response to the request of UDS service.

Troubleshooting method

.Add the error interrupt of FlexCAN to confirm whether the overflow caused by untimely processing leads to frame loss

Your FlexCAN0 uses FIFO0 reception, and FlexCAN2 uses CAN FD+MB interrupt. The former can be checked by "FLEXCAN_EVENT_RXFIFO_WARNING" or "FLEXCAN_EVENT_RXFIFO_OVERFLOW",
and the latter can be checked by "FLEXCAN_IP_INT_RX_WARNING"

2. Is it due to RTOS? Can your application code be tested under non-RTOS conditions?

3. Compiler optimization level settings, etc. After all, the GCC versions used by these two SDK versions are not consistent.

I have thought of many possibilities, and I can only give you some troubleshooting suggestions because I can't reproduce your problem!

[AdithyaJayaram1996]

Hello,

We have gathered the compiler optimization settings for both the SDK-based software (S32DS 2018.R1) and the RTD-based software (S32DS 3.5). Please find the attached zip file of  screenshots for reference.

Additionally, we made a change in the RTD-based software optimization from Os to O2, and we observed a difference in flashing behavior. The updated flashing logs for both the older and modified settings are also attached.

Could you compare the compiler optimization settings between SDK and RTD-based software and suggest any necessary changes to align them for better performance?
and also are there any additional settings we should modify to ensure proper execution in RTD-based software?

because after changing the optimization from OS to O2, we saw the difference and think optimization has something to do with this issue.

[Senlent]

Hi@AdithyaJayaram1996

“

Could you compare the compiler optimization settings between SDK and RTD-based software and suggest any necessary changes to align them for better performance?
and also are there any additional settings we should modify to ensure proper execution in RTD-based software?

”

I don't have more experience with this。

If the compilation options help your problem, you can try different compilation optimization levels, such as -O1, or even -O0. If this is indeed a problem caused by the compilation priority, then you should check your protocol stack. At least the routines we provide currently support -O2 optimization level.

You can have a try below settings, if still can't work as expected, then you can try -O1,or even -O0

[AdithyaJayaram1996]

Thanks for all the suggestions provided by you, It really helped us to figure out the root cause for the issue we were facing

Is it possible to provide any documentation that is available for GCC 10.2 for Arm 32-bit Bare-Metal and similarly for GCC 6.3 also

and also it would be great if some compiler expert from your team could look at the documents that I've shared erlier with you and suggest us with right set of optimization 

[Senlent]

Hi@AdithyaJayaram1996

Good to hear that,

you can find this document in the path shows in the picture.

Also, i have attach it for your reference.

No expert can directly advise you on how to configure optimization options for your code.

This usually requires you to perform compliance testing on your code yourself.

[AdithyaJayaram1996]

Hi, As i mentioned in earlier questions we have been using the NXP SDK (RTM 3.0.2) in our earlier software implementation. However, in our current development, we have transitioned to RTD (NXP RTD AUTOSAR 4.7. Build version: S32K1_RTD_2_0_0_D2308_ASR_REL_4_7_REV_0000_20230804) as part of the software update.

I would like to understand the key reasons behind the transition to RTD. Specifically, I would appreciate insights on:

Justification for Switching to RTD
Is there any specific technical or strategic reason why RTD is now preferred over SDK?
Are there any long-term support or compatibility benefits that RTD offers over SDK?
Major Differences Between RTD and SDK
Could you provide a comparison of the architectural and functional differences between RTD and SDK?
Are there any performance, memory, or flexibility improvements with RTD?
Safety-Related Certifications
Does RTD include any functional safety (ISO 26262) or other safety-related certifications that were not available in SDK?
If yes, could you provide more details on the safety enhancements in RTD?

[Senlent]

Hi@AdithyaJayaram1996

Can you create a new topic for your new topic, thanks for your understanding. 

[AdithyaJayaram1996]

We are currently experiencing a write timeout issue in the CAN TP layer while flashing over UDS. Initially, no data bytes were being transferred before the timeout. However, after applying certain optimizations, we now observe that some data gets transmitted before the timeout occurs.

Given this behavior, we would like to understand if there are any application examples or reference implementations that address similar scenarios, particularly in:

• CAN0 and CAN2 synchronization issues (since CAN0 is using RxFIFO and CAN2 is FD CAN).
• Impact of compiler optimizations on CAN communication (specifically, potential effects on ISR execution, buffer handling, or timing).
• Debugging recommendations to confirm if the issue is related to optimization, clock synchronization, or task scheduling.