cancel
Showing results for 
Search instead for 
Did you mean: 

UART5 transmits before reaching main when debugging.

AHefn
Associate II

I am new to STM32xxxx and STM32CubeIDE/MX. I am using a STEVAL-IDP004V1 board with an ST32F4205RBT. I am trying to do a simple Hello World test program that simply transmits "Hello World!" via UART5 and an ST3485 RS485 chip.

The problem is, once the program is run (in debug) one time, the next time I try to debug it, it transmits "Hello World!" followed by a NULL before reaching the default breakpoint in main. Then when click on the Resume button, it executes the intended code and transmits "Hello World!" as it should.

On the terminal screen (Termite), I receive:

Hello World!

[00]

After clicking the Resume button, I receive:

Hello World!

This time without the trailing NULL.

Here is a clip of my source code:

int main(void)

{

 /* USER CODE BEGIN 1 */

uint8_t au8_Tx_Data[TX_BUFFER_LEN] = "Hello World!\r";

uint8_t au8_Rx_Data[RX_BUFFER_LEN];

 /* 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_UART5_Init();

 /* USER CODE BEGIN 2 */

HAL_GPIO_WritePin(ST3485DE_GPIO_Port, ST3485DE_Pin, GPIO_PIN_SET); //TX enable

HAL_Delay(2);

HAL_UART_Transmit(&huart5, au8_Tx_Data, strlen((const char *)au8_Tx_Data), 10);

while(!__HAL_UART_GET_FLAG(&huart5, UART_FLAG_TC));

HAL_Delay(2);

HAL_GPIO_WritePin(ST3485DE_GPIO_Port, ST3485DE_Pin, GPIO_PIN_RESET); //RX enable

 /* USER CODE END 2 */

 /* Infinite loop */

 /* USER CODE BEGIN WHILE */

 while (1)

  {

   /* USER CODE END WHILE */

   /* USER CODE BEGIN 3 */

  }

 /* USER CODE END 3 */

}

2 REPLIES 2
Pavel A.
Evangelist III

This is because the CubeIDE debugger before reprogramming resets the target and may let it run.

So you can see some activity of the previously programmed version.

If this is a problem, try to tweak the pre-load debugger script.

-- pa

AHefn
Associate II

Thank you Pavel. I was concerned that the program was somehow corrupted. I have since seen other posts about this, including doing a full chip erase with the ST-Link utility, which works, but you have to do it every time before you start a debug session. Some people suggested putting a delay of several seconds at the beginning of the program, but that also delays startup of the intended code.

I tested the program stand alone, and it works fine. Now that I know that this is just a debugger issue, I can ignore any left over activity. Since this was just a test drive of STM32CubeIDE, it is not a problem to me. Now I can move on to writing some real code, but I may check out the pre-load debugger script, just for fun.

Albert H.