• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 82 subscribers
  • Views 582 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F280037C: MCAN module stop working at 1khz reception frequency

David Capdevila
Intellectual 280 points

Part Number: TMS320F280037C
Other Parts Discussed in Thread: SYSCONFIG

Hello,

I am devlopping a CANOpen module over CAN FD and MCAN. The application requires a SYNC reception with a periodicity of 1ms. The CAN is controlled with two interrupts to ensure the periodicity, one for sync and NMT object and the other interrupt for rpdos. The interrupt for sync and nmt sends the message to the Rx Buffers.

We have encountered a problem where the MCAN module is blocked when the syncs are sent. The application works during the first SYNCs but it stop sending the responses after 5 or 6 messages. While debugging in that blocked state, i saw that the flag for new data of the buffer corresponding to the sync, is active; but the interrupts from mcan module and PIE are not triggered so I am thinking that the MCAN module did not trigger the interrupt because some reason. However I can not find the problem to solve it, would it be possible  to provide some help to solve that problem?

As a side note, the program works perfectly at lower rates. For example, the application works perfectly at a periodicity of 5ms. Also, i tried to disable all interrupts that have higher priority (I have nested interrupts) just in case the higher priority interrupt triggered at some point and blocked the mcan module but the application did not at high Reception rates.

Unfortunately I do not know what else I can check so help would be really appreciated.

Regards,

David

  • 0
    TI__Mastermind 43920 points

    Hello David,

    On the two interrupt service routines, please check that you are clearing and acknowledging the interrupt flags as they occur.  Failure to do this will result in overflow and prevent code from going in the interrupt.  Also check if there are functions called in the interrupt service routines that may take time to execute, relative to how often the interrupts are happening.  Some functions might still be running while the other interrupt occurs.

    Regards,

    Joseph

  • 0 in reply to Joseph Casuga
    Intellectual 280 points

    Hello Joseph,

    Thank you for your advice but I have already done that. I measured the interrupt execution time and I obtained 100us in ocmparison with the 1ms interrupt periodicity. Also, I clear all the interrupts correctly regarding the technical reference manual. I am clearing the IE register, the PiE register and the MCAN interrupt flag register in the correct order.

    After debugging some time I found out that by commenting the function MCAN_writeMsg, the interrupt works fine. In the same interrupt, I write the TPDO messages that are needed to be sent when a SYNC is received. It seems that this function hinders the MCAN module in some way and makes it enter into an state where a New data flag is active but the interrupts are Acknowledged.

    Also, as a side note, I am using the motor control SDK 4.0. I checked anyways with the latest version of SDK and the function is exactly the same.

    Regards,

    David

  • 0 in reply to David Capdevila
    Intellectual 280 points

    As a side note, in this message I attach the sysconfig of the message RAM configuration because there may be some issue with the addresing.

  • 0 in reply to David Capdevila
    TI__Mastermind 43920 points

    Hi David,

    Typical CAN ISRs for transmit just check flags and sets user variables as a result of a transmission event.  Modifying message objects, for instance with MCAN_writeMsgRAM is done outside of the ISR and part of message initialization.  Based from your application description, it seems like it would be best to use the TX Event FIFO.  Idea is to write the message objects  for SYNC and NMT the TX FIFO such that as soon as SYNC message is sent out and acknowledged, NMT will be sent out next,

    There is an example in driverlib that illustrates this and you might want to give it a try to see if this works better.  The example is called mcan_ex13_transmit_TxEventFIFO.

    Best regards,

    Joseph

  • 0 in reply to Joseph Casuga
    Intellectual 280 points

    Hello Joseph,

    It is an interesting solution to use the TX event FIFO. However, the messages we are sending in response to the SYNC object is a message with data from a motor that has to be updated anyways as soon as sync is received. The message contains control data for a robot. Therefore, the data should be updated with the last sample obtained before receiving the sync. How can I achieve that without interrupts? If I use normal code flow like an scheduler, There is the posibility not updating the variables for a long time. Also, regarding the sync periodicity, it may not be possible to update something like 10 times faster than the periodicty.

    To help you to undestands our system, the application obtains data from adcs at 50kHz from a motor, these variables are sent through CAN to a controller that in return responds with periodic commands. It is really important that the data variables are updated with the last sample before receiving the sync object.

    Regards,

    David

  • 0 in reply to David Capdevila
    TI__Mastermind 43920 points

    Hi David,

    I may have misunderstood what your application does.  I thought you are sending SYNC and NMT objects in succession hence i suggested the TX FIFO method, but it turns out that one node is sending a SYNC (CAN-FD frame) and the receiving node extracts the message from this SYNC frame and upon reception, reads the adc results and sends these back as a CAN frame.  This process is repeated in 1ms interval (1KHz), and the issue that you are seeing is happening in the receiving node? is my understanding correct?

    Regards,

    Joseph

  • 0 in reply to Joseph Casuga
    Intellectual 280 points

    Hello Joseph,

    Exactly that is our application summarized. I apologize for not explaining myself well.

    Best Regards,

    David

  • +1 in reply to David Capdevila
    TI__Mastermind 43920 points

    Hi David,

    No worries, just wanted to make sure i have the correct understanding of your application.  Earlier you mentioned that you were able to measure 100us ISR execution.  Not sure if this includes the transmission of the ADC readings to CAN bus as well.  Maybe if you can share what your CAN-FD bit rates are for nominal and data segments, it might help produce a clearer picture.  Can you also share how much payload there is in the SYNC portion that is being received and how many are sent from ADC readings during the 1mS interval?  Just wanted to do a quick math on how long the CAN frames are.  You also indicated that at 5ms SYNC duration, everything works fine.  To me, this is an indication that frame durations are probably longer than 1ms and messages are probably not having enough time to be received and acknowledged such that at 1ms interval, it is only successful for 5 or 6 times.  Check also the contents of the error registers and counters.  They may also provide a clue based from last error code.

    Best regards,

    Joseph

  • 0 in reply to Joseph Casuga
    Intellectual 280 points

    Hello Joseph,

    Sorry for the late reply, you gave some ideas to see what is happening and I forgot to answer. This is what I was thinking, the consumption time was very high and made the interrupts to saturate. In fact, what actually happened is that the windows application of pcanview sent the messages at different period even though I configured the transmission period to 1ms. Therefore, by looking at the osciloscope, I observed that sometimes the messages were sent with a separation of 50 us. This made the interrupt to collapse and never admit more interrupts. We used a copy of the same product but acting as a master and the application worked like a charm.

    Thank you for giving me orientation i needed.

    Regards,

    David