S32K3 ADC Optimize DMA Streaming

[Jason22]

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

[Senlent]

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

[Jason07]

Hi@Senlent

The picture in the last reply is not clear. I have uploaded the picture again in the form of attachment. I numbered the order of the pictures with numbers.

BR,

Jason

[Jason07]

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

[Senlent]

Hi@Jason07 @Jason22

Please set the optimization build option to -O0 .

This is the result I observed during single-step debugging.

This is likely because the build optimization (-Os) prevents the debugger from accurately mapping source code variables.

[Jason22]

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].

[Senlent]

Hi@Jason22

These are my test results. If you are using the project I provided and the optimization level is set to -O0, then our observations should be the same.

I don't think there's anything wrong here. If the boundary is exceeded, it should definitely enter a hard fault, but the test results didn't, which can only mean that it's due to the compilation optimization level. There's no need to continue analyzing under an error condition.

[Jason22]

Hi@Senlent

Yes, I used your project without any modifications. In your video, the Dma_Ip_ConvertLogicChToHwCh function is called indirectly by Mcl_Init, which is not the intended behavior. The intended behavior is for Adc_Ipw_SetupTcdSingleAdcChannelMajorLink to indirectly call Dma_Ip_ConvertLogicChToHwCh. My video demonstrates this: while running Mcl_Init, I skipped all breakpoints, and after Mcl_Init completed, I re‑enabled the breakpoints. At that point, Dma_Ip_ConvertLogicChToHwCh was entered again, and LogicCh was 255.

BR,

Jason

[Senlent]

Hi@Jason22

This is strange; I've tried it multiple times. You can directly debug the ELF file I provided.

[Jason22]

Hi@Senlent
Sorry. Step4 is Click the ‘Step Over’ button.
BR,
Jason

[Jason22]

Hi@Senlent

I'm not sure if my operation was correct – I tried debugging with your ELF file but it didn't work.

Could you please perform the same steps as shown in my video? I believe you will be able to reproduce the issue.

Here are the steps:

1. Set a breakpoint at the line Mcl_Init(NULL_PTR);.

2. Run the program until it hits the breakpoint at Mcl_Init(NULL_PTR);.

3. Disable all breakpoints (Click the ‘skip all breakpoints’ button).

4. Step over Mcl_Init(NULL_PTR);(Click the ‘Step All’ button)

5. Re‑enable breakpoints(Click the ‘skip all breakpoints’ button) and Click the ‘resume’ button.

You will see that Dma_Ip_ConvertLogicChToHwCh is entered again, and LogicCh is 255.

BR,

Jason

[Senlent]

Hi@Jason22

I might still not understand your question. I'd like to ask if this project is running as expected? If it is, is there any problem?

I can see LogicCh is showing 255, but the program is running normally. Is there anything wrong with this?

[Jason22]

Hi@Senlent

I'm glad you can see that LogicCh is 255. In your project, it does run correctly, but this is an out‑of‑bounds access, right? Regarding your statement: "If the boundary is exceeded, it should definitely enter a hard fault" – I don't fully agree with that. In C language, there is no runtime boundary checking like in C++. For a pointer array, whether a hard fault occurs depends on the value obtained from the out‑of‑bounds access.

Consider a pointer array: uint32* pArr[2] = {0x20400000, 0x20400004}. Suppose the address of pArr is 0x204300A0, then the value of pArr[2] is the value is stored at address 0x204300A8. If 0x204300A8 contains 0x20400008, then *pArr[2] (an out‑of‑bounds access that ultimately reads the value at address 0x20400008) will not cause a hard fault. However, if 0x204300A8 contains 0x1FFFFFF0, then *pArr[2] (which ultimately reads from 0x1FFFFFF0) will cause a hard fault. Both are out‑of‑bounds accesses, but whether a hard fault occurs is a matter of probability.

To be precise, the hard fault is not directly caused by the out‑of‑bounds access itself, but rather because the out‑of‑bounds access to the pointer array got an invalid pointer, and accessing that invalid pointer triggers the hard fault.

This is exactly why, in your project, accessing Dma_Ip_pxInit->ppxLogicChannelConfigArray[255]->LogicChId.HwChId does not cause a hard fault, but in my project, it does.
BR,
Jason

[Senlent]

Hi@Jason22

I can forward this issue to the design team for confirmation.

Since I wasn't the one who designed the RTD driver, I won't delve into why they designed it this way unless users encounter problems.

This feedback process might be lengthy, but I will relay the findings to the relevant design team.

[Jason22]

Hi@Senlent

Thank you very much for reporting this issue to your design team. If there is a final result, where should I check for it? If there is indeed an error, will it be published in a document similar to SW32K3_S32M27x_RTD_R23-11_7.0.0_D2511_ReleaseNotes.pdf?

BR,
Jason

[Senlent · Accepted solution]

Hi@Jason22

I will send you the design team's feedback.

Usually, if it's a bug with significant impact, they will release it in a new version and include it in the release notes.