Hello everyone, Giovanni,
Newer MCU of the STM32 family received this new feature that allows the MCU to clock the APB1 connected timers at the rate of the AHB bus. The screenshot below is a relevant excerpt from the STM32F446 user manual:
Currently ChibiOS (neither the latest release nor trunk) does not support the case when TIMPRE=1. Can one hope to see this feature supported in the next release?
Thanks!
Support for RCC_DKCFGR.TIMPRE in newer STM32 Topic is solved
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Support for RCC_DKCFGR.TIMPRE in newer STM32
hi,
Moving in bug reports but I cannot guarantee a quick implementation.
Giovanni
Moving in bug reports but I cannot guarantee a quick implementation.
Giovanni
- Spym
- Posts: 45
- Joined: Tue Oct 15, 2013 10:20 am
- Location: Tallinn, Estonia
- Has thanked: 2 times
- Been thanked: 3 times
- Contact:
Re: Support for RCC_DKCFGR.TIMPRE in newer STM32
Hi Giovanni,
Seems like this feature is only supported for STM32H7 at the moment (by virtue of STM32_TIMPRE_ENABLE). Are there plans to support it for STM32F4? Currently, my application has to tinker with registers manually to work around the lack of this feature.
Thanks!
Seems like this feature is only supported for STM32H7 at the moment (by virtue of STM32_TIMPRE_ENABLE). Are there plans to support it for STM32F4? Currently, my application has to tinker with registers manually to work around the lack of this feature.
Thanks!
- FXCoder
- Posts: 384
- Joined: Sun Jun 12, 2016 4:10 am
- Location: Sydney, Australia
- Has thanked: 180 times
- Been thanked: 130 times
Re: Support for RCC_DKCFGR.TIMPRE in newer STM32
Hi,
I've made a patch to the F4 HAL to support F413 which has been in use on a project for > 1 year.
This includes TIMPRE and also support for PLLI2S as a source of CK48 for USB.
I keep the patched HAL files current with trunk so they are up to date.
The F446 is similar in regard to TIMPRE except that F446 (according to the RM) applies the multiplier for APB pre-scaler values > 4.
Whereas the F413 only does so for pre-scaler values > 2.
I've made the changes to support the F446 TIMPRE and if this is of use to you the patch archive is attached.
To use...
In mcuconf #define STM32_TIMPRE to STM32_TIMPRE_PCLK or STM32_TIMPRE_HCLK accordingly.
Note that the F4 hal_lld files do have a lot of conditionals in them.
There was discussion of re-doing the clock tree code as part of an F413 official integration to ChibiOS.
I'm unsure if that is still planned or not.
Cheers,
Bob
I've made a patch to the F4 HAL to support F413 which has been in use on a project for > 1 year.
This includes TIMPRE and also support for PLLI2S as a source of CK48 for USB.
I keep the patched HAL files current with trunk so they are up to date.
The F446 is similar in regard to TIMPRE except that F446 (according to the RM) applies the multiplier for APB pre-scaler values > 4.
Whereas the F413 only does so for pre-scaler values > 2.
I've made the changes to support the F446 TIMPRE and if this is of use to you the patch archive is attached.
To use...
In mcuconf #define STM32_TIMPRE to STM32_TIMPRE_PCLK or STM32_TIMPRE_HCLK accordingly.
Note that the F4 hal_lld files do have a lot of conditionals in them.
There was discussion of re-doing the clock tree code as part of an F413 official integration to ChibiOS.
I'm unsure if that is still planned or not.
Cheers,
Bob
- Attachments
-
- STM32F413-F446.zip
- (5.7 KiB) Downloaded 174 times
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Support for RCC_DKCFGR.TIMPRE in newer STM32
Hi,
The idea was to make a separate hal_lld_41x.h because the differences, the excessive conditionals was exactly the problem.
Giovanni
The idea was to make a separate hal_lld_41x.h because the differences, the excessive conditionals was exactly the problem.
Giovanni
- FXCoder
- Posts: 384
- Joined: Sun Jun 12, 2016 4:10 am
- Location: Sydney, Australia
- Has thanked: 180 times
- Been thanked: 130 times
Re: Support for RCC_DKCFGR.TIMPRE in newer STM32
Hi Giovanni,
Most of the relevant differences are worked out (at least for the project I'm working on using F413).
I could find some time in the next few weeks to split out F41x into a separate hal_lld_f41x and revised platform.mk files if that would be helpful.
Let me know.
Regards,
Bob
Most of the relevant differences are worked out (at least for the project I'm working on using F413).
I could find some time in the next few weeks to split out F41x into a separate hal_lld_f41x and revised platform.mk files if that would be helpful.
Let me know.
Regards,
Bob
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Support for RCC_DKCFGR.TIMPRE in newer STM32
I will look at the current patch first, thanks.
Giovanni
Giovanni
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Support for RCC_DKCFGR.TIMPRE in newer STM32
I added the patch in trunk. Except for some minor style-related changes it should be fine.
The only thing I don't like is checking for a specific model directly in complex expressions (there are checks for defined(STM32F413xx) in several places) but I haven't changed it.
Please let me know if everything is fine.
Giovanni
The only thing I don't like is checking for a specific model directly in complex expressions (there are checks for defined(STM32F413xx) in several places) but I haven't changed it.
Please let me know if everything is fine.
Giovanni
- FXCoder
- Posts: 384
- Joined: Sun Jun 12, 2016 4:10 am
- Location: Sydney, Australia
- Has thanked: 180 times
- Been thanked: 130 times
Re: Support for RCC_DKCFGR.TIMPRE in newer STM32
OK. I agree and also don't like doing those checks in that way.
The reason those mcu specific checks are there was due to the bit positions being the same for STM32_CK48MSEL_PLLI2S and STM32_CK48MSEL_PLLSAI.
So the bit pattern alone can't be used to differentiate between the settings in the conditionals in hal_lld.h.
New definitions could certainly be made to handle the ambiguous bit pattern in a better way.
I didn't want to go too far in making changes at the time.
The reason those mcu specific checks are there was due to the bit positions being the same for STM32_CK48MSEL_PLLI2S and STM32_CK48MSEL_PLLSAI.
So the bit pattern alone can't be used to differentiate between the settings in the conditionals in hal_lld.h.
New definitions could certainly be made to handle the ambiguous bit pattern in a better way.
I didn't want to go too far in making changes at the time.
- FXCoder
- Posts: 384
- Joined: Sun Jun 12, 2016 4:10 am
- Location: Sydney, Australia
- Has thanked: 180 times
- Been thanked: 130 times
Re: Support for RCC_DKCFGR.TIMPRE in newer STM32
Hi Giovanni,
I just did one more change so mcuconf.h does not need to have an STM32_TIMPRE entry.
Also attached the F413 demo, board and .ld for you to check and add to trunk.
Cheers,
Bob
I just did one more change so mcuconf.h does not need to have an STM32_TIMPRE entry.
Also attached the F413 demo, board and .ld for you to check and add to trunk.
Cheers,
Bob
Code: Select all
Index: hal_lld.h
===================================================================
--- hal_lld.h (revision 12011)
+++ hal_lld.h (working copy)
@@ -2067,6 +2067,9 @@
#endif /* STM32_CLOCK48_REQUIRED */
#if defined(STM32F413xx) || defined(STM32F446xx)
+#if !defined(STM32_TIMPRE)
+#define STM32_TIMPRE STM32_TIMPRE_PCLK
+#endif
#if STM32_TIMPRE == STM32_TIMPRE_HCLK
/**
* @brief Clock of timers connected to APB1
- Attachments
-
- RT-STM32F413ZH-NUCLEO144.zip
- (5.15 MiB) Downloaded 195 times
Return to “Small Change Requests”
Who is online
Users browsing this forum: No registered users and 5 guests