I can not trust the MX plugin to generate the right code. I cannot get the serial port to work at all with the generated code. It used to work no problem.

KiptonM · ‎2022-06-27

First the GUI is all screwed up.

When I look at USART2 It gives me the choices for

GPIO output level,

GPIO mode,

GPIO Pull-up/Pull-down

Maximum output speed

User Label,

it is missing Fast Mode.

I click down to USART1_TX and the list is different. It has

GPIO mode,

GPIO Pull-up/Pull-down

Maximum output speed,

Fast Mode

User Label

This one is missing GPIO Output Level.

And it says it is "Modified" I told it to revert to the default and it is still "Modified"

This is a known problem, but it does not help me that it is known.

Here is the code generated.

/**
  * @brief USART1 Initialization Function
  * @param None
  * @retval None
  */
static void MX_USART1_UART_Init(void)
{
 
  /* USER CODE BEGIN USART1_Init 0 */
 
  /* USER CODE END USART1_Init 0 */
 
  /* USER CODE BEGIN USART1_Init 1 */
 
  /* USER CODE END USART1_Init 1 */
  huart1.Instance = USART1;
  huart1.Init.BaudRate = 115200;
  huart1.Init.WordLength = UART_WORDLENGTH_8B;
  huart1.Init.StopBits = UART_STOPBITS_1;
  huart1.Init.Parity = UART_PARITY_NONE;
  huart1.Init.Mode = UART_MODE_TX_RX;
  huart1.Init.HwFlowCtl = UART_HWCONTROL_NONE;
  huart1.Init.OverSampling = UART_OVERSAMPLING_16;
  huart1.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;
  huart1.Init.ClockPrescaler = UART_PRESCALER_DIV1;
  huart1.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;
  if (HAL_UART_Init(&huart1) != HAL_OK)
  {
    Error_Handler();
  }
  if (HAL_UARTEx_SetTxFifoThreshold(&huart1, UART_TXFIFO_THRESHOLD_1_8) != HAL_OK)
  {
    Error_Handler();
  }
  if (HAL_UARTEx_SetRxFifoThreshold(&huart1, UART_RXFIFO_THRESHOLD_1_8) != HAL_OK)
  {
    Error_Handler();
  }
  if (HAL_UARTEx_DisableFifoMode(&huart1) != HAL_OK)
  {
    Error_Handler();
  }
  /* USER CODE BEGIN USART1_Init 2 */
 
  /* USER CODE END USART1_Init 2 */
 
}

It looks good. I do not see an error in it. Can anyone else?

In my main program it has

int main(void)
{
  /* USER CODE BEGIN 1 */
 
  /* USER CODE END 1 */
 
  /* MCU Configuration--------------------------------------------------------*/
 
  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  HAL_Init();
 
  /* USER CODE BEGIN Init */
 
  /* USER CODE END Init */
 
  /* Configure the system clock */
  SystemClock_Config();
 
  /* USER CODE BEGIN SysInit */
 
  /* USER CODE END SysInit */
 
  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_DMA_Init();
  MX_ADC1_Init();
  MX_I2C1_Init();
  MX_TIM2_Init();
  MX_TIM3_Init();
  MX_TIM14_Init();
  MX_USART2_UART_Init();
  MX_USART1_UART_Init();
 
  /* Initialize interrupts */
  MX_NVIC_Init();
  /* USER CODE BEGIN 2 */
 
  uint8_t data[] = "Hello World ***********\r\n";
 
  HAL_UART_Transmit(&huart1, data, sizeof(data), 100);
 
  HAL_Delay(250);
  __NOP();

I put a break point at the __NOP();

The logic analyzer says the UART1 TX pin did not move at all.

The serial port used to work. I like to use it for debugging. I print messages out to see what is going on when it is running. So it is the first thing I get to work when I bring up a new board. The pinout of the STM32G031K6T and STM32G051K8T are exactly the same and both have USART1 and USART2 to the same pins.

Because the MX does not transition from one chip to another (another bug that will be fixed in another version) I started another project. And am trying to bring it up peripheral by peripheral, and USART1 is the first one. The clocks are setup the same. 64 MHz in both cases.

,

I do not trust the latest MX add-in or anything about it, but I do not see what could cause it not to work even in polling mode.

Thanks,

KiptonM · ‎2022-06-27

I opened up another bug report for the GPIO Registers.

The STM32CubeIDE has a debugger window that lets you look at the SPF (Special Function Registers). Why are the set of GPIO registers not included. I am trying to see if RA2 and RA9 are set up the same. But I do not know how to look at them in the debugger

But I found the issue that I was trying to solve here.

The MX program correctly set USART2_TX to alternate function AF1 but left USART1_TX as alternate function AF0 when it should have been AF1 also. That was why I was trying to look at the GPIO registers. Yet another MX program bug...

That only took 8 hours to track down.

View solution in original post

KiptonM · ‎2022-06-27

It looks like USART2 works. When I could not get USART1 to work, I decided to give USART2 a shot.

the main was changed like this

int main(void)
{
  /* USER CODE BEGIN 1 */
 
  /* USER CODE END 1 */
 
  /* MCU Configuration--------------------------------------------------------*/
 
  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  HAL_Init();
 
  /* USER CODE BEGIN Init */
 
  /* USER CODE END Init */
 
  /* Configure the system clock */
  SystemClock_Config();
 
  /* USER CODE BEGIN SysInit */
 
  /* USER CODE END SysInit */
 
  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_DMA_Init();
  MX_ADC1_Init();
  MX_I2C1_Init();
  MX_TIM2_Init();
  MX_TIM3_Init();
  MX_TIM14_Init();
  MX_USART2_UART_Init();
  MX_USART1_UART_Init();
 
  /* Initialize interrupts */
  MX_NVIC_Init();
  /* USER CODE BEGIN 2 */
 
  uint8_t data[] = "Hello World ***********\r\n";
 
  HAL_UART_Transmit(&huart1, data, sizeof(data), 100);
  HAL_UART_Transmit(&huart2, data, sizeof(data), 100);
  HAL_Delay(250);
  __NOP();

Basically copied line 40 which did not work, to line 41 and changed the &huart1 to &huart2. Logic analyzer saw the UART2 data but not the UART1 data.

I just verified the MX plug-in setup and UART2 still has the setup for DMA , but while there is a variable for DMA_HandleTypeDef hdma_usart2_tx; The MX generated code does not use it at all. (Probably another known bug...) so the DMA is not setup.

KiptonM · ‎2022-06-27

Well this is curious. I just looked at the registers for both USART1 and USART2 and they are identical!

So it is not the setup of the USART1 or USART2 that one works and the other does not.

It must be the GPIO for the two TX pins.

KiptonM · ‎2022-06-27

Why can't I see the GPIO registers in the debugger?

Am I missing them?

KiptonM · ‎2022-06-27

I opened up another bug report for the GPIO Registers.

The STM32CubeIDE has a debugger window that lets you look at the SPF (Special Function Registers). Why are the set of GPIO registers not included. I am trying to see if RA2 and RA9 are set up the same. But I do not know how to look at them in the debugger

But I found the issue that I was trying to solve here.

The MX program correctly set USART2_TX to alternate function AF1 but left USART1_TX as alternate function AF0 when it should have been AF1 also. That was why I was trying to look at the GPIO registers. Yet another MX program bug...

That only took 8 hours to track down.

Andrew Neil · ‎2022-06-28

@KiptonM "I found the issue that I was trying to solve here"

Jolly good!

Please mark the solution - so that people can see that it's resolved:

Sara BEN HADJ YAHYA · ‎2022-06-28

Hello @KiptonM ,

Thanks for your feedback,

This is a known issue and it is already reported to the dev team to be fixed. I will keep you posted.

Internal ticket number: 119027(This is an internal tracking number and is not accessible or usable by customers).

Sorry for the inconveniences,

Sara.

KiptonM · ‎2022-06-28

Where are the list of known problems so I can browse them? And not have to discover them the hard way?

Sara BEN HADJ YAHYA · ‎2022-06-29

hello @KiptonM ,

This issue is fixed in STM32CubeMX latest release.

V6.6.0 is now available under this Link.

Thanks for your contribution.

Sara.

KiptonM · ‎2022-07-05

STM32CubeIDE just let me know there is an update from 1.9 to 1.10 I am installing now. Was it fixed in CubeIDE also?

I looked in the STM32CubeIDE 1.9.0 errata and I could not find it or any of the other problems I found that I was told were "known problems".

Why?

Kip