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.

TMS320F280039: Behavior of CAN module upon loss of clock

Part Number: TMS320F280039

Hi experts,

I have some questions about MCLKOFF. 

I'm using 280039 to receive the message from host computer via CAN.

If I suddenly set MCDCR.OSCOFF bit as 1 in application code, OSCCLK will disconnected to OSCCLK Counter in MCD module. Missing OSCCLK will be detected and the OSCCLK source will switch to INTOSC1. 

I think it may take a short time to detect the missing clock and switch the clock source.

My questions are:

1. Can the CAN module still receive the message from host computer via CAN during this short time? Will it cause CAN bus off?

2. When MCDCR.OSCOFF bit is 1, does the CAN clock still work?

Thank you!

Best Regards

Kita

  • Hello Kita,

    On a complete clock failure when OSCCLK is dead, it can take a maximum time of 8192 INTOSC1 cycles (that is, 0.8192 ms) before the CLOCKFAIL signal goes high, after which clock is forcefully switched to INTOSC1. This is the time you are referring to ?

    When the MCD is detected (in this case triggered with OSCOFF bit) PLL is bypassed and clock is forcefully switched to INTOSC1. Meanwhile this happens the system runs on PLL limp Clock. So to answer your question yes CAN module will still receive the message or work but considering the clock requirements of CAN the transaction might be affected as system runs on limp clock.

    Thanks,
    Prarthan.

  • Hi Prarthan,

    Thanks for your reply.

    My customer is using 280039 as a receiver node of CAN. 

    My customer has external oscillator and is testing MCD function with following steps:

    1. Disconnect the MCD clock source with function: SysCtl_disconnectMCDClockSource();

    2. Wait till the NMI is fired on clock failure: while(mcd_clkfail_isr != 0x1U);

    3. connect the internal oscillator: SysCtl_selectOscSource(SYSCTL_OSCSRC_OSC1);

    4. Re-connect missing clock detection clock source to stop simulating clock failure: SysCtl_connectMCDClockSource();

    5. Set up PLL control and clock dividers using the original clock source : SysCtl_setClock(DEVICE_SETCLOCK_CFG);

    The customer reports that, if receiver is executing the step 1-5 and transmitter sends a message to receiver via CAN at the same time, the transmitter sends a abnormal CAN message and then the transmitter is in bus-off state.

    I am testing and find the same issue. I am using 28335 as a transmitter and 28335 always the same messages: 0x00 0x00 0xFF 0xFF 0xFF 0xFF 0x00 0x00.

    At beginning the Sysclk is 120MHz and the message can be transmitted well. There is no error. The scope is below.

    CH1 is CANRX-GND of transmitter, CH2 is CANTX-GND of transmitter, CH15 is the Sysclk/8.

    Then the Sysclk will be changed to 10MHz and the message can not be good transmitted. There is an Error on both CANRX-GND and  CANTX-GND of transmitter.

    In the next cycle the transmitter send an abnormal message, the scope is below. The Sysclk is to 10MHz.

    In the next cycle the transmitter also send an abnormal message. The Sysclk is to 10MHz

    And after 3 cycles the transmitter goes to bus-off state. The Sysclk is to 10MHz

    I guess the clock of receiver maybe the cause of the communication error because the clock will be changed to internal oscillator first and it will take time to change back to external oscillator.

    But I don't understand why the clock issue of receiver will cause abnormal message CANTX-GND and CANRX-GND of transmitter.

    Could you give me some advices?

    Thank you!

    Best Regards

    Kita

  • Kita,

                This is the expected behavior. Let me explain: As soon as you disable the OSCCLK, the device is running on the limp mode clock of the PLL until the MCD circuit detects a missing clock and switches the clock to INTOSC1. The receiving CAN node becomes incapable of receiving the moment you disable the OSCCLK. Not only that. Since the input clock frequency to the CAN module has changed, its configured bit-rate would have changed. Therefore, it will start jamming the bus with error frames every time the transmitter attempts to transmit. This will make the transmitter go bus-off. This is what you are seeing.