[SOLVED] STM32VL-Discovery Serial1 recv doesn’t work

I noticed that STM32vl-discovery board has now been added. I gave it a spin, Serial1.print() seems fine and spews characters. However trying to use the Serial.availble() never seems to receive any characters. I put a scope probe on PA10 and the idle voltage is ~400mA. If I type characters into the terminal program I can see data arriving. However, the voltage is way too low.

If I use the same usb dongle (a cp2102) on a Nucleo-F030R8 Board on D2/D8 it shows proper signal levels and works properly echoing characters.

Have anyone else had success using Hardware Serial1 with the STM32vl-discovery board?

Here is the code I used:
void setup() {
Serial1.begin(9600);
Serial1.println("Echo type some stuff");
}

void loop() {
if ( Serial1.available() ) {
int c = Serial1.read();
Serial1.write(c);
}
}

Hi Rick,
As Said I do not have a STM32VL disco.
I’ve just review the code and Serial definition seems correct (pinname, pin number, USART number, IRQ,…).
Have you try to do a loop btw Rx and Tx?

As the VL does not have USB Serial handy, it could be the PA9/PA10 uart is Serial (not Serial1).

[Pito – Tue Aug 08, 2017 6:49 am] –
As the VL does not have USB Serial handy, it could be the PA9/PA10 uart is Serial (not Serial1).

Yeah it is using PA9/PA10. I commented above that the output works fine. It is only the receive side that is not working. It isn’t ending up in the IRQ nor is the signal level correct.

To test and see if I can use Stm32CubeMx / HAL with this stm32vl board I took one of the STM32CUBE example projects for the stm32vl-discovery board and got it to compile with Eclipse. Sadly, they don’t provide either a gcc makefile project or a sws4stm32 project for any of the stm32vl examples. I just slogged through it and got the UART_HyperTerminal_DMA demo application to compile and load. And yes it does work fine. It sends and receives properly and the signal levels on the pins are what I would expect.

I’m guessing the stm32vl-discovery board variant in the stm32 core is the source of the problem. This I deduced after trying a newly received NUCLEO-F103RB board which works fine with the same usb dongle as I used with the stm32vl-discovery. That uses the same F1 core code ( uart.c / HardwareSerial.cpp ) stuff. I was mainly putting this issue out there for the ST guys to notice.

I think issue comes fom the HAL for F1. I will release soon an update of the F1 HAL with Uart Updated.
That’s why it probably works with the cubemx.

Update of the F1 are available in this PR:
https://github.com/stm32duino/Arduino_C … 32/pull/78

[fpiSTM – Wed Aug 09, 2017 8:29 pm] –
I think issue comes fom the HAL for F1. I will release soon an update of the F1 HAL with Uart Updated.
That’s why it probably works with the cubemx.

I tried your latest check-in and it didn’t change anything for the better. The STM32F100RB VL-board still is broken with regard to Serial input.

Ok. Thanks forthe test. I will try to get a vldisco to debug this issue. Maybe a specific part for F100 in the HAL.

OK I’ve spent a bunch of time looking at this trying to figure out why receive doesn’t work for the stm32vl-discovery.

I’ve compared the NUCELO_F103RB to the DISCO_F100RB variant directories. I focused on just trying to get PA2/PA3 working.
I noticed that the F103 has the PA2/PA3 commented out of all tables except the uart ones so I changed the F100 to do the same thing. It didn’t fix anything, no change.

I spent in inordinate amount of time in debug, checking to see that the USART2_IRQHandler is working. It always works on
receive for the F103 but doesn’t ever work for the F100. Both chips trigger the USART2_IRQHandler when a character is transmitted.
I’m at a loss because I don’t know the HAL_UART code very well. My one comment would be why are there so many state variables associated with the state of the device instead of just using the USART hardware registers to decide what is going on.

The code for the uart.c seems to be the same for F100 and the F103. I’m not sure what else to look at.

The code creates and appropriate USART IRQ handler. The code does trigger the IRQ handler at least for transmit. The HAL code is overly complex and hides what is going on to the point that I can’t debug it.

As another data point the BluePill in the F1_Merge_Other branch exhibits the same problem. So I don’t think it is specifically a F100 issue.
Also, I can use the same VL-Discovery Board with the stm32duino/libmaple core and the same .ino file and it works fine.

@fpiSTM Are you making any progress on this? I’m hopeful if you figure this out you might also be able to provide the same fix for the BluePill.

Currently not Rick
I’m trying to get a vldisco. But as you said there is the same issue on BP. I will focus on it.
Thanks for your time to try debugging this issue.
Keep in touch

Rick, Could you test by adding in uart.c, function: void uart_init(serial_t *obj) in the //Configure uart part

huart->gState = HAL_UART_STATE_RESET;


I tried that … no difference.

As another data point, I went into the debugger and before the line I added was executed it was already set to HAL_UART_STATE_RESET

Breakpoint 3, uart_init (obj=obj@entry=0x20000218 <Serial+148>) at /home/kimballr/Arduino/hardware/st/stm32/cores/arduino/stm32/uart.c:248
248 huart->Init.OverSampling = UART_OVERSAMPLING_16;
(gdb) l
243 huart->Init.WordLength = obj->databits;
244 huart->Init.StopBits = obj->stopbits;
245 huart->Init.Parity = obj->parity;
246 huart->Init.Mode = UART_MODE_TX_RX;
247 huart->Init.HwFlowCtl = UART_HWCONTROL_NONE;
248 huart->Init.OverSampling = UART_OVERSAMPLING_16;
249 // huart->Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;
250 huart->gState = HAL_UART_STATE_RESET;
251
252 if(HAL_UART_Init(huart) != HAL_OK) {
(gdb) p/x huart->gState
$9 = 0x0
(gdb) p huart->gState
$10 = HAL_UART_STATE_RESET
(gdb) n
250 huart->gState = HAL_UART_STATE_RESET;
(gdb) n
252 if(HAL_UART_Init(huart) != HAL_OK) {
(gdb) p huart->gState
$11 = HAL_UART_STATE_RESET
(gdb) p/x huart->gState
$12 = 0x0
(gdb) p *huart
$13 = {Instance = 0x40004400, Init = {BaudRate = 9600, WordLength = 0, StopBits = 0, Parity = 0, Mode = 12, HwFlowCtl = 0, OverSampling = 0}, pTxBuffPtr = 0x0, TxXferSize = 0, TxXferCount = 0, pRxBuffPtr = 0x0, RxXferSize = 0, RxXferCount = 0, hdmatx = 0x0, hdmarx = 0x0, Lock = HAL_UNLOCKED, gState = HAL_UART_STATE_RESET, RxState = HAL_UART_STATE_RESET, ErrorCode = 0}


I think it was the case as compiler init all to 0 (=HAL_UART_STATE_RESET)
Thanks for the test. I will try with the BP, I’ve rebase the PR so I could test.

Issue come from GPIO config for Uart rx pin.
For F1 it should be configured as
STM_MODE_INPUT

Just to be clear, this problem isn’t fixed in the current master just in your private repo/branch, yes?

https://github.com/fpistm/Arduino_Core_ … mits/F1_AF

Yes,Rick, I’m waiting fprwi6labs comment if any before merge it