Question about BCTU Trigger Notification

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Question about BCTU Trigger Notification

Jump to solution
558 Views
embedded_dan73
Contributor I

Hello to all NXP Community!

I think this is a silly question, but please, don't bother me...

I'm working with MBDT for S32K3xx, my target is the evaboard S32K44EVBQ172.

I successfully was able to configure the ADC and BCTU for doing a simple thing, just creating a PWM output with synchro ADC reading, and using that reading for generating the duty cycle.

Now, just for checking if all is as I was expecting, I would simply rise up a spy code when the ADC starts the conversion, and in order to do this I would like to use the "Trigger Notification" option in the BctuHwUnit, so I set a name for this field, in the S32 Configuration Tool, as you see in the following picture:

NXP_Pins_0-1709128773774.png

Now I was supposed to manage this callback inside Simulink, using an "Hardware Interrupt Callback" block, but I can't see my callback listed in.

I tried to add custom C code in the project, in order to create my own code for this callback, but I have a lot of issue in compiling because some dependencies can't be found by the compiler.

There is surely something that I missed or I didn't understand.

So, here is my question:

am I doing something wrong? Is there a better/simpliest way to turn on a monitoring output when the ADC conversion starts?

Thanks in advance for your help and kind support.

Regards

 

 

0 Kudos
1 Solution
430 Views
Irina_Costachescu
NXP Employee
NXP Employee

Hello @embedded_dan73 

The option that you are referring to (controlling the edge of the hardware trigger signal) is applied by the drivers, in the code, only if the signal triggering the Adc conversion is not coming from BCTU - i.e. the Hardware Trigger used for this group has its source configured to be an external signal.

Irina_Costachescu_0-1710143775620.png

 

The BCTU inputs are active-high signals, hence a logic 1 asserts the trigger input which is subsequently routed to the Adc peripheral. The BCTU is configured to take its input source from an eMIOS channel, the Flag Generation of the eMIOS channel being the event that asserts the BCTU input. Thus, you might change the edge of triggering the BCTU from the Pwm component settings.

Since I am not aware of the Pwm signal configuration in your project, I will provide a brief explanation on this based on how the Pwm is configured inside the s32k344_pwm_trgmux_lcu_adc_ctu_ebt example that our toolbox delivers (you might find this application useful in terms of Adc, Bctu, Pwm, and other peripherals configurations as well). Inside this project, the eMIOS channel used as a trigger source for BCTU is configured in OPWMB mode, having a Polarity defined as PWM_HIGH, and the Flag Generation option set on Trailing_Edge. Based on the Reference Manual of the S32K3 (you can find it inside the Documentation section on the page), in OPWMB mode, the Flag Generation occurs according to the following table:

Irina_Costachescu_1-1710143928552.png

The value of the Cn[MODE] is set by the Flag Generation option inside the configuration project (Trailing_Edge is equivalent to the Flag generation occurring at a BS1 match).

AS1 and BS1 define the first and second edges of the generated Pwm signal, this generation being also influenced by the selection of the channel Polarity. If the Polarity is set to PWM_HIGH, a positive edge will occur when AS1 matches the selected counter bus, and a negative edge occurs when BS1 matches the selected counter bus. If the Polarity is set to PWM_LOW, a negative edge will occur at AS1 match, and a positive one at BS1 match. However, at a BS1 match, the Flag Generation event occurs as well, given the table above, hence asserting the BCTU trigger input.

In this particular case, changing the Polarity of the Pwm signal from HIGH to LOW could provide the behavior that you would like to achieve.

Considering these, could you please check the settings of the Pwm signal routed to BCTU and change them based on the information depicted above to see if this impacts the behavior you are currently encountering?

For more details on the eMIOS peripheral operating modes and settings, please check the, as it provides comprehensive information which you might find helpful for designing your application.

For the Adc and Bctu operating modes (Trigger vs. Control), besides the S32K3 Reference Manual, you could also check the Adc User Manual, provided by the drivers package that MBDT integrates (<toolbox_root>\S32K3_RTD\SW32K3_RTD_4.4_R21-11_3.0.0\eclipse\plugins\Adc_TS_T40D34M30I0R0\doc), while useful details could be also found in the following application note (you can find it inside the Documentation section on the page, under the Application Note category).

Hope this information will help,

Irina

View solution in original post

0 Kudos
7 Replies
502 Views
Irina_Costachescu
NXP Employee
NXP Employee

Hi @embedded_dan73

The Bctu Trigger Notification callback is not supported by the Hardware Interrupt Block in the current MBDT release version. For enabling it to appear in the dropdown list of callbacks configured for the component, could you please check the attached archive?

Inside this archive you will find the isr_vector_settings_s32k3.xml file, which should be copied to the following location: <toolbox_root>/mbdtbx_s32k3/settings folder. After you perform this operation, please reopen the Hardware Interrupt Block mask, and the BctuLed_CodeSpy function should be available to be selected, and included inside the generated code.

Please let me know if this works or if you encounter any issues during this process.

Thank you,

Irina

0 Kudos
465 Views
embedded_dan73
Contributor I

Hi @Irina_Costachescu ,

your solution works perfectly! I can now see my callback function inside the hardware interrupt block mask, thanks a lot for your support.

Now I have another issue, probably it's not a real issue, but it's just for my understanding.

My intention was:

- turn on the code spy when the ADC is triggered

- turn off the code spy when the conversion is completed

So, in the group notifications array I set this option for ADC hardware triggering:

embedded_dan73_0-1709911685062.png

I'm expecting to see the code spy rising together with the PWM rising edge, and then going down when the conversion is complete.

But actually, what I see is this:

embedded_dan73_1-1709911831979.png

Yellow waveform is PWM, light blue waveform is my codespy.

It seems that the ADC is triggered with the falling edge...

The same happens if I set the "Adc Group Hardware Trigger Signal" to "ADC_HW_TRIG_FALLING_EDGE" or if I remove completely this field (because if I try to set "ADC_HW_TRIG_BOTH_EDGES" I receive an error message).

Am I doing something wrong?...

 

Thanks again for your kind support.

 

With Best Regards,

Daniel

 

 

0 Kudos
431 Views
Irina_Costachescu
NXP Employee
NXP Employee

Hello @embedded_dan73 

The option that you are referring to (controlling the edge of the hardware trigger signal) is applied by the drivers, in the code, only if the signal triggering the Adc conversion is not coming from BCTU - i.e. the Hardware Trigger used for this group has its source configured to be an external signal.

Irina_Costachescu_0-1710143775620.png

 

The BCTU inputs are active-high signals, hence a logic 1 asserts the trigger input which is subsequently routed to the Adc peripheral. The BCTU is configured to take its input source from an eMIOS channel, the Flag Generation of the eMIOS channel being the event that asserts the BCTU input. Thus, you might change the edge of triggering the BCTU from the Pwm component settings.

Since I am not aware of the Pwm signal configuration in your project, I will provide a brief explanation on this based on how the Pwm is configured inside the s32k344_pwm_trgmux_lcu_adc_ctu_ebt example that our toolbox delivers (you might find this application useful in terms of Adc, Bctu, Pwm, and other peripherals configurations as well). Inside this project, the eMIOS channel used as a trigger source for BCTU is configured in OPWMB mode, having a Polarity defined as PWM_HIGH, and the Flag Generation option set on Trailing_Edge. Based on the Reference Manual of the S32K3 (you can find it inside the Documentation section on the page), in OPWMB mode, the Flag Generation occurs according to the following table:

Irina_Costachescu_1-1710143928552.png

The value of the Cn[MODE] is set by the Flag Generation option inside the configuration project (Trailing_Edge is equivalent to the Flag generation occurring at a BS1 match).

AS1 and BS1 define the first and second edges of the generated Pwm signal, this generation being also influenced by the selection of the channel Polarity. If the Polarity is set to PWM_HIGH, a positive edge will occur when AS1 matches the selected counter bus, and a negative edge occurs when BS1 matches the selected counter bus. If the Polarity is set to PWM_LOW, a negative edge will occur at AS1 match, and a positive one at BS1 match. However, at a BS1 match, the Flag Generation event occurs as well, given the table above, hence asserting the BCTU trigger input.

In this particular case, changing the Polarity of the Pwm signal from HIGH to LOW could provide the behavior that you would like to achieve.

Considering these, could you please check the settings of the Pwm signal routed to BCTU and change them based on the information depicted above to see if this impacts the behavior you are currently encountering?

For more details on the eMIOS peripheral operating modes and settings, please check the, as it provides comprehensive information which you might find helpful for designing your application.

For the Adc and Bctu operating modes (Trigger vs. Control), besides the S32K3 Reference Manual, you could also check the Adc User Manual, provided by the drivers package that MBDT integrates (<toolbox_root>\S32K3_RTD\SW32K3_RTD_4.4_R21-11_3.0.0\eclipse\plugins\Adc_TS_T40D34M30I0R0\doc), while useful details could be also found in the following application note (you can find it inside the Documentation section on the page, under the Application Note category).

Hope this information will help,

Irina

0 Kudos
415 Views
embedded_dan73
Contributor I

Hello @Irina_Costachescu ,

thanks again for your kind and absolutely clear support,

your explanation is indeed clarifying and I'm able now to have the behavior I was expecting.

It was my fault to not set the right parameters in S32 Configuration Tool, I didn't understand the use case.

Thanks also for the information about the documentation, by the way: on my pc the MBDT has been installed in the AppData\Roaming subfolders of my user directory, that is hidden, so it wasn't easy to reach it, thanks for your tip!

Best regards,

Daniel

0 Kudos
489 Views
embedded_dan73
Contributor I

Hi Irina,

thank you for your kind reply. I'll try your solution soon, now I'm facing other issues while trying to use DMA (I made another post about this) and I'm working on this, but I think I'll be able to try your suggestion within today.

Thanks again, I'll give you a feedback.

Best Regards,

Daniel

0 Kudos
484 Views
Irina_Costachescu
NXP Employee
NXP Employee

Hi @embedded_dan73

Thank you as well for your reply.

I have seen the other post as well, and I will take a look into it, trying to provide an example on how DMA could be configured for ADC data transfer and how this scenario could be implemented in a Simulink model. Currently, MBDT provides support only for ADC with Interrupts, so a custom configuration must be made, and some additional functions might need to be called inside your application.

I'll post an answer on that specific thread as soon as I will have a complete solution for addressing your use case.

Regards,

Irina

0 Kudos
480 Views
embedded_dan73
Contributor I
Thanks in advance for your support.

Regards,
Daniel
0 Kudos