2016-04-04 09:26 AM
2016-04-04 09:56 AM
Honestly I don't think you could pay me enough to want to wade into this mire...
You've got software written by people who don't use the hardware, you've got hardware designed by people who've not had to implement software drivers, or a practical system using their own design. In the industry we describe this as not eating the dog food. You can reset the peripherals at a bus/unit level. Like an asynchronous reset input of yore. #define __DMA1_FORCE_RESET() (RCC->AHBRSTR |= (RCC_AHBRSTR_DMA1RST)) #define __DMA1_RELEASE_RESET() (RCC->AHBRSTR &= ~ (RCC_AHBRSTR_DMA1RST)) The SPI+CRC seems like an unmitigated cluster, you have to track bytes, and change modes, and you have Rx/Tx channels that aren't bonded in any sensible way. The SPI really needs a byte/word counter. And a better thought out chip-select generator/handler.https://en.wikipedia.org/wiki/Eating_your_own_dog_food
2016-04-04 10:34 AM
2016-04-04 11:16 AM
Indeed, but not the entire micro-controller. So marginally less worse.
A lot of the design here has been poorly thought through.2016-04-04 11:26 AM
Disabling stream will be enough.
2016-04-06 12:40 AM
The recommendation to use __DMA1_FORCE_RESET() and __DMA1_RELEASE_RESET() pointed me in the direction to try the following:
__SPI2_FORCE_RESET(); __SPI2_RELEASE_RESET();This seems to work fine, now my SPI-module recovers just fine after a faulty transmission. Thank you for your help.