2014-08-12 05:14 PM
I do not know enough about the internal workings of the processor to be sure, but I believe there is a bug in the HAL DMA drivers for the F4xx series. Specifically, it seems the De-init method puts the DMA peripheral in a state that the Init method does not properly reset. This was evidenced in a problem I had posted [DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Java/SPI¤tviews=20]here. Essentially, if I made a call to de-init prior to initializing, the DMA transfer never incremented the destination address. Removing the de-init call results in working behavior. I was able to confirm by changing the length of the transfer that the peripheral being served by the DMA transfer was in fact receiving the correct data, but that each byte transferred to memory by the DMA was going to the same location rather than auto-incrementing.
#stm32 #stcubemx #hal #stm32f42014-08-27 03:03 AM
Hi woolston.jared,
We've checked the DMA De-Init API and it's OK, we can re-start a transfer after DMA De-Init call. We've followed this scenario:We've also checked the following based DMA examples (P2M and M2P modes):
2014-09-08 10:26 AM
Hi,
Can you try to call the HAL_DMA_Abort() API before calling the HAL_DMA_DeInit() when the DeInit return is different from HAL_OK?Please, keep us informed about your finding.Regards.2015-10-07 06:37 AM
Sorry to reopen an old thread.
I have a problem which looks similar to this one. I would be very glad to get some help for this: [DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Java/How%20to%20properly%20stopcancel%20a%20%28SPI%29%20DMA%20transfer%20when%20CRC%20is%20enabled¤tviews=4]How to properly stop/cancel a (SPI) DMA transfer when CRC is enabled?