[Scheduling][HRTIM] Under a certain HRTIM Frequency, control task no longer launches

[jalinei]

Major issue that derives from https://gitlab.laas.fr/owntech/power-api/core/-/issues/57

We should check that pwm engine is correctly running at any frequency if criticalTask source is source_tim6

• Verify that it is working well for all frequency spectrum
  • if so remove warning Only 200Khz was tested with SPIN and TWIST
  • document the fact that frequency can be initialized only once or that we can change it when disabling timing units

scheduling_define_uninterruptible_synchronous_task returns -1 for all kind of problems which makes debugging non trivial.

• We do need a user friendly error message.
  • That alert the user that the frequency of the criticalTask is not an integer multiple of the pwm
  • How to show the error message as it is in the setup section that is known not to show message because close to the boot time...
• Clearly state the limits of source_pwm in the javadocs snippet.
  • Must be an integer multiple of source_pwm frequency
  • PWM_frequency should be higher or equal to criticalTask frequency

It has to be clearly documented that PWM carrier can not be slower than criticalTask frequency if HRTIM is criticalTask clock source. This issue is also midly linked with #32

[jalinei]

Testing should be done to check if #57 is solving this High priority issue.

[luizvilla]

I have tested the frequency with the Setting multiple PWM code. There is still a behavior that is left:

• It is not possible to "sweep" the frequency from 1Hz to 1MHz.
• When the frequency is initialized with spin.pwm.initFrequency(frequency);, the frequency value given is the minimum.
• There is, however, a maximum as well. That is the maximum frequency that can be given by a certain master timing unit prescaler.

[luizvilla]

Here's the prescaler information

[luizvilla]

After some testing, I cannot get the frequency to be lower than 10kHz. If I start at 10kHz, I cannot raise the frequency above 190kHz.

[luizvilla]

At 20kHz I cannot go beyond 383kHz At 50kHz I cannot go beyond 957kHz At 200kHz I cannot go beyond 3831kHz

Experimentally, I find that the maximum frequency is 19.15 times higher than the minimum frequency.

[luizvilla]

At 50kHz I cannot go beyond 957kHz At 200kHz I cannot go beyond 3831kHz

[jalinei]

This behaviour seems normal to me Luiz. We do need to test wether the control task is succesfully launched or nor in the interval specified in initFrequency. [minimal_frequency, maximal_frequency].

What I understand from your comment is that we should clarify the capabily and spread of the upper frequency bound. This can be discussed in a separate issue and IMO without the "high priority" tag.

However here I expect that we conclude wether or not the control task correctly triggers in "reasonable" bounds let say between 20kHz to 200kHz, that for any multiple of the carrier frequency we do enter the critical task.

[luizvilla]

The PWM does not start below 10kHz

[luizvilla]

Initfrequency has no "upper bound". The frequency given to it creates the "lower bound" but that is it.

void PwmHAL::initFrequency(uint32_t init_frequency)
+1 overload

This function initialize the frequency

Parameters:
init_frequency – frequency in Hz

Warning:
this function must be called BEFORE initialiazing any timing unit. the frequency initialized becomes the MINIMUM possible. use it BEFORE initialization of the timing unit.

[luizvilla]

We can add in the documentation that the maximum frequency is 19.15 times the initial frequency.

[luizvilla]

I worked on the test a little further. Instead of using the serial port, I use the LED to test that the critical task is working. I get a blinking led that becomes faster over time and stops after a while. This is due to the fact that when the critical task is initialized, the micro-controller calculates the number of master reset repetition it needs for calling the critical task. Whenever the critical task becomes too fast, this become an issue.

[jalinei]

Initfrequency has no "upper bound". The frequency given to it creates the "lower bound" but that is it.

void PwmHAL::initFrequency(uint32_t init_frequency)
+1 overload

This function initialize the frequency

Parameters:
init_frequency – frequency in Hz

Warning:
this function must be called BEFORE initialiazing any timing unit. the frequency initialized becomes the MINIMUM possible. use it BEFORE initialization of the timing unit.

If you set two arguments in pwm.initFrequency(freq_low, freq), the prescaler is calculated in a way that the range [freq_low, freq] can be obtained. It is true that freq is not really the "real" upper bound, but the pwm should be able to output a signal with a frequency between [freq_low, freq] without any guarantee above that range. I do not see the inconvenient with that approach.

[luizvilla]

I tried again and the init frenquency works down to 650Hz with the critical task working fine.

[luizvilla]

Summary of our discussion on the matter. We currently miss:

• [x] A way to know what the resolution of the chosen frequency is: this comes from the prescaler
• [x] A way to know the maximum frequency: the minimum period is 3*fHRTIM. The counter is 16bit, so we can go from 3 to 65000.
• [x] A way to know the minimum frequency
• [x] A way to know this even if we are on center aligned

We should provide the user with the necessary data in our code and information in our documentation.

[luizvilla]

From the current code we can retrieve most of the information. The only information missing is the resolution.

[luizvilla]

I've updated the hrtim driver and the pwnHAL to retrieve all the data that is listed above. This is treated by commits 57e0b1a , f420184 and 9a7420e