2018-02-07 04:33 AM
Greetings. I wasted a lot of time trying to figure out what is wrong with I2Ccommunication and thus found this issue. Following code works as it is expected to (it changes corresponding CNFy bits to 0x03 and MODEy bits to 0x03 too):
/* Configure SCL Pin as : Alternate function, High Speed, Open drain, Pull up */
LL_GPIO_SetPinMode(GPIOB, LL_GPIO_PIN_6, LL_GPIO_MODE_ALTERNATE);
LL_GPIO_SetPinSpeed(GPIOB, LL_GPIO_PIN_6, LL_GPIO_SPEED_FREQ_HIGH);
LL_GPIO_SetPinOutputType(GPIOB, LL_GPIO_PIN_6, LL_GPIO_OUTPUT_OPENDRAIN);
LL_GPIO_SetPinPull(GPIOB, LL_GPIO_PIN_6, LL_GPIO_PULL_UP);
/* Configure SDA Pin as : Alternate function, High Speed, Open drain, Pull up */
LL_GPIO_SetPinMode(GPIOB, LL_GPIO_PIN_7, LL_GPIO_MODE_ALTERNATE);
LL_GPIO_SetPinSpeed(GPIOB, LL_GPIO_PIN_7, LL_GPIO_SPEED_FREQ_HIGH);
LL_GPIO_SetPinOutputType(GPIOB, LL_GPIO_PIN_7, LL_GPIO_OUTPUT_OPENDRAIN);
LL_GPIO_SetPinPull(GPIOB, LL_GPIO_PIN_7, LL_GPIO_PULL_UP);�?�?�?�?�?�?�?�?�?�?�?
Given:
#define RF430_NRST LL_GPIO_PIN_4
#define RF430_INT LL_GPIO_PIN_5
#define RF430_I2C_SIG LL_GPIO_PIN_8
#define RF430_I2C_RD LL_GPIO_PIN_9
#define RF430_SDA LL_GPIO_PIN_7
#define RF430_SCL LL_GPIO_PIN_6
#define RF430_IO_PORT GPIOB�?�?�?�?�?�?�?�?
Next code snippet should do the same job.However for some reason it sets CNFy bits to 0x02 and MODEy bits to 0x01, which is far from what I expect to see.
LL_GPIO_InitTypeDef pin_init;
pin_init.Mode = LL_GPIO_MODE_ALTERNATE;
pin_init.OutputType = LL_GPIO_OUTPUT_OPENDRAIN;
pin_init.Speed = LL_GPIO_SPEED_FREQ_HIGH;
pin_init.Pull = LL_GPIO_PULL_UP;
pin_init.Pin = RF430_SCL;
LL_GPIO_Init(RF430_IO_PORT, &pin_init);
pin_init.Pin = RF430_SDA;
LL_GPIO_Init(RF430_IO_PORT, &pin_init);�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?
GPIO LL driver code looks like totally unreadable mess, so I can't figure outwhetherit is my bad or issue in code. However some workaround and clarification required, I think.
#gpio #ll-gpio #ll-drivers #ll #i2cSolved! Go to Solution.
2018-03-22 02:00 AM
Hello,
We would inform you that
GPIO LL driver issue is fixed with
the new patch of STM32CubeF1 Firmware package V1.6.1.
Kind Regards
Imen
2018-02-07 06:16 AM
Hello
Mischuk.Vadim
,can you please share which STM32 family you use and STM32Cubexx version you have?
Best regards,
Tilen
2018-02-07 05:11 PM
I can confirm that LL_GPIO_Init is broken in the latest STM32CubeMX version 4.24.0 at least for STM32F1 v1.6.0 (maybe others).
Whenever pins >= pin8 are configured the corresponding pin-8 is configured instead.
This is a very important bug because it may destroy your hardware by programming the wrong pins and connecting outputs to outputs.
Example:
GPIO_InitStruct.Pin = LL_GPIO_PIN_13|LL_GPIO_PIN_15;
inside the function you have
pinpos = POSITION_VAL(GPIO_InitStruct->Pin);
which uses the rbit and clz asm instructions for the 0x04a000a0 value so it returns pinpos = 5
So in the end pin 5 and 7 will be programmed instead of pins 13 and 15.
2018-02-08 02:29 AM
* @file stm32f1xx_ll_gpio.c
* @author MCD Application Team
* @version V1.1.1
* @date 12-May-2017
* @brief GPIO LL module driver.�?�?�?�?�?
STM32F1 cube 1.6.0. I use STM32F103RET6 MCU.
2018-02-08 05:24 AM
Hello,
We raisedthis issueinternally for fix.
Please refer to this discussion with same issue
https://community.st.com/0D50X00009XkhPcSAJ
Sorry for the inconvenience it may bring.
Best Regards,
Imen
2018-02-19 03:07 AM
Hello
, ,This issue is confirmed for LL Gpio pins and this will be fixed in the next release.
We propose thisfix with LL_GPIO_Init function for ll_gpio driver :
ErrorStatus LL_GPIO_Init(GPIO_TypeDef *GPIOx, LL_GPIO_InitTypeDef *GPIO_InitStruct){ uint32_t pinmask = 0x00000000U; uint32_t pinpos = 0x00000000U; uint32_t currentpin = 0x00000000U; /* Check the parameters */ assert_param(IS_GPIO_ALL_INSTANCE(GPIOx)); assert_param(IS_LL_GPIO_PIN(GPIO_InitStruct->Pin)); assert_param(IS_LL_GPIO_MODE(GPIO_InitStruct->Mode)); assert_param(IS_LL_GPIO_PULL(GPIO_InitStruct->Pull)); /* ------------------------- Configure the port pins ---------------- */ /* Initialize pinpos on first pin set */ pinmask = (GPIO_InitStruct->Pin & 0x00FFFF00U) >> 8 ; pinpos = POSITION_VAL(pinmask);/* Configure the port pins */ while ((pinmask >> pinpos) != 0U) { /* skip if bit is not set */ if ((pinmask & (1U << pinpos)) == 0U) { pinpos++; }/* Get current io position */ if(pinpos <8 ) { currentpin = (0x00000101U << pinpos); } else { currentpin = ((0x00010001U << (pinpos-8)) | 0x04000000U); } if (currentpin) { /* Pin Mode configuration */ LL_GPIO_SetPinMode(GPIOx, currentpin, GPIO_InitStruct->Mode); /* Pull-up Pull down resistor configuration*/ LL_GPIO_SetPinPull(GPIOx, currentpin, GPIO_InitStruct->Pull); if ((GPIO_InitStruct->Mode == LL_GPIO_MODE_OUTPUT) || (GPIO_InitStruct->Mode == LL_GPIO_MODE_ALTERNATE)) { /* Check Output mode parameters */ assert_param(IS_LL_GPIO_OUTPUT_TYPE(GPIO_InitStruct->OutputType));/* Output mode configuration*/ LL_GPIO_SetPinOutputType(GPIOx, currentpin, GPIO_InitStruct->OutputType);/* Speed mode configuration */ LL_GPIO_SetPinSpeed(GPIOx, currentpin, GPIO_InitStruct->Speed); }} pinpos++; } return (SUCCESS);}
Hope this is helpful for you.
Best Regards,
Imen.
2018-02-19 06:54 PM
@Vadim If you set
LL_GPIO_InitTypeDef.Mode = LL_GPIO_MODE_ALTERNATE, you also must specify theLL_GPIO_InitTypeDef.Alternate field?
This is missing in your snippet.
-- pa
2018-03-22 02:00 AM
Hello,
We would inform you that
GPIO LL driver issue is fixed with
the new patch of STM32CubeF1 Firmware package V1.6.1.
Kind Regards
Imen