-
Notifications
You must be signed in to change notification settings - Fork 2.1k
cpu/stm32{f3,l4,wb,wl}: Replace ztimer with busy_wait, fix VBat sampling time and {wl only} fix initialization sequence #21238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
(Totally unrelated: I still don't love git.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have such board to test but I like the overall idea.
Could you also remove the ztimer dependency for WL family here while at it ?
It seems like no other module depends on
|
48bc726
to
911bd8b
Compare
The One thing I would like to do is to change the sampling time for the WL to the same pattern that the other implementations have with the define and the condition based on Perhaps the F3 and L4/WB should be changed to the register defintions like the F3 to avoid the magic number. Also it still has to be tested with an L4 board. The resources for the register descriptions and delays of VBat sampling: https://www.st.com/resource/en/reference_manual/rm0434-multiprotocol-wireless-32bit-mcu-armbased-cortexm4-with-fpu-bluetooth-lowenergy-and-802154-radio-solution-stmicroelectronics.pdf p. 491 |
911bd8b
to
ef4f286
Compare
I checked code from this PR using Results from
Results from
|
ad8af3e
to
997a168
Compare
35690a0
to
e8b083f
Compare
After rebasing and a lot of moving things around, this is now in a clean state for Review. The major change is that I reverted the sampling time for the "normal" channels back to the original value and just changed it for the VBat line. There is no need to slow the other channels down so much if it's not necessary. The part of the STM32WL code where the sampling time is set still differs from the other two implementations, but I didn't want to change it too. All the ADC implementations are different in one way or another anyway and I just had to find a stopping point and I think it is here 😅 This still has to be tested, but since I didn't change anything functionally, everthing should still work as it should. |
I just got done testing it and everything still does work as it should. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice one, thx :)
e8b083f
to
112e542
Compare
Thanks everyone for reviewing and testing :) |
Contribution description
This PR fixes some issues with the ADC of the STM32WL55 and the ADC of the STM32F3, L4 and WB series.
All: The ADC initialization routine used
ztimer
for an uncritical delay, which caused issues (a crash) when it was called from the early reset vector to check the battery status. I explained it here in greater detail: boards/nucleo-wl55jc: add ADC configuration #21235 (comment)Using ztimer for an uncritical delay is not really necessary, especially since the intended delay is 20µs and if only
ZTIMER_MSEC
was available instead ofZTIMER_USEC
, the delay was extended to 1ms.I replaced it with busy_wait and added a factor of 2, because busy_wait is not really accurate. We can wait longer, but we shouldn't push our luck by waiting shorter.
This was present in the F3, L4, WB and WL series.
All: Reading out the VBat voltage takes some time for the analog switch to fully switch. This was not taken into consideration, leading to incorrect voltage readings. This PR conditionally increases the sample time when the VBat module is used.
WL55: Similar to the L0, L1 and F0/G0/C0 ADC implementations, the initialization order was incorrect. The resolution setting will be ignored when the ADC is already enabled, as described in the Errata [1].
I adapted the
_adc_enable
and_adc_disable
functions from PR cpu/stm32{f0,g0,c0}: fix ADC initialization sequence #21230. At this moment it is a bit pointless to have_disable_adc
return something, but in the future someone (maybe me) wants to add a timeout to the somewhat dangerous infinite while loops and then it makes sense to have the return in place already.Also I changed the
is the ADC already initialized?
-test from checked theADEN
bit to checking if the sampling time has already been set.This should work without issues since the reset value for this register is 0.
WL55: (No fix but an improvement) Similar to the F0/G0/C0 PR from cpu/stm32{f0,g0,c0}: fix ADC initialization sequence #21230, I added the RS-register guard to avoid setting or resetting a flag that shouldn't be touched.
The issue here is that sometimes a flag is set by writing a 1 to it (typical behavior) and sometimes it is reset by writing a 1 to it. A typical RMW-cycle could potentially reset a flag, which is why the original STM32-HAL uses these guards.
The older documentation does not say that this is required, but it can't hurt. The initialization is not really time critical so we don't have to save cycles.
Testing procedure
WL55: The testing procedure is a bit of a hen-egg-problem, because for some reason the Nucleo-WL55 did not have the ADC lines configured, so PR #21235 has to be applied as well as this one. I recommend checking out PR #21235 and manually copying
cpu/stm32/periph/adc_wl.c
from this PR.F3, L4, WB: The tests can be run without any further modifications.
The first part of this PR can be easily tested with
tests/periph/vbat
withBOARD=nucleo-wl55jc make -C tests/periph/vbat flash term
.With current master (F3, L4, WB, WL):
With this PR (before applying the fix for VBat):
With this PR (after applying the fix):
The second part of this PR can be tested with
tests/periph/adc
with withBOARD=nucleo-wl55jc make -C tests/periph/adc flash term
.With master:
With this PR:
Issues/PRs references
This has to be merged before #20971 can be merged (and tested...).
See also
[1] https://www.st.com/resource/en/errata_sheet/es0500-stm32wl55xx-stm32wl54xx-device-errata-stmicroelectronics.pdf p.13 section 2.3.2