DMA Bootloader and Application conflict

[#1]

Hi everyone,

we have recently encountered the following enigmatic problem:

There is a bootloader that uses the SPI_MASTER (4.3.20) App with DMA configuration and soon after jumps into the main application with the same SPI_MASTER App configuration. Somehow that blocks the SPI.

BUT: If we change the SPI_MASTER configuration in bootloader or in the application to "direct", then it works!.

Unfortunately, we cannot change either. The product is already out with the bootloader in DMA and the new application was coded with DMA as well and won't work correctly in "direct" mode.

So far we tried to reset the DMA manually again in application with no luck. Any brighter ideas? Thanks!

[#2]

Just in case someone encounters the same problem, here is what we learned and the solution:

-> Cause: The problem was due to a conflict in the resources assignment. The DMA channels were, as per default, assigned by DAVE. The criteria that DAVE follows for this assignment is not yet clear to me. Anyhow, the receive and transmit channels of the DMA were exchanged.
In concrete /dma4/0/ch/3 and /dma4/0/ch/2 as rx and tx respectively. In the application, exactly the other way around.

-> Solution: Navigate to the Manual Resource Assignment menu and select the same configuration for both the bootloader and application (or between any two or more application on your controller).

-> Unknown yet: why the resource assignment cannot or will not correctly be resetted when entering into the new DAVE application.