HAL bug - array overflow in HAL_RCC_GetSysClockFreq()

[richardst9]

Posted on June 10, 2016 at 17:23

The purpose of this post is to save other developers the time I have spent tracking this down. Bear with me on this - its messy.

Line 1108, of stm32f1xx_hal_rcc.c is

  if (pllmul == aPLLMULFactorTable[(uint32_t)(RCC_CFGR_PLLMULL6_5) >> POSITION_VAL(RCC_CFGR_PLLMULL)])

You'll need to know that

&sharpdefine  RCC_CFGR_PLLMULL6_5   ((uint32_t)0x00340000)

&sharpdefine  RCC_CFGR_PLLMULL      ((uint32_t)0x003C0000) and

const uint8_t aPLLMULFactorTable[12] = {0, 0, 4, 5, 6, 7, 8, 9, 0, 0, 0, 13};

You'll find that

(RCC_CFGR_PLLMULL6_5) >> POSITION_VAL(RCC_CFGR_PLLMULL)

is a constant that evaluates to 13. And when this is used to index

aPLLMULFactorTable

[12], it generates an array bounds overflow. This would seem to be a bug in the HAL library (though please tell me if I have got this wrong). I encountered this in trying to understand why I was occasionally getting the wrong baudrate. Scary, eh? #hal-bug

[richardst9]

Posted on June 11, 2016 at 10:23

The problem would appear to be in the lookup tables in stm32f1xx_hal_rcc.c (and stm32f1xx_hal_rcc_ex.c). [I can see now that I should have mentioned that this issue was found on STM32F105 as I think that makes a difference.]

I read from 13902.pdf:  8.3.2 Clock configuration register (RCC_CFGR)   Bits 21:18 PLLMUL[3:0] : PLL multiplication factor    1101: PLL input clock x 6.5 So it would appear that the index of 13 is correct but that the table is not. I think

  const uint8_t aPLLMULFactorTable[12] = {0, 0, 4,  5,  6,  7,  8,  9, 0, 0, 0, 13};

should have been

  const uint8_t aPLLMULFactorTable[14] = {0, 0, 4,  5,  6,  7,  8,  9, 0, 0, 0, 0, 0, 13};

Hopefully ST will fix this issue in future versions of the HAL source code.

[Walid FTITI_O]

Posted on June 13, 2016 at 14:10

Hi richard,

Thank you for the feedback. We will check this internally. -Hannibal-

[richardst9]

Posted on June 14, 2016 at 10:43

Hi Hannibal,

Thanks for taking a look at this. Also, I should apologise for posting in ''STM32'' when perhaps it should have been  issue posted in ''

STM32 Software Tools and Firmware

''. While we are in this area, can you explain why these lookup tables appear to be located in RAM?. Wait...I'd better start this as a new discussion in ''

STM32 Software Tools and Firmware

''. Watch that space 😉 Thanks, Richard

[antoine]

Posted on June 15, 2016 at 14:57

Hi Richard,

This is not directly related to the subject, but I'd like to know where do you find this file? I use mbed but I can't go far in programming with it. The examples I have are short, clear and all, but I can't find out how to modify them efficiently, and so I wanted to see if the answer could be in the default libraries (.h + .c/.cpp ). When I export an mbed project into Keil, I can see many many .h, like the one you mention in this post, but not the .c related to them. So my question is: where are they?

[richardst9]

Posted on June 16, 2016 at 11:26

Antoine.PM, I'm sorry but I don't know anything about mbed.

>where do you find this file?

stm32f1xx_hal_rcc.c

is part of the stm32cubef1 library provided by ST and available at their website. This file typically unpacks to ...\Drivers\STM32F1xx_HAL_Driver\Src >This is not directly related to the subject Its probably better if we don't piggyback one discussion on the back of another. Better to start a new discussion with a relevant subject so that other developers can easily find any useful information that is posted.

[antoine]

Posted on June 16, 2016 at 12:52

Ok, thank you for your answer, I'll keep digging then :p

You're right about the multiple questions on the same subject, of course, but I have several little questions about different aspects of coding on stm32 and using related softwares, and I thought it was better to ask them directly than to flood the forum with my newbie and sometimes confused questions :\