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.

Worst Case Delay required for DCANCTL INIT Bit to get SET from ZERO

Hello Support,

In the spnu517a.pdf, under Figure 20-3, there is a following statement for DCAN Chapter :

Step 3: Wait for the INIT bit to get set.

Can you please tell me what is the worst case Peripheral Clock Cycles [Host Clock Cycles for DCAN] is required when DCAN is previously active [INIT Bit is ZERO]?
Thank you.
Regards
Pashan

  • Hello,

    I am working with our CAN expert to get this information.

    Regards, Sunil

  • Hello,

    The CAN module waits for detecting a bus idle condition (11 successive recessive bits) before transitioning from operating mode to initialization mode. So the actual time it would take for the "init" bit to set depends on the CAN bus activity.

    Regards, Sunil

  • Hello Sunil,

    In the following order :

    1> Current State of DCANCTL is PMD=0x05 and INIT=0. That means DCAN is active
    2> Within the CODE, DCANCTL is being changed to INIT=1 and PMD=0x0A using a single STR instruction

    Does the new value of PMD takes effect within DCAN after INIT bit is SET and hence DCAN is disabled from CAN Bus, so that there is no potential for DCAN RAM Parity Error?

    Please help me understand better about the internal behaviour of INIT Bit being SET as well as PMD field being changed from 0x05 to 0x0A simultaneously using a single STR instruction.
    In essence, can both the fields changed atomically?

    Thank you.
    Regards
    Pashan

  • Hello Pashan,

    I see that you can change the PMD field irrespective of what the INIT bit is. So you are able to attempt to set the INIT bit at the same time as writing 0xA to the PMD field. The change to the parity checking mechanism also occurs as soon as PMD is changed, so it is not recommended to change this field when a bus master or the DCAN kernel may be reading from the DCAN mailbox memory.

    Regards,

    Sunil