STM32H743 errata

[Handzic.Dirk]

Posted on May 24, 2018 at 12:03

I have designed a board using the STM32H743II. During integration testing of the software I have found the following issues related to the microcontroller (SCB->CPUID 0x411fc271) :

1)SPI1 and ADC1 is not working when using PLL2 P output due to the bit DIVP2EN in RCC_PLLCFGR stuck at '0'. This is probably true for all peripherals which could use PLL2 output P. PLL3 output P works fine as clocksource.

2)ADC1 is not working when using PLL3 R output due to the bit DIVR3EN in RCC_PLLCFGR stuck at '0'. This is probably true for all peripherals which could use PLL3 output R. PERCLK works fine as ADC1 clock source,

3) TIM2->ARR is 0x00000000 after reset NOT as in the RM 0xFFFFFFFF and will not start counting even when configured as up counter as long as ARR is 0x00000000 (which is not outlined in the RM either). Thanks Jan Waclawek for the help!

Hopefully this will spare other developers some time. I spent a couple of days on it before I found the reason and a solution.

Best regards

Dirk

[Amel NASRI]

Posted on May 25, 2018 at 13:26

Hi

Handzic.Dirk

‌,

1)SPI1 and ADC1 is not working when using PLL2 P output due to the bit DIVP2EN in RCC_PLLCFGR stuck at '0'. This is probably true for all peripherals which could use PLL2 output P. PLL3 output P works fine as clocksource.

==> Is there any other peripheral using PLL2Q or PLL2R?

2)ADC1 is not working when using PLL3 R output due to the bit DIVR3EN in RCC_PLLCFGR stuck at '0'. This is probably true for all peripherals which could use PLL3 output R. PERCLK works fine as ADC1 clock source,

==> Is there any other peripheral using PLL3P or PLL3Q?

In fact there is an issue with RCC driver in the STM32CubeH7 package when using more than one output on PLL2 or PLL3 as clock source for 2 or more peripherals. A patch is developped and should be deployed in coming release of the package.

Please let me know if you would like to test this patch in order to confirm if this is really the root cause of the issue or not.

3) TIM2->ARR is 0x00000000 after reset NOT as in the RM 0xFFFFFFFF and will not start counting even when configured as up counter as long as ARR is 0x00000000 (which is not outlined in the RM either). Thanks Jan Waclawek for the help!

==> I suggest to follow this problem in 

https://community.st.com/s/feed/0D50X00009XkZJuSAN

-Amel

[Tesla DeLorean]

Posted on May 25, 2018 at 14:34

>>Please let me know if you would like to test this patch in order to confirm if this is really the root cause of the issue or not.

Yes, I'd like whatever patched RCC code you can supply, issues here can be particularly difficult to understand, and the clock routing on the H7 is complex/critcal. The issues with SDMMC clocks also stem from the PLL configuration modes and interactions. The Peripheral Clock HAL code strikes me as rather confusing.

Also can someone please refactor to the Get PLL functions so they don't read the same PLL/RCC registers a dozen times, these registers are 'volatile' and the compile cannot optimize this code. Take a snap shot of the value into a local copy and process that.

Example for F7 PLL decoder

https://community.st.com/0D50X00009Xki9ZSAR

I have something similar for the H7, search isn't helping me right now, will find again later

Ok, this thread, it uses the ST functions I think need refactoring

https://community.st.com/0D50X00009XkhUQSAZ

I find that I need to write these clock decoder/cracking routines to I can understand what's going on internally.

[Amel NASRI]

Posted on May 25, 2018 at 17:10 The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6uG&d=%2Fa%2F0X0000000bxk%2F65ghTvVQKhEXjiRv5.bEHmOD6xTF0U50gwzQlJ2RxbI&asPdf=false

[Handzic.Dirk]

Posted on May 25, 2018 at 15:43

Hi Amel N,

1)SPI1 and ADC1 is not working when using PLL2 P output due to the bit DIVP2EN in RCC_PLLCFGR stuck at '0'. This is probably true for all peripherals which could use PLL2 output P. PLL3 output P works fine as clocksource.

==> Is there any other peripheral using PLL2Q or PLL2R?

:: No, not what I am aware of. Could you please explain which constraints there are on PLL output usage?

2)ADC1 is not working when using PLL3 R output due to the bit DIVR3EN in RCC_PLLCFGR stuck at '0'. This is probably true for all peripherals which could use PLL3 output R. PERCLK works fine as ADC1 clock source,

==> Is there any other peripheral using PLL3P or PLL3Q?

:: Yes, I changed SPI1 to use PLL3 output P instead of PLL2 output P as CubeMx suggested.

In fact there is an issue with RCC driver in the STM32CubeH7 package when using more than one output on PLL2 or PLL3 as clock source for 2 or more peripherals. A patch is developped and should be deployed in coming release of the package.

Please let me know if you would like to test this patch in order to confirm if this is really the root cause of the issue or not.

:: As far as I could see it is just impossible to set the DIVP2EN bit even using a statement as *(__IO uint32_t *) 0x5802442C |= 0x00080000 would not set the bit.

3) TIM2->ARR is 0x00000000 after reset NOT as in the RM 0xFFFFFFFF and will not start counting even when configured as up counter as long as ARR is 0x00000000 (which is not outlined in the RM either). Thanks Jan Waclawek for the help!

==> I suggest to follow this problem in

https://community.st.com/s/question/0D50X00009XkZJuSAN/stm32h743-tim2-input-compare

.

:: This problem is not really related to TIM2 input capture, it is a far more general problem stopping TIM2 to start counting unless ARR is not 0 and having a diffrent reset value compared to the RM.

[Amel NASRI]

Posted on May 25, 2018 at 16:23

In the first case, could you please share your project or your .ioc file to test the generated code from my side as I am not facing an issue in such case: PLL2P used as clock source for SPI1 & ADC1.

Then, if

PLL2 is already enabled , you cannot set  the 

bit DIVP2EN. This is what we say in RM0433 (p304):

-Amel

[Handzic.Dirk]

Posted on May 25, 2018 at 16:50

Hi Amel N,

please find attached the ioc file. Note that I have change the PLL clock routing in order to make the SPI1 and ADC1 working!

In HAL_RCCEx_PeriphCLKConfig() __HAL_RCC_PLL2CLKOUT_ENABLE(RCC_PLL2_DIVP); is called but using the debugger I found that DIVP2EN in RCC_PLLCFGR will NOT be set.

Regards

Dirk

________________ Attachments : SRMS.ioc.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxYW&d=%2Fa%2F0X0000000azt%2Fncy7JFAwhbdlyYkrKgnqEinejtlr9QF64EgKgmWBey4&asPdf=false

[Torsten Jaekel]

Posted on June 21, 2018 at 20:52

WHAUUU - GREAT - it works with this fix:

now I can use PLL2 for SDMMC and also PLL3 for USB plus I2C - all works fine now.

Thank you.

BTW:

don't forget to modify the prototypes:

//ERRATA

static HAL_StatusTypeDef RCCEx_PLL2_Config(RCC_PLL2InitTypeDef *pll2, uint32_t Divider);static HAL_StatusTypeDef RCCEx_PLL3_Config(RCC_PLL3InitTypeDef *pll3, uint32_t Divider);

[Amel NASRI]

Fix deployed in STM32CubeH7 v1.3.0 currently available on the web.

[T J]

what was the actual fix ?

check to see if DIVP2EN is set ?

after you run __HAL_RCC_PLL2CLKOUT_ENABLE(RCC_PLL2_DIVP); ?

but ?

As far as I could see it is just impossible to set the DIVP2EN bit even using a statement as *(__IO uint32_t *) 0x5802442C |= 0x00080000 would not set the bit.

in the IOC cube file;

I have change the PLL clock routing in order to run the SPI1 and ADC1 correctly.

(this file is not attached)

@Amel NASRI​ 

The following parameters cannot be changed after the PLL is enabled:  
DIVNx,PLLxRGE, PLLxVCOSEL, DIVPx, DIVQx, DIVRx,DIVPxEN, DIVQxEN, DIVRxEN.