2019-10-11 01:08 AM
To assign pull mode of output pin the function LL_GPIO_SetPinPull writes 0 or 1 to the output buffer (inside the body of LL_GPIO_Init ). Hence if pull-up or pull-down is not necessary (pull parameter equals zero) the output of the pin changes to 0.
So the routine should be corrected so that if the pull parameter is not assigned nothing is written to the output buffer. Generally, the pull parameter for output pin type is excess. It should be hiden in CubeMx.
2019-10-14 08:42 AM
Hello @Ruslan ,
This issue is already raised internally to CubeMx team for fix in the coming release.
Regards,
Imen
2019-10-14 11:25 AM
What about the libraries?
for example
-- pa
2019-10-14 11:48 AM
What do you mean by this question, @Pavel A. ?
As far as I understand the original post, this problem is 'F1-specific, stemming from the different GPIO registers structure.
JW
2019-10-14 12:02 PM
Is this F1 specific? Then yes this what I wanted to know. So it does not affect other families?
Even if the Cube team hides the pull up/down option on output GPIOs as the OP suggests - the library code still uses the pull field in the init struct. Either the init function should not use this field for output pins, or the Cube should generate some consistent values in GPIO init code (which calls the library), or both?
-- pa
2019-10-14 02:10 PM
> Is this F1 specific?
Thou hast faith too little in me.
> So it does not affect other families?
No. Not only is there PUPDR register for pullup/down, it also has 3 distinct settings for pull up, down and none, and the Pull element in init struct is supposed to hold one of 3 respective values - LL_GPIO_PULL_NO, LL_GPIO_PULL_UP, LL_GPIO_PULL_DOWN (see IS_LL_GPIO_PULL() "assert"). The init struct gets zeroed in the CubeMX autovomitedgenerated code, AFAIK, and not surprisingly it corresponds to LL_GPIO_PULL_NO. It *does* change previously selected pullup-down - if there was any previous setting - but that's expected behaviour, once you want to change a pin's setting.
JW