Hi, I want to have GTP0 trough interrupt. FSP5.5.0 seems only allowing it if I also enable the crest (cycle end) interrupt, is this behavior correct?
Below is fine with both Underflow and overflow interrupts enabled.
However, if I disable the overflow, I can't have the underflow (trough) interrupt on itself as below. Why?
Also I want to check if the interrupt timing is correct or not, I try to toggle a couple pins in the interrupt routine, like below. Do I do it correctly? My scope does not indicate that the pins are toggle correctly. timer_trough_callback is the callback for the interrupts.
Hello,
This seems like a bug of FSP configurator. When underflow/through is enabled, another interrupt must be also enabled otherwise it throws an error. I will need to confirm this internally but for now you can keep overflow/crest interrupt enabled.
To detect the crest and through events in the callback you can use TIMER_EVENT_CREST and TIMER_EVENT_TROUGH events which are triggered in triangle-wave PWM only.
If you can correct FSP5.5.0 behavior, it would be great! Right now, if I let the red flag in FSP configurator by only enabling the trough interrupt, FSP seems to generate the correct code. I just ignore this error when building the project.
My timer_trough_callback function only see the TIMER_EVENT_TROUGH event now. Since I'm evaluating timing, I want to eliminate all burdensome codes. It also seems that R_BSP_PinWrite function (from FSP) is taking too long time or something is wrong, pin writing function within interrupt callback is not correct. After I change to address the pin directly, pins behave correctly. Timing from a trough (PWM triangular) through software interrupt and then pin write takes about 1uS for 100MHz RA4E2. Executing a simple variable (SwitchingCycleCount) increment takes 0.2uS.
ch1: P408, ch3: PWM, ch4: P409. middle of ch3 PWM should be the trough.
I will report it and if it is confirmed as a bug, it will be fixed in future FSP releases.
The time from interrupt generation until toggling a pin and actually see it with an oscilloscope is affected by the FSP interrupt handling process and the FSP code that toggles the pin. You have now optimized the latter by writing the register directly, but if you are also interested in minimizing the time of FSP interrupt handling please go through my answer on this thread:
community.renesas.com/.../pwm-output-from-i-o-ports
thx for the pointer to FSP interrupt processing method. I was vaguely aware of this and don't want to remove it for now. My next step is to get into AD triggering by GPT trough. Over there there is a pin GTADSM0 that I hope to get better timing.
Ok, if you have further questions in the process please create a new post as we try to ticket one issue per post.
Sure I will start another post if different. Below is relevant. When a module in stacks tab shows red. It indicates some errors. However those links provided when the i circled is clicked do not bring up anything. Do you know how to get help from these links?
Normally you get some useful information from this window if you have an error on FSP configurator, but in this case I do not think it the information is relevant, possibly because it is should not be an error at the first place.