This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28P550SJ: Tx data not same in all the MCAN messages

Part Number: TMS320F28P550SJ
Other Parts Discussed in Thread: SYSCONFIG

Hello TI,

While transmitting the same data in all the bytes I am receiving different results for each byte. I tried sending the data of a sine wave at both 10ms and 10ms but still the results are miscellaneous. I have attached the zip folder of the project, image of bit time config, PCAN project file along with .sym file and the 8 and 16 bit file of the sine plot that we get as a result.

Regards,

Shrihari

mcan_ex7_classic_transmit_epm.zip 

PCAN_files.zip 

image (1).png

  • Hi Shrihari,

    Thank you for providing the project files and PCAN configuration files. Based on the information provided, here are the most likely causes of the inconsistent byte data you are seeing in your MCAN transmitted messages.

    Root Cause Analysis

    The most probable cause is a race condition between your ePWM ISR updating the sine wave data buffer and the MCAN ISR transmitting that data. If a MCAN transmission begins mid-update of your data array, the resulting message will contain a mix of old and new values, which would explain the inconsistent byte behavior you are observing.

    Recommended Actions

    First, implement data protection around your buffer update to prevent the MCAN ISR from reading partially updated data:

    DINT; // Disable global interrupts
    // Update sine wave data buffer here
    EINT; // Re-enable global interrupts
    Second, verify your bit timing configuration matches the MCAN peripheral registers on the F28P550SJ. Your PCAN setup shows 500 kbit/s at 30 MHz with Prescaler 6, TSEG1 7, TSEG2 2 PCAN_files.zip. Confirm this is consistent with your device clock configuration. I recommend using the SysConfig tool to configure your MCAN instance rather then relying on the hardcoded functions currently used in the example .c project file shared.

    Third, consider implementing a double-buffer scheme where the ePWM ISR writes to an inactive buffer and the MCAN ISR reads from the active buffer, swapping only after the update is complete.


    Clarifying Questions

    To further narrow down the issue, please confirm the following:

    • How are you packing the sine wave bytes into the CAN frame?
    • What is the DLC setting in your Tx buffer configuration?
    • Are you working with 8-bit or 16-bit sine wave data?

    Best Regards,
    Zackary Fleenor

  • Hi Shrihari,

    I wanted to follow up on the MCAN data inconsistency issue we discussed earlier. I haven't heard back from you, so I wanted to check in and see if you were able to make progress with the recommendations I provided.

    Quick Recap of Key Suggestions:

    1. Data protection - Implementing critical sections around your sine wave buffer updates to prevent race conditions between ePWM and MCAN ISRs
    2. Bit timing verification - Confirming your MCAN peripheral registers match your PCAN configuration (500 kbit/s, 30 MHz, Prescaler 6)
    3. SysConfig usage - Leveraging the SysConfig tool for MCAN configuration instead of hardcoded functions
    4. Double-buffering - Implementing a ping-pong buffer scheme to eliminate data corruption during updates

    Status Check:

    • Were you able to implement any of these changes?
    • Are you still experiencing the inconsistent byte data in your transmitted messages?
    • Did you have a chance to review the clarifying questions I asked about your data packing method, DLC settings, and whether you're using 8-bit or 16-bit sine data?

    If you've resolved the issue, I'd love to hear what solution worked for you so we can document it for others who may encounter similar problems. If you're still stuck or have moved in a different direction, please let me know how I can continue to assist.

    Looking forward to your update!

    Best Regards,
    Zackary Fleenor

  • Hi Zackary,

    The issue was resolved. It was a typedef error the correction of which I have attached. 

    Regards,

    Shrihari