HAL gpio libary code bug

[dan2]

Posted on September 04, 2015 at 09:24

This problem has been reported in the following link.

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fbug%20in%20HAL%20library%20stm32l1xx_hal_gpio_ex%2eh&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CD...Apparently none at ST really cares!!! stm32l1xx_hal_gpio_ex.h incorrectly maps ports F, G, H when using EXTI capability. The bug is in  inSTM32Cube_FW_L1_V1.0.0The and STM32Cube_FW_L1_V1.3.0 library code.The file defines the following&sharpif defined (STM32L151xCA) || defined (STM32L151xD) || defined (STM32L152xCA) || defined (STM32L152xD) || defined (STM32L162xCA) || defined (STM32L162xD) || defined (STM32L151xE) || defined (STM32L152xE) || defined (STM32L162xE)&sharpdefine GET_GPIO_INDEX(__GPIOx__) (((__GPIOx__) == (GPIOA))? 0U :\                                   ((__GPIOx__) == (GPIOB))? 1U :\                                   ((__GPIOx__) == (GPIOC))? 2U :\                                   ((__GPIOx__) == (GPIOD))? 3U :\                                   ((__GPIOx__) == (GPIOE))? 4U :\                                   ((__GPIOx__) == (GPIOF))? 5U :\                                   ((__GPIOx__) == (GPIOG))? 6U :\                                   ((__GPIOx__) == (GPIOH))? 7U : 8U)&sharpendif It should be as follows:&sharpif defined (STM32L151xCA) || defined (STM32L151xD) || defined (STM32L152xCA) || defined (STM32L152xD) || defined (STM32L162xCA) || defined (STM32L162xD) || defined (STM32L151xE) || defined (STM32L152xE) || defined (STM32L162xE)&sharpdefine GET_GPIO_INDEX(__GPIOx__) (((__GPIOx__) == (GPIOA))? 0U :\                                   ((__GPIOx__) == (GPIOB))? 1U :\                                   ((__GPIOx__) == (GPIOC))? 2U :\                                   ((__GPIOx__) == (GPIOD))? 3U :\                                   ((__GPIOx__) == (GPIOE))? 4U :\                                   ((__GPIOx__) == (GPIOF))? 6U :\                                   ((__GPIOx__) == (GPIOG))? 7U :\                                   ((__GPIOx__) == (GPIOH))? 5U : 8U)RegardsDaniel #exti #stm32l15x/16x-gpio

[waclawek.jan]

Posted on September 05, 2015 at 14:22

A quick glance at the unusual mapping of bitfields to ports in description of SYSCFG_EXTICRx in RM0038 appears to confirm this, even if I'm not going to try to understand it as a whole.

But, Cube library can't possibly contain a bug, as ''All functions are tested with all possible parameters'', see http://www.st.com/web/en/news/n3719 . You may take it as a lesson, not to rely on ''libraries''. JW

[Nesrine M_O]

Posted on September 06, 2015 at 10:07

Hi  sulik.daniel,

I will check this problem with our development team & come back to you.Sorry for the inconvenience may bring.-Syrine –

[Nesrine M_O]

Posted on September 07, 2015 at 16:51

Hi sulik.daniel,

Sorry for the late response.Your reported issue is confirmed by our team and will be fixed in coming release of the STM32cubeL1 package.Thank you very much for your contribution to the enhancement of our STM32 related solutions.-Syrine –

[waclawek.jan]

Posted on September 07, 2015 at 21:36

No, seriously.

We all know that marketing is not here to be honest down to the details but to sell, and that there's nothing like 100% test coverage except for requirements crippled to trivial; but the above quote has to have some solid background. In other words, you probably have some unit testing in place for the Cube(s). As this case is apparently a failure of this testing procedure, can you please ask the developers to come here and share the details and the reason of failure? I understand that it's not easy to confess one's failure, but we here are all grown-ups and engineers, and we all make mistakes. And as the purpose of this forum is to convey wisdom, it's a great opportunity for your developers to show us the methods and ways to properly test the delicate combination of hardware and software these complex designs present, for all of us to learn. Thanks, Jan Waclawek

[dan2]

Posted on September 07, 2015 at 22:05

Hi Syrine,

thank you for the response, I appreciate it.RegardsDaniel

[Raouf Hosni]

Posted on September 17, 2015 at 14:04

Hello Jan, Daniel,

First, we apologize for this bug you are encountering. It will be fixed in next STM32CubeL1 V1.4.0 release planned e/o October.

As you may know it’s quite challenging to have bug free software, there are always few bugs not detected through the validation process. The root cause can be; the process is not followed as it should be, incomplete validation coverage …

However from ST we are engaged to reduce the number of bugs over time to reach this challenging bug free software. We are ensuring as well a regular maintenance of the different FW packages; either patch release to fix critical bugs, or full release to implement all the feedback we receive from our customers.

I will take this opportunity to share w/ you that we are introducing a new set of APIs, called Low Layer (LL), allowing performance and memory footprint optimization with register access level programming.

These LL APIs will be 1st introduced w/ STM32CubeL4 V1.1.0 to be available on ST web next week, deployment on all STM32 Series is ongoing with releases planned during 2016.

With regards,

Jasmin.

[John F.]

Posted on September 17, 2015 at 16:11

Hi Jasmin,

This sounds like at may be a ''good thing''. I wondered if you could explain exactly where the split is between third party (say Keil for example) middleware and the code ST produces. As far as I understand, Keil middleware now depends on lower level ST drivers ... but if they all depend on HAL and I don't want anything to do with HAL where does that leave me? I've googled all over trying to understand this and guidance from Keil seems to be use HAL or write your own drivers. I really want to understand this. Please help!