ODP: [Zephyr-users] console_getline vs 0ms char delay in UART comms
Piotr Barszczewski <piotr@...>
toggle quoted messageShow quoted text
Good point, forgot to mention that. Flow control pins are specified in DTS as well as FT232R has FC lines connected to nRF52832. Changing FC settings in Cutecom doesn’t change anything and data is corrupted as before.
The board itself has no issues with doing DFU with https://github.com/NordicSemiconductor/pc-nrfutil on other firmware written in various versions of nRF5 SDK and by default HWFC is required there.
On 18 March 2021 at 15:08:13, Chruściński, Krzysztof (krzysztof.chruscinski@...) wrote:
do you have flow control enabled? When it is disabled then after each byte receiver is stopped and restarted after reading the byte. Restarting may happen when transmitter is already started, in the middle of the byte. In that case, byte will be corrupted.
Od: users@... <users@...> w imieniu użytkownika Piotr Barszczewski via lists.zephyrproject.org <piotr=1am.pl@...>
Wysłane: czwartek, 18 marca 2021 14:35
Do: Lawrence King <lawrence.king@...>; users@... <users@...>
Temat: Re: [Zephyr-users] console_getline vs 0ms char delay in UART comms
I actually was about to check the signals out of curiosity and sending them in the attachment. All of the following were done with 8N1 @ 115200 and flashed with https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html having different DTS for the custom board of course. Every time I’ve sent "1234\r\n” to the nrf52832-QFAA chip and connected with the probes directly to UART lines.
I’ve checked the PCBs on Linux and OSX to get rid of suspicion that the OS drivers might somehow be involved in makig things funny.
I’ve also tried changing to 8N2 but the result was the same.
From the nrf52832-pcb-UART-0ms it looks like the RX corruption happens when nrf52832 starts transmitting but then it handles every n-th byte correctly. What is even stranger is that the analyzer gets a different value than what was sent and what nRF52832 received. I don’t really understand what could be the difference as both are nrf52832 (same frequency clocks) in the end, the only thing that is different is the way USB-UART converter is made and handled on OS level. Though I can’t really say that FT232R has failed like that before. It’s just this particular firmware and the way it handles the data.
I will try to find some USB-UART converter which will enumerate as ttyACM device on my Linux, unsolder the FTDI chip and try talking through ttyACM it instead of a /dev/ttyUSB one. Maybe there is something to it.
On 17 March 2021 at 23:49:09, Lawrence King (lawrence.king@...) wrote: