2025-01-30 02:19 AM
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?
2025-01-31 02:32 AM - edited 2025-01-31 02:36 AM
@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:
Note the UART also handles a Break as a Framing error:
2025-02-03 12:59 AM
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.
2025-02-03 02:36 AM
@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.
2025-02-03 05:31 AM
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 05:40 AM
Does it work via the ST-Link VCP?
2025-02-03 05:42 AM
Yes it works fine when i use USART1 over ST-Link VCP
2025-02-03 05:58 AM
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
2025-02-04 06:31 AM
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.
But why is that?
Next I have to check how this affects the sleep mode.
2025-02-04 07:38 AM
That sound suspicious: using an internal RC oscillator (eg, HSI) is not recommended for UART comms - an external crystal should be used.
2025-02-06 02:34 AM
In the original example BLE_p2pServer_ota from the FW package STM32Cube_FW_WBA_V1.4.1, USART1 is also set to HSI.
I tried to set PCLK2 and set the baud rate from 115200 to 19200.
Then i pushed button B1 on the NUCLEO board a view times and i get failurs with receiving characters with HTerm:
I measured the signal at pin PB12 (USART1 Tx) and the signal condition is not very well:
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?