STM32: CAN Reset()

[chrissnow]

Description

• Type: Bug

---

Bug

Target
STM32 (device not important)

Toolchain:
ARM

A call to reset() triggers the CAN peripheral reset bit, however the peripheral itself seems to set the sleep bit when this happens.

This means that CAN cannot be used after a call to reset without manually clearing the sleep bit in the MCR register (CAN_MCR_SLEEP) which the user has no easy way of doing.

Should can_reset() be changed to clear the sleep bit after the reset?

cc @thomasonw

[0xc0170]

cc @bcostm @adustm @LMESTM @jeromecoutant

[thomasonw]

A comment in support,
-- @ POR the STM32 CAN devices are placed in sleep by default (CAN_MCR Reset value: 0x0001 0002).
-- MBED libs stm32f?xx_hal_can.c, function HAL_CAN_Init() clears this bit.
-- STM32F man states software reset will re-enable sleep mode

There may be other configs as well which need cleaning up? Would it be appropriate for can_reset() to resolve to HAL_CAN_Init() ?

[LMESTM]

@chrissnow @thomasonw thanks for reporting this.
We can indeed consider the idea of applying the init phase again to restore registers - I will look into it and propose a patch, keeping @adustm in cc for review

[LMESTM]

@thomasonw @chrissnow settings like CAN mode() and monitor() would probably be lost as well after reset. Would you expect them to be restored as well or would application set them again ?
Restoring them means storing them in a first place and I just want to avoid wasting memory

[chrissnow]

@LMESTM I guess it depends what the API is meant to do, If the intention is to clear some sort of error then I would expect the configuration to survive, if it's meant to be like a hardware reset I'd expect everything to be lost.

I didn't check what config(if any) was lost, but it worked fine after clearing standby.

[chrissnow]

Here it is,

  /** Reset CAN interface.
  *
  * To use after error overflow.
  */
  void reset();

So calling it should maintain config.

[LMESTM]

@chrissnow I've read those lines as well but let's be honest, that doesn't help much ;-)
Anyway I think that I can avoid other settings to be lost without storing too much data. While doing the changes, I've done other clean-ups, especially for proper multiple instantiation of the driver.
I've got a branch available (https://github.com/LMESTM/mbed/tree/can_reset). I'll try to run some tests and check the registers are ok. Then when I think this is ok, would you have also have a setup and some time to run a test to check the patch is fine ?

[LMESTM]

I tested the proposed patch set and have sent the pull requet in #4932
I ended with more modifications than I'd first expected - so would be great if @adustm can review :-)
Also maybe @chrissnow could run some test ?