Page 1 of 1
STM32F030 USART?
Posted: Thu Jun 09, 2016 4:27 pm
by rew
Could it be that USART on STM32F030 is untested/not working?
Re: STM32F030 USART?
Posted: Thu Jun 09, 2016 4:37 pm
by 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
Re: STM32F030 USART?
Posted: Thu Jun 09, 2016 4:57 pm
by 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.
Re: STM32F030 USART?
Posted: Thu Jun 09, 2016 5:05 pm
by RoccoMarco
What version of ChibiOS are you using?
Re: STM32F030 USART?
Posted: Thu Jun 09, 2016 5:28 pm
by rew
Beats me. Pulled from git a few days to weeks ago.
Re: STM32F030 USART?
Posted: Thu Jun 09, 2016 5:31 pm
by 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.
Re: STM32F030 USART?
Posted: Thu Jun 09, 2016 5:41 pm
by Giovanni
Apparently the F030 does not support the LBD bit.
Giovanni
Re: STM32F030 USART?
Posted: Fri Jun 10, 2016 11:47 am
by 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.
Re: STM32F030 USART?
Posted: Sat Jun 11, 2016 2:30 pm
by 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.