STM32F030 USART?

[rew]

Could it be that USART on STM32F030 is untested/not working?

[RoccoMarco]

Why not. You have to port a demo from testhal. Note that RT-STM32F030R8-NUCLEO64 uses Serial Driver which is a buffered version of UART driver.
Ciao,
RM

[rew]

I have started to work on my application. I had it working quite a way with "serial", but when I disable serial and enable UART, it doesn't compile. Problems in chibios system files.

Code: Select all

chibios/os/hal/ports/STM32/LLD/USARTv2/hal_uart_lld.c: In function 'translate_errors':
chibios/os/hal/ports/STM32/LLD/USARTv2/hal_uart_lld.c:35:24: error: 'USART_ISR_LBD' undeclared (first use in this function)
 #define USART_ISR_LBDF USART_ISR_LBD

As I understand things, the "SERIAL" and "UART" drivers happen to drive the same hardware, but are totally different in the way they are set up.

[RoccoMarco]

What version of ChibiOS are you using?

[rew]

Beats me. Pulled from git a few days to weeks ago.

Code: Select all

Fixed Bug #743

[RoccoMarco]

I suppose you are working on trunk. Version of kernel is in os/rt/ch.h, version of hal in os/hal/hal.h.

By the way I will take a look into it.

[Giovanni]

Apparently the F030 does not support the LBD bit.

Giovanni

[rew]

Correct!
Verified: On STM32L4 (the first family that I picked that had a similar enough USART) it is USART-> CR2 -> bit6, which is documented as "reserved" on 030.

[rew]

Adding:

Code: Select all

#define USART_ISR_LBD 0
#define USART_CR2_LBDIE 0

to a board.h helps compile the UART driver. I haven't looked into this deeply, but I would think that now the driver would in vain try to enable the break detect and then fail to get "break detected" interrupt, as if no break happened at all. This is consitent with the capabilities of the hardware.

As a more "proper" fix, I would suggest something like:

Code: Select all

#if !defined(USART_ISR_LBD) && !defined (USART_ISR_LBDF)
// Some of the cheapest CPUs do not have the break detect hardware. The bit is 
// reserved and documented to return 0 on that hardware. Defining these bits 
// to 0 for this driver effectively disables this feature in the driver.
#define USART_ISR_LBDF 0
#define USART_CR2_LBDIE 0[
#else 
... then the existing #ifndef USART_ISR_LBDF

Agreed? Should I provide a patch?

RoccoMarco, Giovanni sometimes complains he doesn't have hardware for some CPUs so he can't test things. I've offered to provide hardware for testing in "chibios headquarters". I'll offer this to you too. If you need an odd CPU or development board that I do have and you don't I'll send it to you (no cost, no obligation). I have boards for the 20 pin ssop and 64pin TQFP chips.