TMS570LS0914: CAN1 is not communicating after wake-up from sleep mode.

Hi,

Please check the DCAN CTL register for CAN1. If the PDR (Power Down Request) bit is still stuck high or the Init bit refuses to clear, the internal state machine is frozen.

Have you cleared the bit in PSPWRDWNCLRx register for DCAN1 clock domain? If the DCAN1 clock is still gated at the PCR level post-wake, register writes to CAN1 will have no effect.

What are the values of the DCAN1 CTL and DCAN1 ES registers right after the failed wake-up?

Is CAN transceiver is enabled by a GPIO? are the transceivers controlled by the same GIO pin?

We captured the DCAN1 CTL register values immediately after wake-up and compared them with the working case.

Working case: DCAN1->CTL = 0x00021402
Failed wake-up case: DCAN1->CTL = 0x00021403

The only difference between the two values is the INIT bit (Bit 0). In the failed wake-up scenario, the INIT bit remains set, indicating that DCAN1 stays in Initialization Mode and does not enter Normal Communication Mode.

As a test, we manually cleared the INIT bit:

canREG1->CTL &= ~1U;

After clearing the INIT bit, CAN1 immediately started communicating normally.

This indicates that the CAN controller is functional, however DCAN1 is getting stuck in Initialization Mode after wake-up. We would like to understand the possible reasons why the INIT bit is not getting cleared automatically during the wake-up sequence.

Also, our periphInit() function clears all PSPWRDWNCLRx registers (0xFFFFFFFF), enabling all peripheral clock domains. Could there be any other condition during wake-up that prevents DCAN1 from exiting Initialization Mode even though the peripheral clock appears to be enabled?

delna mol A S said:

Failed wake-up case: DCAN1->CTL = 0x00021403

The INIT is set which means the CAN is not in normal operation mode.

In the Bosch DCAN IP used by TI Hercules microcontrollers, the INIT bit is never automatically cleared by hardware when exiting a power-down state. It always requires software intervention. Clearing PSPWRDWNCLRx only restores the peripheral clock domain to the module.

delna mol A S said:

After clearing the INIT bit, CAN1 immediately started communicating normally.

Since your manual test confirms the hardware is perfectly operational, you should explicitly handle the INIT bit removal at the end of your wake-up sequence。

1. Clear PSPWRDWNCLRx bit to enable CAN1 peripheral clock

2. Add a short delay to guarantee the clock propagation

3. Clear INIT to enter normal operation mode

4. Wait for the module to sync to the bus (11 recessive bit) and verify INIT bit is cleared 

while ((canREG1->CTL & 1U) == 1U);

delna mol A S said:

In the failed wake-up scenario

Can you verify the wake-up configuration? How the wake-up sequence is triggered (e.g., via an external GPIO, a CAN transceiver RX edge, or an internal timer? Are you using HalCoGen-generated drivers?

BTW, What are the value of these two bits (PDA, WakeUpPnd) in ES register?

QJ Wang said:

1. Clear PSPWRDWNCLRx bit to enable CAN1 peripheral clock

QJ Wang said:

Can you verify the wake-up configuration? How the wake-up sequence is triggered (e.g., via an external GPIO, a CAN transceiver RX edge, or an internal timer? Are you using HalCoGen-generated drivers?

QJ Wang said:

In the Bosch DCAN IP used by TI Hercules microcontrollers, the INIT bit is never automatically cleared by hardware when exiting a power-down state. It always requires software intervention. Clearing PSPWRDWNCLRx only restores the peripheral clock domain to the modul

We are already clearing the INIT bit once after wake-up in the initialization sequence. However, the issue was still observed. For testing, we implemented a polling-based check/clear of the INIT bit after wake-up, and communication is working consistently with this approach.

delna mol A S said:

Failed wake-up case: DCAN1->CTL = 0x00021403

The ABO (Auto-Bus-On) bit and WUBA bit in CTL are not enabled. If the ABO is disabled, any physical line disturbance during the transceiver power-up phase could hard-lock the module into INIT = 1 until software manually clears it. If WUBA=0, no detection of a dominant CAN bus level while in local power down mode.

delna mol A S said:

The wake-up is triggered by a GPIO wake-up source as well as an analog wake-up condition when the monitored signal exceeds the configured threshold.

Analog wake-up condition: is it CAN bus activity?

How do you use a GPIO to wake-up CAN? My understanding is to force the Global Clock Module (GCM) to restore the core clocks (GCLK, HCLK) the exact moment the GPIO edge is detected. Please refer to the section "VIM Wakeup Interrupt" in device TRM. Is the GPIO connected to CAN transceiver? 

QJ Wang said:

What are the values of the DCAN1 CTL and DCAN1 ES registers right after the failed wake-up?

Hi Delna,

Because bits 8, 9, and 10 (PER, WakeUpPnd, and PDA) are all 0 in this specific value (0x00E7), the node is trapped in a permanent Bus-Off state without any active wake-up pending flags at the exact millisecond of the read.