ChibiOS Free Embedded RTOS

Hi all,

i want to make use of the UART feature in order to unload the processor of actively sending byte by byte. However, it does not work as expected, only at the very first uartStartSend call data are sent, then nothings happens any more. In order to deal more in detail with using the UART device, I decided to have a closer look to the testhal UART example for the STM32F4 Discovery Board.

I am using ChibiStudio along with the os that is bundled in the download. In detail, I deleted all the files of the ARMCM4-STM32F407-DISCOVERY-MEMS Project (not the folders of the project) and copied all the files of the testhal UART for the STM32F4xx there. I modified the Makefile so that it can be compiled. The compile process works fine, there are no errors.

When I run the demo on the board, nothings happens. I don't see any output in the terminal. I placed a breakpoint in main.c @ uartStartSend(&UARTD2, 13, "Starting...\r\n") (line 140). This breakpoint is never reached. However, when placing a breakpoint at the command before, palSetPadMode(GPIOA, 3, PAL_MODE_ALTERNATE(7)), the breakpoint is reached. When I then resume execution (still, the breakpoint @line 140 is never reached) and then suspend execution, I always end up in function SVCallVector in chcore_v7m.c

Is this only a problem I encounter or does it show up at somebody's palce else as well?

Best regards,

Ralf

Hi,

The UART driver functions are asynchronous, they start the operation and then a callback is called when the operation finishes, you must not attempt another operation until the previous one is over, see the driver state machine in the manual. Probably there is a driver state violation, if you want to be sure then activate all the debug options in chconf.h, probably some assertion will be trapped.

If you need to send data synchronously then you should use the Serial driver instead, it is a classic I/O driver with circular buffers, easier to use.

Giovanni

Dear Giovanni,

thanks for your fast reply. The point you mentioned is clear to me. What I am wondering is that the testhal example does not work. This is not what I expected.

Regards,

Ralf

I will re-test it ASAP.

Giovanni

hi Giovanni
I have some problems with receiving data using uart driver.
- what I do: http://pastebin.com/L6p0cPKB
- what I expect:
1) reach breakpoint in rxend callback after sending of 8 characters in UART2 using terminal program
2) see typed characters in rxbuf array
- what I observe:
1) after calling uartStartReceive() immediately reached breakpoint in rxend callback, that immediately reached breakpoint in rxchar callback
2) rxbuf array is unchanged
3) changing rxchar to NULL in config struct fixes problem.
I think that problem is somewhere with STM32_DMA_CR_TCIE flag. If you have some quick ideas than I will try to fix it myself and push changes in repo.

I plan extensive UART usage in my current project and have some unrelated to current problem questions:
1) Why there are no UART4 and UART5 support in driver? Some architectural problems with stm32 UART cell?
2) What you plan to realize in UARTv2 driver?

Hi Barthess,

There must be something in the RX side of that driver, there is also an open ticked reporting an anomaly but so far I haven't yet found a cause. I have no idea yet of the what the problem could be but I will give it a serious try during next weekend, first step: a better test application.

Giovanni

If its the same UART as the 32F051, perhaps try the interrupt-driven code: viewtopic.php?f=14&t=1002
It needs testing the way you're using it, anyway, and might help identify whether any problem is DMA-related or elsewhere.

Hi,

I found the anomaly but not the real cause yet, it looks like a spurious interrupt. When this code is executed:



The driver immediately goes into uart_lld_serve_rx_end_irq() but the parameter "flags" is zero, so there is an interrupt without a cause. The act of disabling the stream triggers this. I could put a check on "flags" in uart_lld_serve_rx_end_irq() and just fix it but I am concerned about the cause, this is not supposed to happen.

I committed a modified ./testhal/STM32F4xx/UART application, the anomalous behavior is triggered by pressing the board button. You can see the driver calling the callback "rxend()" even if there is nothing to receive.

Does anybody have an idea about this?

Giovanni

Update,

I found a solution by implementing a different channel disable method in stm32_dma.h, bug 3607518.

I implemented the same method on all the STM32 devices even if it is possible this is a F4-specific quirk.

Barthess, could you confirm that this fix makes your problem disappear?

Giovanni

Problem dissapeared on my custom board. Tomorrow I will test it on F4discovery board on my work.