Hello to all the community,
It's some days I'm using MBDT for developing on S32K344EVBQ172.
All is working fine just right now, but now I'm facing an issue I'm not able to solve looking in available documentation.
My goal should be to use DMA transfer for ADC instead of interrupts.
Starting from the default configuration provided for this target, I made the following settings:
1) Enabled DMA Support in McI Configuration:
2) Added DMA Logic Instance and DMA Logic Channel in McI Specific Configuration tab:
3) Checked Adc Enable DMA Support in Adc AutosarExt tab:
4) Set Adc Transfer Type to ADC_DMA in AdcHwUnit1 (because my intention is to make a test to ADC_POT_0 that is mapped to this hw unit):
5) Disabled interrupts related to AdcHWUnit1:
The application compiles successfully but, if I download it on the evaboard, the target seems to be freezed: nothing works (I use a blink code spy on one led for checking that the application is running), also if I try a PIL execution, there is no communication with serial port.
I please ask if you have some solution or if there is some examples in MBDT that could help me to find where I'm missing.
Thanks in advance,
Daniel
Hi @embedded_dan73 ,
The issue you are facing is related to a difference between MATLAB versions in terms of the order in which some header files are included inside the model generated code. I have developed and tested the model sent in the previous thread in R2021a to ensure compatibility with any newer MATLAB releases you might be using. When testing in 2022b I have encountered the same problem, for which I am proposing the following fix - the attached adc.tlc file addresses the Adc header files includes in a manner which is not impacted by the order in which header files are included in the generated code.
Could you please extract the adc.tlc file and copy it inside <toolbox_root>/mbdtbx_s32k3/+mbd_s32k3/+common/blocks/adc folder?
After this step, could you please try and test the original model that I have sent (Test_DMA_Original_NotCompiling) to firstly ensure that ADC and DMA functionality, decoupled from the rest of your application, compiles successfully and works as expected? Before doing this, I would also recommend you to remove any artifacts of the previous build (i.e cleanup the cache and codegen folders of your project).
Now, for the second model (Test_S32K344_DMA), this issue was not reproducible because in here multiple MBDT blocks are used, adding various headers in the generated code, which included also the file missing in case no. 1. However, in the configuration you have attached, please note that the Rm component needs to be configured using the PRE-COMPILE variant to match the Rm_Init(NULL_PTR) call inside the Board Initialization. If configured in PRE-COMPILE mode, the drivers will use an internal structure containing the selected settings for initialization, hence the NULL_PTR argument. However, if the configuration variant is set to POST-BUILD, the Rm_Init function won't use the internally defined structure, and it will expect a parameter to be passed (e.g Rm_Config_MBDT - structure defined in the .mex file generated code). You can also see that, inside the Board Initialization list, there are some components which are using this kind of initialization (e.g Adc_Init(&Adc_Config_MBDT);), meaning that they are configured in POST-BUILD mode.
For this, I have also attached a .mex configuration file, which you could copy next to your model, containing this update (Rm component configured as PRE-COMPILE).
Moreover, since the Test_S32K344_DMA application you have shared also contains the PWM-BCTU-ADC hardware trigger implementation, I have added inside this .mex file the setting mentioned in the other thread as well (ADC hardware trigger behavior on S32K344). With this configuration, I have tested your model to ensure that both solutions are working together - ADC conversion and DMA data transfer on ADC1 + PWM hardware triggering conversions on two different channels of ADC2.
1. Using a logic analyzer I have validated that the signals SPY1 and SPY2 are toggling at corresponding PWM triggers rising edges.
2. Using FreeMASTER I have checked the evolution of the ADC_POT0 variable when manipulating the on-board potentiometer.
Please let me know if this is the use case that you are trying to achieve or if there are additional details that should be covered and taken into consideration for developing your application.
Thank you,
Irina
- AdcHwUnit_1, associated to ADC1 has the Transfer Type set on ADC_DMA.
- Adc1Group_0, associated to the ADC1 instance, contains the ADC_POT_0 channel, and it is configured to be triggered by a software source, performing normal conversions, in the one-shot mode.
- ADC1 interrupts were disabled from the AdcInterrupt tab of the Adc component configuration and the DMA support was enabled in the AutosarExt tab.
- AdcHwUnit_1 uses the Adc_Dma_Channel for transfering the data, and this channel is configured inside the Mcl component.
- Dma_Adc_Channel was configured to use the DMA hardware channel 0
- The Interrupt Callback, executed when the DMA transfer is completed, is configured for Adc_Ipw_Adc1DmaTransferCompleteNotification - this callback is already defined and implemented by the drivers MBDT generates code on top of, and it will be executed from the DMA peripheral interrupt service routine, as detailed below.
- DMAMUX needs to be configured being used to route DMA sources to DMA channels - each ADC supports a single DMA request after the conversion of every channel. Hence, inside this component configuration, for DMA hardware channel 0, the Dma Mux Source was configured for a request from the ADC1 instance.
- Interrupt for the DMA Channel 0 must be enabled inside the Platform component - its ISR (Dma0_Ch0_IRQHandler - already defined and implemented by the drivers MBDT generates code on top of) will be executed when the transfer is completed, function which will subsequently call the callback configured inside the Mcl component - Adc_Ipw_Adc1DmaTransferCompleteNotification
- Clocks for the EDMA, DMAMUX0 and DMA Channel 0 must be enabled inside the Mcu component. Please note that DMAMUX0 and DMAMUX1 are mapped to the eDMA_TCD 0-15 and 16-31 respectively. Hence, if the DMA Channel 0 is configured for the data transfer, DMAMUX0 clock must be enabled.
Inside this list, enabling the initialization of the default components MBDT provides support for, custom initialization sequences could be added by pressing the '+' button and inserting the specific code.
- Adc_SetupResultBuffer sets the location in the memory where the ADC results will be transferred via DMA.
- Group Notification is enabled for the Adc1Group_0 to inform on when the data conversion and transfer is completed.
The noCacheable Storage Class has associated a custom Memory Section, implementing this variable placement in a non cacheable memory section with the help of the drivers Adc_MemMap.h file - contains keywords which control the assignment of variables and functions to specific sections.
For more details on this Simulink functionality, I am attaching the following reference https://www.mathworks.com/help/ecoder/ug/design-custom-storage-classes-and-memory-sections.html.
Hi @embedded_dan73 ,
The issue you are facing is related to a difference between MATLAB versions in terms of the order in which some header files are included inside the model generated code. I have developed and tested the model sent in the previous thread in R2021a to ensure compatibility with any newer MATLAB releases you might be using. When testing in 2022b I have encountered the same problem, for which I am proposing the following fix - the attached adc.tlc file addresses the Adc header files includes in a manner which is not impacted by the order in which header files are included in the generated code.
Could you please extract the adc.tlc file and copy it inside <toolbox_root>/mbdtbx_s32k3/+mbd_s32k3/+common/blocks/adc folder?
After this step, could you please try and test the original model that I have sent (Test_DMA_Original_NotCompiling) to firstly ensure that ADC and DMA functionality, decoupled from the rest of your application, compiles successfully and works as expected? Before doing this, I would also recommend you to remove any artifacts of the previous build (i.e cleanup the cache and codegen folders of your project).
Now, for the second model (Test_S32K344_DMA), this issue was not reproducible because in here multiple MBDT blocks are used, adding various headers in the generated code, which included also the file missing in case no. 1. However, in the configuration you have attached, please note that the Rm component needs to be configured using the PRE-COMPILE variant to match the Rm_Init(NULL_PTR) call inside the Board Initialization. If configured in PRE-COMPILE mode, the drivers will use an internal structure containing the selected settings for initialization, hence the NULL_PTR argument. However, if the configuration variant is set to POST-BUILD, the Rm_Init function won't use the internally defined structure, and it will expect a parameter to be passed (e.g Rm_Config_MBDT - structure defined in the .mex file generated code). You can also see that, inside the Board Initialization list, there are some components which are using this kind of initialization (e.g Adc_Init(&Adc_Config_MBDT);), meaning that they are configured in POST-BUILD mode.
For this, I have also attached a .mex configuration file, which you could copy next to your model, containing this update (Rm component configured as PRE-COMPILE).
Moreover, since the Test_S32K344_DMA application you have shared also contains the PWM-BCTU-ADC hardware trigger implementation, I have added inside this .mex file the setting mentioned in the other thread as well (ADC hardware trigger behavior on S32K344). With this configuration, I have tested your model to ensure that both solutions are working together - ADC conversion and DMA data transfer on ADC1 + PWM hardware triggering conversions on two different channels of ADC2.
1. Using a logic analyzer I have validated that the signals SPY1 and SPY2 are toggling at corresponding PWM triggers rising edges.
2. Using FreeMASTER I have checked the evolution of the ADC_POT0 variable when manipulating the on-board potentiometer.
Please let me know if this is the use case that you are trying to achieve or if there are additional details that should be covered and taken into consideration for developing your application.
Thank you,
Irina
