Page 2 of 3

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Posted: Mon May 07, 2018 1:47 pm
by Giovanni
Hi,

The correct approach would be to add a guard for the setting:

Code: Select all

#if !defined(STM32_TIMPRE) || defined(__DOXYGEN__)
#define STM32_TIMPRE STM32_TIMPRE_PCLK
#endif


All other settings are done this way.

I am adding it.

Giovanni

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Posted: Mon May 07, 2018 2:41 pm
by FXCoder
Thanks for implementing correctly...
FYI the release note says RCC_CFGR register... should say RCC_DKCFGR register.

Bob

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Posted: Mon May 14, 2018 1:08 pm
by Giovanni
Hi,

I decided to rework the STM32F4 HAL support, it was way too complex and had several problems. It is now divided in two parts, one is specific for the F413. I hope to not have introduced regressions while doing this but we should be better off now.

I also included the F413 demo.

Giovanni

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Posted: Mon May 14, 2018 2:09 pm
by FXCoder
Thanks.
The hal_lld_type2.h still has some F446 conditional remnants in the TIM_CLK code (1322-1364) that can be cleared out.
I'll remove those and give the revised hal_lld_type2.h a try on the Pecan project mid -week.

Also are both defines intentional for mcuconf.h?

Code: Select all

/*
 * Configuration-related checks.
 */
#if !defined(STM32F4xx_MCUCONF)
#error "Using a wrong mcuconf.h file, STM32F4xx_MCUCONF not defined"
#endif

#if defined(STM32F413xx) && !defined(STM32F413_MCUCONF)
#error "Using a wrong mcuconf.h file, STM32F413_MCUCONF not defined"
#endif


The demo is missing STM32F413_MCUCONF so I figured maybe there was a late change on the #define name?
--
Bob

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Posted: Mon May 14, 2018 4:06 pm
by Giovanni
The demo I committed has that definition in mcuconf.h, this will be extended to all mcuconf.h files in future, this way I will be able to identify the mcuconfs and update them from templates, like we already do with chconfs and halconfs.

I fixed that F446 remains and made some other changes too. Please update and evaluate the latest one.

Giovanni

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Posted: Tue May 15, 2018 3:58 am
by FXCoder
OK. Thanks for the additional work.

Regarding the common timer section for TIMPRE in hal_lld.h (lines 200-239)...
The TIMPRE handling in F413 and F446 are different (have to check if others are affected as well).
The F413 HCLK * 4 applies after prescaler division factor of 2 (RM0430 section 6.2)
The F446 HCLK * 4 applies after prescaler division factor of 4 (RM0390 section 6.2)

To avoid having an individual platform conditional in the common code maybe add a #define like STM32_TIMPRE_HCLK_START 2 (or 4) (or whatever name you think) to the hal_lld_type1.h and hal_lld_type2.h (with guards as appropriate).
Then test STM32_TIMPRE_HCLK_START in the common code?

--
Bob

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Posted: Tue May 15, 2018 7:23 am
by Giovanni
Hi,

It is 1,2 and 4 for most devices, I checked all RMs, on two older devices it is 1,2 but I think it could be an error. The exception is 1,2 anyway.

Giovanni

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Posted: Thu May 17, 2018 2:58 pm
by FXCoder
Hi Giovanni.
I posted a question to STM on the F413 versus F446.
The response was that the TIMPRE handling in the RM for the F413 is indeed correct and is different to the F446.
Due to the lower max APB speed of the F413 versus the F446 the multiplier applies after pre-scaler of 2 for the F413.

So a conditional (platform specific check or generalized #define) revision of the hal configuration will be needed.

--
Bob

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Posted: Thu May 17, 2018 3:24 pm
by Giovanni
Hi,

If you have time add a conditional to hal_lld.h but we need to consider all F4s do the condition should be on the "exceptions".

Giovanni

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Posted: Fri May 18, 2018 5:07 am
by FXCoder
On my list for next week...