Is this normal? CAN bus generates an error frame when waking up.

[!BBQ!]

Here is what I observe:

I have an application running that communicates via the CAN bus. With a certain command via CAN the STM32 (STM32F2xx) is put into sleep mode. Thereby I configure the microcontroller to wake up and get an interrupt when activity is detected on the CAN bus. I wait until the configuration is done successfully by the hardware and then call __WFI(). 

As soon as a message comes in on the CAN bus the microcontroller also wakes up without problems and does its job perfectly BUT here one thing happens:

Should it be alone on the bus (apart from the sender of course), then the first message that wakes up the MC is answered with a NAK; only on the second repetition (ARQ) the message is answered with an ACK. Almost as if the controller takes too long to wake up.

In the Reference Manual I read that the bxCAN module needs 11 consecutive recessive

bits to synchronize with the CAN after a sleep. 

Does this mean that this behavior can be considered normal?

Thanks for your help!

[Tesla DeLorean]

>>Almost as if the controller takes too long to wake up.

Or the clock sources you're using don't come up and stabilize quickly. CAN has some relatively tight timing expectations, so you can't sleep-walk into the communications.

Are you using a constantly clocking external XO, TCXO type device, or something else. If using a crystal is this slow to start, or is your supply slow to ramp?

Can you output the internal clock node via MCO/PA8 pin and watch that vis-a-vis the CAN bus data, as it starts up.

[!BBQ!]

Hello,

thank you very much for your advice.

In any case, this has already helped me so far that I now know: "No, this is not normal".

It is a custom made board. Unfortunately PA8 is more or less out of reach. But what I was able to do is to switch another GPIO. Not perfect but better than nothing. I see here that the interrupt handler from the wake up interrupt switches about 9 us after the first edge on the Bus. The main loop starts again after 12 us (Measurement inaccuracy not taken into account). So pretty much at the same time. I communicate with 500 kBits/s. So I think that should be fast enough? Or not? 

[T J]

>> an interrupt when activity is detected on the CAN bus

how ? is that on the falling edge ?

you could connect the CanRx pin to another pin and set a falling edge interrupt.

to be sure.

// in the interrupt, disable the interrupt.

// entering sleep, enable the interrupt

[!BBQ!]

>> how ? is that on the falling edge ?

The Wake Up Interrupt described in Reference Manual RM0033 - section 27.4.3 Sleep mode (low-power) with AWUM in CAN_MCR set to 1 and in CAN_IER WKUIE also set. 

To quote the Reference Manual:

"bxCAN can be woken up (exit Sleep mode) either by software clearing the SLEEP bit or on detection of CAN bus activity. "

The corresponding interrupt is triggered and evaluated by me in the SCE handler. As a test I switch a GPIO only if the corresponding interrupt bit is set (see below) Channel 1 is the CAN_L and Channel 0 (below) is the GPIO-Signal.The first message is the message which is waking up the MC. Close behind is the repetition of the message because of the NAK. The second message gets a proper ACK. The third message is the reply of the microcontroller. Below the CAN_L line you see the GPIO which is getting switched off when the Interrupt Handler is called. This happens ~9 µs after the first edge.

[!BBQ!]

>> I kinda double answered the question and have no permission to delete this one. Just ignore <<

[T J]

9uS is a very long time... probably 500-1000 bus cycles

have you tried an EXTI interrupt pin or wakeup pin , tied to the CanRx

I wonder if you would wakeup faster ? and fix the issue

you would have to disable the interrupt as soon as you get it.

and then re-enable it as you enter sleep.

[!BBQ!]

All right. That would make sense. So the microcontroller would detect the activity on the bus and then wake up, but just too late and miss part of the message. Only with the repetition it gets the whole message. 

That means, if there would be another device on the bus, which would take over the ACK, then the microcontroller would miss the message in the current configuration, because the message would not be repeated.

I have tried this and connected a random CAN-Device. In deed, it is like this. It wakes up but without repetition my sleeping MC sends no answer. 

Thanks for the help @Community member​, @Community member​. Both of were right. The wake-up time is too long.

Thanks for the help!

[rclar.6]

Are you holding the bus in dominant by mistake intermittently. This can happen if the processor demands a dominant bit and then stops. The CAN TXR can then be in dominant and hold the bus up.

So disable to CAN before sleeping on the main processor.