Support for RCC_DKCFGR.TIMPRE in newer STM32 Topic is solved

Use this forum for requesting small changes in ChibiOS. Large changes should be discussed in the development forum. This forum is NOT for support.
User avatar
Giovanni
Site Admin
Posts: 11224
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 401 times
Been thanked: 333 times
Contact:

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Postby Giovanni » Mon May 07, 2018 1:47 pm

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

User avatar
FXCoder
Posts: 123
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 31 times
Been thanked: 31 times

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Postby FXCoder » Mon May 07, 2018 2:41 pm

Thanks for implementing correctly...
FYI the release note says RCC_CFGR register... should say RCC_DKCFGR register.

Bob

User avatar
Giovanni
Site Admin
Posts: 11224
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 401 times
Been thanked: 333 times
Contact:

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Postby Giovanni » Mon May 14, 2018 1:08 pm

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

User avatar
FXCoder
Posts: 123
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 31 times
Been thanked: 31 times

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Postby FXCoder » Mon May 14, 2018 2:09 pm

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

User avatar
Giovanni
Site Admin
Posts: 11224
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 401 times
Been thanked: 333 times
Contact:

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Postby Giovanni » Mon May 14, 2018 4:06 pm

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

User avatar
FXCoder
Posts: 123
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 31 times
Been thanked: 31 times

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Postby FXCoder » Tue May 15, 2018 3:58 am

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

User avatar
Giovanni
Site Admin
Posts: 11224
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 401 times
Been thanked: 333 times
Contact:

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Postby Giovanni » Tue May 15, 2018 7:23 am

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

User avatar
FXCoder
Posts: 123
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 31 times
Been thanked: 31 times

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Postby FXCoder » Thu May 17, 2018 2:58 pm

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

User avatar
Giovanni
Site Admin
Posts: 11224
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 401 times
Been thanked: 333 times
Contact:

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Postby Giovanni » Thu May 17, 2018 3:24 pm

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

User avatar
FXCoder
Posts: 123
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 31 times
Been thanked: 31 times

Re: Support for RCC_DKCFGR.TIMPRE in newer STM32

Postby FXCoder » Fri May 18, 2018 5:07 am

On my list for next week...


Return to “Small Change Requests”

Who is online

Users browsing this forum: No registered users and 0 guests