Hello to all community.
I'm working with MBD Toolbox v1.4.0 and S32K144EVBQ172 evaboard, and I developed a simple project in order to test the ADC functionality.
Here is my scope:
1) driving two PWM outputs
2) using these PWMs as hardware triggers for two analog inputs channel
3) the triggers should be independent for each PWM, so that: PWM #1 is a trigger for ADC_IN #1, PWM #2 is a trigger for ADC_IN #2 (I can't use a unique trigger for all inputs because, for my final application, I have to sample the input at the middle of high state of the PWM, that varies depending on duty cycle)
I successfully do this if I use the BCTU control mode (Adc_EnableCtuControlMode() call inside the model), but I know that, as described in the RTD ADC user manual, in this way I can't use software triggered conversion group on the ADC Unit controlled by BCTU.
I would try to use both hardware trigger and software trigger, so I tried with BCTU triggered mode, as by default.
I read on the user manual that only one trigger at time is enabled, infact if I enable all hardware triggers contemporarly, only one reading works. So what I did:
a) In model initialization I enable hardware trigger #1
b) when hardware trigger #1 isr callback occurs, inside the callback I disable this trigger, read the related analog input, and enable hardware trigger #2
c) when hardware trigger #2 isr callback occurs, inside the callback I disable this trigger, read the related analog input, and enable hardware trigger #1
And so on.
In this way I can read both hardware triggered and software triggered ADC groups, it's fine.
But there is a behavior I didn't expect, and reading the documentation (also the uC reference manual) I'm not able to find a specific reference to what is happening:
as the two hardware triggers should be served in a single PWM period, I would expect that in any period I have a new trigger and a new conversion for each hw triggered group.
What I see, instead, is that the trigger occurs every two PWM cycles, as if for any period only one trigger was asserted. But actually, as you can see in following picture, I set the PWM outputs in order to have a phase shift between them, in order to be sure not the triggers to be asserted at the same time (I know that, if it would happen, only the trigger with major priority is served):
Yellow waveform: PWM #1
Green waveform: Trigger #1 spycode (toggle on ADC conversion complete isr callback)
Light blue waveform: PWM #2
Purple waveform: Trigger #2 spycode (toggle on ADC conversion complete isr callback)
In zip archive attached to this post you'll find the whole Simulink project, included the mex file with board setup.
I please ask you if you can help me with this behavior, and if this is the right way to implement this kind of control (as said: the BCTU control mode should be ok, but I would try to not loose the possibility to use Adc conversion groups) or if you have a better suggestion for doing so.
Thanks in advance for your support,
Daniel
Hello @embedded_dan73 ,
The Phase Shift setting of the PwmChannel_1 reflects indeed in the output signal that you are observing on the oscilloscope, but it has no impact on the signal passed as a trigger source to the BCTU. Hence, even if the rising edge of the PwmChannel_1 is no longer aligned with the one of PwmChannel_0, the trigger signals sent by eMIOS to BCTU will be asserted at the same time.
To get a clearer view on this behavior, you could test each conversion (PWM signal + ADC channel pair) of the model separately, and you could do this by performing the following actions:
- initialize the notification and hardware trigger for the conversion you would like to test (inside the Initialize subsystem)
- inside the group notification corresponding to the converted channel keep only the Adc_ReadGroup and the SPY toggle blocks
- comment the group notification block corresponding to the other conversion
By performing this test, you will notice that for the phase shifted PWM signal, the SPY signal will not toggle on the PWM signal rising edge, compared to what happens when you analyze the same scenario when performing the ADC conversion triggered by the non shifted PWM signal. Given this behavior, at each rising edge of the PWM signal which is not shifted (PwmChannel_0 in case of this configuration), you could notice that the active trigger will convert its corresponding ADC channel. Since you are enabling/disabling each trigger in the ADC groups notifications, you could see that they will perform alternatively.
Now, for the behavior that you would like to achieve, you could shift the Trigger signal that the PWM channel is sending to BCTU, so that they are not asserted in the same time. You could do that using the Trigger option in the S32 Configuration Tool - I have set it to 5000 ticks to match the signal displayed on the oscilloscope.
With these setting in place, when running the model on target, I am obtaining the following behavior:
At each PWM signal rising edge, its corresponding trigger is asserted, action which starts the ADC conversion on the specific channel and toggles the corresponding SPY signal used inside the ADC group notification.
- PwmChannel_0 (PTA1) sends a trigger to BCTU at its rising edge which subsequently triggers Group0. Inside Group0 notification PTA12 (SPY1 signal) is toggled.
- PwmChannel_1 (PTA0) sends a trigger to BCTU at its rising edge which subsequently triggers Group1. Inside Group1 notification PTB12 (SPY2 signal) is toggled.
The time difference between the PWM rising edge and the SPY signal toggle is caused by the overhead introduced by the functions executed between the moment when the trigger was asserted and the time when the Dio_WriteChannel function was called.
To minimize this time and obtain more accurate results, I would recommend you to perform the SPY signal toggling as the first action inside the ADC groups notification. For this, you could set the Dio block Priority to 1, and increase it for the others, keeping the order in which they should be executed. Please note that this will not remove this delta time completely, since other functions are also performed inside the drivers between these two actions (the callback is called from inside the ISR function associated to the interrupt, and several operations are performed before executing this callback as well).
Indeed, in this configuration, you can't use the Adc_EnableHardwareTrigger function to enable both triggers, since a second call of the function will not complete successfully - the group for which the function was first called will prevent another group to have its trigger enabled (you could see that inside the Adc_EnableHardwareTrigger function implementation). Hence, if you would like to have both triggers enabled at the same time, you could try using separate ADC instances (2 different instances for the 2 different channels being triggered by different PWM signals) or, as you have already mentioned, use the BCTU Control Mode. Please note that in BCTU Control mode you could also start software conversions using the Adc_CtuStartConversion function. As a reference to this, you could check the s32k3xx_adc_bctu_ebt example delivered inside the toolbox.
Hope this helps,
Irina
Hello @embedded_dan73 ,
The Phase Shift setting of the PwmChannel_1 reflects indeed in the output signal that you are observing on the oscilloscope, but it has no impact on the signal passed as a trigger source to the BCTU. Hence, even if the rising edge of the PwmChannel_1 is no longer aligned with the one of PwmChannel_0, the trigger signals sent by eMIOS to BCTU will be asserted at the same time.
To get a clearer view on this behavior, you could test each conversion (PWM signal + ADC channel pair) of the model separately, and you could do this by performing the following actions:
- initialize the notification and hardware trigger for the conversion you would like to test (inside the Initialize subsystem)
- inside the group notification corresponding to the converted channel keep only the Adc_ReadGroup and the SPY toggle blocks
- comment the group notification block corresponding to the other conversion
By performing this test, you will notice that for the phase shifted PWM signal, the SPY signal will not toggle on the PWM signal rising edge, compared to what happens when you analyze the same scenario when performing the ADC conversion triggered by the non shifted PWM signal. Given this behavior, at each rising edge of the PWM signal which is not shifted (PwmChannel_0 in case of this configuration), you could notice that the active trigger will convert its corresponding ADC channel. Since you are enabling/disabling each trigger in the ADC groups notifications, you could see that they will perform alternatively.
Now, for the behavior that you would like to achieve, you could shift the Trigger signal that the PWM channel is sending to BCTU, so that they are not asserted in the same time. You could do that using the Trigger option in the S32 Configuration Tool - I have set it to 5000 ticks to match the signal displayed on the oscilloscope.
With these setting in place, when running the model on target, I am obtaining the following behavior:
At each PWM signal rising edge, its corresponding trigger is asserted, action which starts the ADC conversion on the specific channel and toggles the corresponding SPY signal used inside the ADC group notification.
- PwmChannel_0 (PTA1) sends a trigger to BCTU at its rising edge which subsequently triggers Group0. Inside Group0 notification PTA12 (SPY1 signal) is toggled.
- PwmChannel_1 (PTA0) sends a trigger to BCTU at its rising edge which subsequently triggers Group1. Inside Group1 notification PTB12 (SPY2 signal) is toggled.
The time difference between the PWM rising edge and the SPY signal toggle is caused by the overhead introduced by the functions executed between the moment when the trigger was asserted and the time when the Dio_WriteChannel function was called.
To minimize this time and obtain more accurate results, I would recommend you to perform the SPY signal toggling as the first action inside the ADC groups notification. For this, you could set the Dio block Priority to 1, and increase it for the others, keeping the order in which they should be executed. Please note that this will not remove this delta time completely, since other functions are also performed inside the drivers between these two actions (the callback is called from inside the ISR function associated to the interrupt, and several operations are performed before executing this callback as well).
Indeed, in this configuration, you can't use the Adc_EnableHardwareTrigger function to enable both triggers, since a second call of the function will not complete successfully - the group for which the function was first called will prevent another group to have its trigger enabled (you could see that inside the Adc_EnableHardwareTrigger function implementation). Hence, if you would like to have both triggers enabled at the same time, you could try using separate ADC instances (2 different instances for the 2 different channels being triggered by different PWM signals) or, as you have already mentioned, use the BCTU Control Mode. Please note that in BCTU Control mode you could also start software conversions using the Adc_CtuStartConversion function. As a reference to this, you could check the s32k3xx_adc_bctu_ebt example delivered inside the toolbox.
Hope this helps,
Irina
