I am having the same issue with "User Setting Error" on GPDMA.
Edit: I found the root of my issue. I based my code off the example ADC_SingleConversion_TriggerTimer_DMA for the NUCLEO-N657X0-Q, instead of FSBL I used secure application. So if anyone else sees the same error this is the cause.
The problem is in two places.
- When using a secure application in addition to the FSBL there is a new method added to main.c called SystemIsolation_Config. Here the RIF aware config is set for the GPDMA again.
if (HAL_DMA_ConfigChannelAttributes(&handle_GPDMA1_Channel0,DMA_CHANNEL_SEC|DMA_CHANNEL_NPRIV)!= HAL_OK )
{
Error_Handler();
}
if you attach any peripheral (such as ADC) to the GPDMA in the application context you will see another call to this method in stm32n6xx_hal_msp.c HAL_ADC_MspInit
if (HAL_DMA_ConfigChannelAttributes(&handle_GPDMA1_Channel0, DMA_CHANNEL_PRIV|DMA_CHANNEL_SEC
|DMA_CHANNEL_SRC_SEC|DMA_CHANNEL_DEST_SEC) != HAL_OK)
{
Error_Handler();
}
it gets called before the SystemIsolation_Config one. Commenting out the second one here fixes the first issue.
- The second issue is that the DMA buffer needs to be in an uncacheable area of memory. Disabling either the Dcache or explicitly placing the buffer in memory marked as uncacheable allows the DMA to work. The code in the example method MPU_Config
default_config.BaseAddress = __NON_CACHEABLE_SECTION_BEGIN;
default_config.LimitAddress = __NON_CACHEABLE_SECTION_END;
does not work in the application context. The base and limit address is the same so if you use the __NON_CACHEABLE macros they do nothing. All you will see is zeroes at the memory addresses and the DMA user error. Changing the limit address to base address + your required buffer size allows the DMA to work.
