cancel
Showing results for 
Search instead for 
Did you mean: 

Problems with USART2 Rx Callback with BLE_p2pServer_ota example

ledi7
Associate III

Hi,

i am using the BLE_p2pServer_ota example with NUCLEOWBA55 and i want transmitt a 20 Byte package over USART2 with DMA in circular mode (19200 Baud). Here as an example, i send 20 bytes every second via HTerm to USART2. BLE advertising (every 2s) is working (but i am not connected to the cellphone app). 

The Rx Callback function is inside p2p_server_app.c and here i want to toggle the blue LED:

/* USER CODE BEGIN FD_LOCAL_FUNCTIONS*/
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
   if(huart->Instance == USART2)	// Rx Callback for USART2
   {
	BSP_LED_Toggle(LED_BLUE);
   }
/* USER CODE END FD_LOCAL_FUNCTIONS*/

But after several transmissions (between 50 and 150) the callback function is no longer called.

Does anyone have an idea what is going wrong?

23 REPLIES 23

@ledi7 wrote:

I occasionally get frame errors here. 


So that's a hardware error on the wire.

Give more details about the hardware connection to this UART. Some good, clear photos would help.

Are you getting interference - eg, from the RF?

Is your baud rate marginal? Signal levels?

 

PS:

This is what gets detected as a "Framing" error:

AndrewNeil_1-1738319771069.png

 

Note the UART also handles a Break as a Framing error:

AndrewNeil_0-1738319715254.png

 

Hi @Andrew Neil ,

It's true that the signal on the interface is not really clean. But what is confusing is that when I perform the data transfer with a different code example (only UART2 DMA transfer) and the same hardware, I don't get any errors.


@ledi7 wrote:

It's true that the signal on the interface is not really clean. .


So think about why it is "not really clean"...

If the noise is caused (or exacerbated) by the BLE activity then you will obviously get more problems in a BLE example, and less in a non-BLE example.

Again, give more details about the hardware connection to this UART. Some good, clear photos would help.

@Andrew Neil 

To exclude interference from BLE, I commented out MX_APPE_Process(); in while(1). But nothing changed. 

while (1)
  {
    /* USER CODE END WHILE */
    //MX_APPE_Process();

    /* USER CODE BEGIN 3 */
  }

Attached is my "test setup" with an FTDI USB/UART converter which is connected to the PC via a 1m long shielded USB cable.

2025-02-03_14h00_19.png

 

Does it work via the ST-Link VCP?

Yes it works fine when i use USART1 over ST-Link VCP

I tried changing the baud rate and using 2 stop bits instead of one.

1 or 2 stop bits -> no change

9600 baud instead of 19200 baud -> it seems to get a little worse

115200 baud -> much better, but not without errors

ledi7
Associate III

Hi all,

I have now found the problem!

As SYSCLK I use the 32MHz HSE / 2 = 16MHz.

For USART 2 I have used PCLK1 with 16 MHz up to now. As soon as I changed the USART2 clock mux to HSI, the USART signal is OK and I have no more errors.

2025-02-04_15h29_34.png

But why is that?

Next I have to check how this affects the sleep mode.

 

That sound suspicious: using an internal RC oscillator (eg, HSI) is not recommended for UART comms - an external crystal should be used.

@Andrew Neil 

In the original example BLE_p2pServer_ota from the FW package STM32Cube_FW_WBA_V1.4.1, USART1 is also set to HSI.

2025-02-06_10h45_00.png

I tried to set PCLK2 and set the baud rate from 115200 to 19200.

2025-02-06_10h44_44.png

Then i pushed button B1 on the NUCLEO board a view times and i get failurs with receiving characters with HTerm:

 

2025-02-06_11h00_50.png

I measured the signal at pin PB12 (USART1 Tx) and the signal condition is not very well:

SCR01.PNG

Then i changed the baud rate from 19200 to 115200 and the signal condition is much better.

Are there any known problems with the silicon and HSE with USART?