2024-09-03 08:01 AM - edited 2024-09-03 08:57 AM
Hi all,
I own a STM32MP135F-DK board and started to write a simple firmware on it based on RTX threads.
I'd like to use USART1 port as simple terminal interface with the board.
I chose USART1 cause it is present on CN8 connector (RX + TX) and cause the UART8 presents only TX pin.
The code I wrote is:
void MX_USART1_UART_Init(void)
{
huart1.Instance = USART1;
huart1.Init.BaudRate = 9600;
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;
if (HAL_UART_Init(&huart1) != HAL_OK)
{
ASSERT(false);
}
}
and
if (uartHandle->Instance == USART1)
{
/* USER CODE BEGIN USART1_MspInit 0 */
/* USER CODE END USART1_MspInit 0 */
/* USART1 clock enable */
__HAL_RCC_USART1_CLK_ENABLE();
__HAL_RCC_GPIOB_CLK_ENABLE();
__HAL_RCC_GPIOC_CLK_ENABLE();
/**USART1 GPIO Configuration
PC2 ------> USART1_RTS
PC0 ------> USART1_TX
PB0 ------> USART1_RX
*/
GPIO_InitStruct.Pin = GPIO_PIN_0 | GPIO_PIN_2;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);
GPIO_InitStruct.Pin = GPIO_PIN_0;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
GPIO_InitStruct.Alternate = GPIO_AF4_USART1;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
/* USART3 interrupt Init */
GIC_SetPriority(USART1_IRQn, 0);
GIC_EnableIRQ(USART1_IRQn);
/* USER CODE BEGIN USART1_MspInit 1 */
/* USER CODE END USART1_MspInit 1 */
}
I'm wondering if this code is correct cause, connecting to the CN8 pins a 232-USB FTDI232 converter I see nothing on the terminal running on Windows.
If I comment out the GIC_EnableIRQ() lines the firmware continue to run (without any serial output): I see the firmware is alive cause a task that blinks red and blue LEDS.
If I leave the IRQ (and I transmit something) the LEDs task freeze and if I press pause IDE button I almost always land in the IRQ_EndOfInterrupt() function (or nearby - irqarmv7a.S), with irqn=70 (USART1_IRQn).
If I try with UART8 I have the same behaviors but irqn=116 (UART8_IRQn).
Any idea, please?
Solved! Go to Solution.
2024-09-09 12:39 AM - edited 2024-09-09 12:39 AM
It is a bare metal programming.
I've found the working UART1 configurations:
GPIO_InitStruct.Pin = GPIO_PIN_0;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
GPIO_InitStruct.Alternate = GPIO_AF7_USART1;
HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);
GPIO_InitStruct.Pin = GPIO_PIN_0;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_PULLUP;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
GPIO_InitStruct.Alternate = GPIO_AF4_USART1;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
In general, whare I can find the possible pins configuration, including the alternate modes?
Thanks!
2024-09-04 03:07 AM
Partial solutions:
UART8:
This way I'm able to receive on Windows side the output. But on the CN8 connector there is not the UART8_RX pin.
UART1: applied the same changes. The UART1_IRQHandler() only receives FRAME_ERROR irq.
2024-09-04 09:12 AM - edited 2024-09-04 09:14 AM
Following the UART8 way, I wrote some functions to handle the debug outputs toward UART8.
The source is:
/*
* serial_dbg.c
*
* Created on: Sep 4, 2024
*
*/
#include <stdio.h>
#include <stdarg.h>
#include "system.h"
#include "stm32mp13xx_it.h"
#include "serial_dbg.h"
#define DBGMSG_MAX_STRING_LENGTH 128
static UART_HandleTypeDef huartDbg;
static __IO ITStatus UartReady = RESET;
void serial_dbg_output(const char *format, ...)
{
static va_list args;
static uint32_t length;
if (huartDbg.Instance == 0)
return;
char Trace_Buffer[DBGMSG_MAX_STRING_LENGTH + 1];
va_start(args, format); //lint !e718 !e727 !e746 !e530
length = vsnprintf(Trace_Buffer, sizeof(Trace_Buffer), format, args);
if (length > DBGMSG_MAX_STRING_LENGTH)
{
length = DBGMSG_MAX_STRING_LENGTH;
Trace_Buffer[DBGMSG_MAX_STRING_LENGTH - 2] = '.';
Trace_Buffer[DBGMSG_MAX_STRING_LENGTH - 1] = '.';
Trace_Buffer[DBGMSG_MAX_STRING_LENGTH] = '\0';
}
va_end(args); //lint !e718 !e746
if(HAL_UART_Transmit_IT(&huartDbg, (uint8_t*)Trace_Buffer, length)!= HAL_OK)
{
Error_Handler();
}
while (UartReady != SET){}
/* Reset transmission flag */
UartReady = RESET;
}
/* UARTDbg init function */
static void MX_UARTDbg_Init(void)
{
huartDbg.Instance = UART8;
huartDbg.Init.BaudRate = 9600;
huartDbg.Init.WordLength = UART_WORDLENGTH_8B;
huartDbg.Init.StopBits = UART_STOPBITS_1;
huartDbg.Init.Parity = UART_PARITY_NONE;
huartDbg.Init.Mode = UART_MODE_TX_RX;
huartDbg.Init.HwFlowCtl = UART_HWCONTROL_NONE;
huartDbg.Init.OverSampling = UART_OVERSAMPLING_16;
huartDbg.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;
huartDbg.Init.ClockPrescaler = UART_PRESCALER_DIV1;
huartDbg.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;
if (HAL_UART_Init(&huartDbg) != HAL_OK)
{
Error_Handler();
}
if (HAL_UARTEx_SetTxFifoThreshold(&huartDbg, UART_TXFIFO_THRESHOLD_1_8) != HAL_OK)
{
Error_Handler();
}
if (HAL_UARTEx_SetRxFifoThreshold(&huartDbg, UART_RXFIFO_THRESHOLD_1_8) != HAL_OK)
{
Error_Handler();
}
if (HAL_UARTEx_DisableFifoMode(&huartDbg) != HAL_OK)
{
Error_Handler();
}
}
/*
*/
void serial_dbg_init()
{
char initMsg[] = "-- DEBUG STARTED --\r\n";
MX_UARTDbg_Init();
serial_dbg_output(initMsg);
}
void UART8_IRQHandler(void)
{
HAL_UART_IRQHandler(&huartDbg);
}
void HAL_UART_TxCpltCallback(UART_HandleTypeDef *UartHandle)
{
/* Set transmission flag: transfer complete */
UartReady = SET;
}
The functions are callled within application_init() function, generating some debug outputs between some init functions.
Now it happens that, after the call to serial_dbg_init(), if I call a function that contains a task creation, for example
Usb_App_Thread_Id = osThreadNew(usb_app_task, NULL, &Usb_App_Thread_Attributes);
the firmware hangs.
WhenI press pause button, I land in an infinite loop (while(1);) inside the CUndefHandler() function in the file RTX/Src/handlers.c, calld by Undef_Handler() in RTX/Src/irq_armv7a.S
Without the serial_dbg_init() call there are not problems.
Any idea?
2024-09-05 06:11 AM
Is this bare metal programming and the STM32MP13 or using Linux ?
2024-09-09 12:39 AM - edited 2024-09-09 12:39 AM
It is a bare metal programming.
I've found the working UART1 configurations:
GPIO_InitStruct.Pin = GPIO_PIN_0;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
GPIO_InitStruct.Alternate = GPIO_AF7_USART1;
HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);
GPIO_InitStruct.Pin = GPIO_PIN_0;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_PULLUP;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
GPIO_InitStruct.Alternate = GPIO_AF4_USART1;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
In general, whare I can find the possible pins configuration, including the alternate modes?
Thanks!
2024-09-09 01:38 AM
Hi @SteMMo ,
@SteMMo wrote:
In general, whare I can find the possible pins configuration, including the alternate modes?
Information is present in product Datasheet or in a more friendly way using STM32CubeMx.
Regards.