Hello,
When the adc group has only one channel and the Adc Enable Optimize DMA Streaming Groups configuration item is checked, a hard fault occurs when the Adc_Ipw_SetupTcdSingleAdcChannelMajorLink function is executed.
In the case of a single channel, if the Adc Group Without Interrupts configuration item is checked and ACCESS_MODE_STREAMING, Select Adc Streaming Dma Channel is enabled. Otherwise, the number of the dma channel in the configuration file is 255, which is reasonable here. But what I don't understand is why when ADC_ENABLE_GROUP_STREAMING_RESULTS_RORDER or ADC_OPTIMIZE_DMA_STREAMING_GROUPS is STD_ON, instead of STD_ON==GroupPtr ->AdcWithoutInterrupt, the Adc_Ipw_SetupTcdSingleAdcChannelMajorLink function will be called. This seems unreasonable, and also because the call to this function leads to hard fault.
BR,
Jason
Hi@Jason22
Please do not use your QQ email account next time; please use your company email account instead.
I tested this, but I didn't find any problems.
I have attached my test project and test result for your reference.
Also, i check your code and i found some error in your code.
1.clock init is wrong, your code can't not run successfully,
2."adc_group0_val" should be attribute to "no-cacheable area"
also:
The usage instructions for Optimize DMA streaming groups are clearly explained in the user manual.
RTD_ADC_UM.pdf
Hi@Senlent
Thank you very much for your reply. I have registered a new account using my company email address, and I will use that account after this thread is closed.
I ran your project and found that no hard fault occurred. However, my question still remains. As shown in the screenshot below, the function Adc_Ipw_SetupTcdSingleAdcChannelMajorLink configures the DMA_IP_CH_SET_MAJORLOOP_LOGIC_LINK_CH parameter for the DMA channel. When Dma_Ip_ConvertLogicChToHwCh is called, the LogicCh value is 255. Dma_Ip_pxInit->ppxLogicChannelConfigArray points to the Dma_Ip_paxLogicChannelConfigArrayPB array, which has a size of 2. Accessing Dma_Ip_pxInit->ppxLogicChannelConfigArray[255] should be an out‑of‑bounds access. Although no hard fault occurred, I believe this is not reasonable.
This out‑of‑bounds access is caused by calling Adc_Ipw_SetupTcdSingleAdcChannelMajorLink, which is another question I have. I have reviewed the relevant content in RTD_ADC_UM.pdf and also checked the driver code. For Optimize DMA Streaming Groups (single channel), the data is transferred directly from the CDR to the user buffer, unlike the multi‑channel case where data is first moved from the CDR to the DmaIntermediateBuffer and then from there to the user buffer. Optimize DMA Streaming Groups (single channel) does not use a Streaming DMA channel. In the configuration file, the values of AdcIpwConfigPtr->Mapping.AdcCountingDmaChanLogicId array are indeed ADC_IPW_INVALID_DMA_CHANNEL_ID (255).
I do not understand why Adc_Ipw_SetupTcdSingleAdcChannelMajorLink still needs to be called. The function that really should call this is Without Interrupt Group (single channel), but when ADC_ENABLE_GROUP_STREAMING_RESULTS_RORDER or ADC_OPTIMIZE_DMA_STREAMING_GROUPS is STD_ON, instead of STD_ON == GroupPtr ->AdcWithoutInterrupt, the Adc_Ipw_SetupTcdSingleAdcChannelMajorLink function is called.
I have found the issue in my project: when I uncheck "Data sections", the hard fault no longer occurs. However, I do not think this is the key point of the problem.
BR,
Jason
Hi@Senlent
The optimization level of my project is -O0, and I ran your project (also with -O0). I found that in Adc_Ipw_SetupTcdSingleAdcChannelMajorLink -> ...... -> Dma_Ip_ConvertLogicChToHwCh, the LogicCh value is still 255.
In your screenshot, was Dma_Ip_ConvertLogicChToHwCh called as a result of Adc_Ipw_SetupTcdSingleAdcChannelMajorLink? Mcl_Init also calls Dma_Ip_ConvertLogicChToHwCh, and in that case LogicCh is 0, which seems consistent with your screenshot.
I ran a test in your project. When Adc_Ipw_SetupTcdSingleAdcChannelMajorLink indirectly calls Dma_Ip_ConvertLogicChToHwCh, I observed that &Dma_Ip_pxInit->ppxLogicChannelConfigArray[LogicCh] is 0x429F28, which matches &Dma_Ip_pxInit->ppxLogicChannelConfigArray[255].
I then modified the value at address 0x429F28 to 0x1FFFFFF0, and executed the code at line 348.
A hard fault occurred, and the BFAR value was 0x1FFFFFF6, as expected.
This confirms that the out‑of‑bounds access does exist. Whether a hard fault occurs depends on the value at Dma_Ip_pxInit->ppxLogicChannelConfigArray[255].
