Closed heinwessels closed 1 year ago
Is it due to timer 5 ? How is the PWM input capture chosen for the test case ?
On my nucleo_h743zi board, I configure
pwm_loopback_0 {
compatible = "test-pwm-loopback";
/* first index must be a 32-Bit timer */
pwms = <&pwm2 2 0 PWM_POLARITY_NORMAL>,
<&pwm5 1 0 PWM_POLARITY_NORMAL>;
and as well
pwm_loopback_0 {
compatible = "test-pwm-loopback";
/* first index must be a 32-Bit timer */
pwms = <&pwm5 1 0 PWM_POLARITY_NORMAL>,
<&pwm2 2 0 PWM_POLARITY_NORMAL>;
timer2 channel 2 on pb3 (<&tim2_ch2_pb3>; /* CN7 PIN15 D23 */
)
and let timer5 ch1 on PA0 (<&tim5_ch1_pa0>; /* CN10 PIN29 D32 */
)
--> test PASSED
Is it due to timer 5 ? How is the PWM input capture chosen for the test case ?
Thanks for having a look! I was actually also looking into this yesterday, and saw the same. With the following inputs the tests passed for me.
I've only had it fail for Timer 5 on Channel 2 and 4. Can you confirm that it fails for you too? If so it means it could possibly be a bug in the LL drivers?
Is it due to timer 5 ? How is the PWM input capture chosen for the test case ?
Thanks for having a look! I was actually also looking into this yesterday, and saw the same. With the following inputs the tests passed for me.
- Timer 2 Channel 2
- Timer 2 Channel 4
- Timer 3 Channel 2 (some tests failed, but it's because it's a 16-bit timer, and the tests are designed for 32-bit)
I've only had it fail for Timer 5 on Channel 2 and 4. Can you confirm that it fails for you too? If so it means it could possibly be a bug in the LL drivers?
Well, not sure about the order in
pwm_loopback_0 {
compatible = "test-pwm-loopback";
pwms = <&pwm5 2 0 PWM_POLARITY_NORMAL>,
<&pwm2 2 0 PWM_POLARITY_NORMAL>;
};
--> with Timer 5 first :
START - test_pulse_and_period_capture
Testing PWM capture @ 15000000/100000000 nsec
Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/pwm/pwm_loopback/src/test_pwm_loopback.c:96: test_capture: (period_capture not within period +/- period / )
period capture off by more than 1%(pulse_capture not within pulse +/- pulse / 100)
FAIL - test_pulse_and_period_capture in 0.224 seconds
===================================================================
START - test_pulse_capture
Testing PWM capture @ 15000000/100000000 nsec
Testing PWM capture @ 75000/100000 usec
PASS - test_pulse_capture in 0.550 seconds
===================================================================
START - test_pulse_capture_inverted
Testing PWM capture @ 15000000/100000000 nsec
Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/pwm/pwm_loopback/src/test_pwm_loopback.c:101: test_capture: (pulse_capture not within pulse +/- pulse / 10) pulse capture off by more than 1%Pulse capture not supported, trying period capture
FAIL - test_pulse_capture_inverted in 0.310 seconds
===================================================================
Well, not sure about the order in
The first pwm is the output, meaning the PWM generator, and the second is the input, or PWM capture, which we are testing. So you need to set the second one to TImer 5 Channel 2. There's a diff on how to achieve this in the issue description.
Well, not sure about the order in
The first pwm is the output, meaning the PWM generator, and the second is the input, or PWM capture, which we are testing. So you need to set the second one to TImer 5 Channel 2. There's a diff on how to achieve this in the issue description.
OK,
In anycase PWM capture "only CH1 and CH2 are supported"
With timer5, channel 2 for capture (second position) <&tim5_ch2_pa1>
then is the testcase blocked:
START - test_capture_busy
E: counter overflow during PWM capture
(which does not occur when the capture is on timer2)
There is a difference between TIMER 2 and TiMER 5 that the refMan RM0433 mentions in the TIMx status register (TIMx_SR)(x = 2 to 5) _UIF: Update interrupt flag This bit is set by hardware on an update event. It is cleared by software. 0: No update occurred 1: Update interrupt pending. This bit is set by hardware when the registers are updated: At overflow or underflow (for TIM2 to TIM4) and if UDIS=0 in the TIMxCR1 register.
The pb seems specific to Timer 5 channel 2 --> I see the same error with nucleo_h563zi
Note that I also have set the st,prescaler = <255>;
for each Timer
This is due to the HW of the nucleo board pin PA1 of the TIMER5 ch2 : tim5_ch2_pa1
--> it is also connected through the SB57 to the RMII_REF_CLK of the ethernet transceiver
Open the SB57 and the test PASSED.
TESTSUITE pwm_loopback succeeded
------ TESTSUITE SUMMARY START ------
SUITE PASS - 100.00% [pwm_loopback]: pass = 8, fail = 0, skip = 0, total = 8 duration = 5.147 seconds
- PASS - [pwm_loopback.test_capture_busy] duration = 0.006 seconds
- PASS - [pwm_loopback.test_capture_timeout] duration = 1.003 seconds
- PASS - [pwm_loopback.test_continuous_capture] duration = 1.201 seconds
- PASS - [pwm_loopback.test_period_capture] duration = 0.588 seconds
- PASS - [pwm_loopback.test_period_capture_inverted] duration = 0.587 seconds
- PASS - [pwm_loopback.test_pulse_and_period_capture] duration = 0.587 seconds
- PASS - [pwm_loopback.test_pulse_capture] duration = 0.587 seconds
- PASS - [pwm_loopback.test_pulse_capture_inverted] duration = 0.588 seconds
------ TESTSUITE SUMMARY END ------
(The other pin for TIMER 5 channel 2 is PH11 which not present on this stm32h743zi package of the nucleo_h743zi board )
@heinwessels Can you confirm @FRASTM 's observation ?
Yeah, @FRASTM seems to be correct.
Describe the bug The current implementation of PWM capture on the STM32 only works for timer channel 1, while it's designed to work for channel 1 and 2. When channel 2 is selected the capture gets stuck with the ISR constantly being triggered forever.
Some symptoms I observed, although it's hard to say which values correct:
CNT
register never gets higher than about 20, it's always reset by Slave Mode Controller almost immediatelly.0
or1
.I think the base issue is that the
CC2IF
interrupt is constantly raised. This is because in #57607 this bug still persists, even if I turn off all interrupts exceptCC2IF
.On further investigation by both @FRASTM and me it seems like this issue only appears on Timer 5 Channel 2. As well as Timer 5 Channel 4 if #57607 is used. Other timers seem to function as expected.
To Reproduce Steps to reproduce the behavio on Nucleo H743zi.
pwm_loopback
test to use Timer 5 Channel 2 for PWM Capture. Note: The same happens when there's a valid input on the capture pin as well.@@ -29,7 +29,7 @@ status = "okay"; pwm5: pwm { status = "okay";
pinctrl-0 = <&tim5_ch2_pa1>; / CN11 PIN28 / pinctrl-names = "default"; }; };
Booting Zephyr OS build zephyr-v3.3.0-3460-gb10817ba25b2 Running TESTSUITE pwm_loopback
START - test_capture_busy E: counter overflow during PWM capture
Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/pwm/pwm_loopback/src/test_pwm_loopback.c:322: p) pwm capture not busy (err 0) FAIL - test_capture_busy in 0.021 seconds
START - test_capture_timeout E: counter overflow during PWM capture
Expected behavior The tests to executing normally by timing out. For example, here is the output if I make no changes to the test, except grounding the capture pin. Meaning this is capturing on timer channel 1. It's clear the capture functions as expected, as gracefully times out.
Impact Showstopper. It still persists in #57607 which is important for our project. I'm trying to debug why it's happening, but haven't had any luck yet. Any insights will be very helpful.
Environment (please complete the following information):