Closed noomio closed 2 years ago
Hi @noomio,
Thank you for your report. In order to allow a better analysis of this problem, could you please confirm when using the latest firmware version v1.26.2 that the issue is systematically reproducible on your side ?
Thank you again for your report.
With regards,
@RKOUSTM I updated to v1.26.2 and the issue remains.
These functions should be called at the end of the MX_GPIO_Init() instead at the beginning.
/*Configure GPIO pin Output Level */
HAL_GPIO_WritePin(SPI1_CS_GPIO_Port, SPI1_CS_Pin, GPIO_PIN_SET);
/*Configure GPIO pin Output Level */
HAL_GPIO_WritePin(GPIOB, LD1_Pin|LD3_Pin|LD2_Pin, GPIO_PIN_RESET);
Hi @noomio,
Thank you for your report. The point you reported is related to the CubeMX generation problem and not directly related to the firmware published in this repository. Unfortunately we don't treat aspect related to CubeMX tool in our GitHub repositories.
All aspects related to Cube MX tool are not handled at GitHub level. They are rather treated at ST Community level, precisely within the Cube MX dedicated section. Indeed, we are reproducing the same behavior you described but according to the CubeMX team, this behavior has not been treated as a problem. Also, no functional problems are detected with this CubeMX generation.
Now, as this issue is not directly related to some software component published within this repository (CMSIS, HAL, BSP, etc.) but rather to our ecosystem (namely the Cube MX tool), please allow me to close it.
Thank you for your contribution. We are looking forward to reading from you again.
With regards,
@noomio,
When selecting the gpio output to high the produced code set the pin high before it has been initialised.
These functions should be called at the end of the MX_GPIO_Init() instead at the beginning.
I disagree with your expectation. IMO, it should be configured (set to the desired value with HAL_GPIO_WritePin
) before it is activated (by HAL_GPIO_Init
, which does not set the hi/low state). That prevents a potentially unwanted toggle, e.g. the default/current state is 0
, you call HAL_GPIO_Init()
, it outputs the 0
, then you call HAL_GPIO_WritePin(..., GPIO_PIN_SET)
, and it outputs the 1
. As opposed to the reverse, where you never push/pull a 0
.
Is there some functional issue caused by the code CubeMX is currently generating?
@bmcdonnell-fb ok, I misunderstood the usage of the parameter in cubemx. Thanks for the clarification.
Describe the set-up CubeMX 6.3.0 STM32CubeF4 Firmware Package V1.26.0 / 12-February-2021
Describe the bug When selecting the gpio output to high the produced code set the pin high before it has been initialised.
How To Reproduce Select gpio pin to push-pull, output to high, generate code or check with scope
The modules that you suspect to be the cause of the problem (Driver, BSP, MW ...). CubeMX code genertion
The use case that generates the problem. Selecting gpio to output high
How we can reproduce the problem. With CubeMX
Code produced: