On 18 March 2021 at 17:36:29, Chruściński, Krzysztof (krzysztof.chruscinski@...) wrote:

Just to be sure. Specifying pins is not enough. hw-flow-control property must be set like here: https://github.com/zephyrproject-rtos/zephyr/blob/0f93d58994cd17753cfdf02fd022c2f226ec0471/samples/bluetooth/hci_uart/boards/nrf52840dk_nrf52840.overlay#L7

regards,

Krzysztof

---

Od: Piotr Barszczewski <piotr@...>
Wysłane: czwartek, 18 marca 2021 17:20
Do: Lawrence King <lawrence.king@...>; users@... <users@...>; Chruściński, Krzysztof <Krzysztof.Chruscinski@...>
Temat: Re: ODP: [Zephyr-users] console_getline vs 0ms char delay in UART comms

 

Hello Krzysztof,

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.

Best regards,

Piotr

On 18 March 2021 at 15:08:13, Chruściński, Krzysztof (krzysztof.chruscinski@...) wrote:

Hi,

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.

regards,

Krzysztof

---

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.

1. nrf52832-DK-0ms-delay.png - nRF52832 DK with 0ms delay set. All ok
2. nrf52832-DK-1ms-delay.png - nRF52832 DK with 1ms delay set. All ok
3. nrf52832-pcb-UART-0ms-char-delay.png - the tested custom PCB with 0ms delay. Data gets corrupted actually on TX and RX but what is returned is different thatn what is sent
4. nrf52832-pcb-UART-1ms-char-delay.png - As above but 1ms delay. All ok
5. nrf52832-pcb-UART-OSX-0ms-char-delay.png - Same as 3 but on OSX using Coolterm
6. nrf52832-pcb-UART-OSX-1ms-char-delay.png - Same as 4 but on OSX using Coolterm

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.

Best regards,

On 17 March 2021 at 23:49:09, Lawrence King (lawrence.king@...) wrote:

I wasn’t suspecting your FT232R HW, just how the various terminal programs set up the HW may be different. When all other debugging fails, nothing beats the certainty of capturing the waveforms with an oscilloscope and validating that all of the characters were sent, and the signal levels are good. But you are not likely to this level of debugging yet.

 

When you are using cutecom, try setting to 8N2. This adds one extra bit time between characters which a lot less than 1mS and may be enough that you stop dropping characters.

 

What baudrate are you running at? The usual 115200? Do you see the same problem if you try slower speeds like 38400 or 19200? Of course you need to change both ends of the link if you select an alternat baud rate.

 

Finally, what processor and processor clock rate are you running, you may simply be sending characters faster than your processor can respond to interrupts and receive the characters (which would make sense if you are missing every second character).

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Piotr Barszczewski <piotr@...>
Sent: Wednesday, March 17, 2021 3:43 PM
To: Lawrence King <lawrence.king@...>; users@...
Subject: RE: [Zephyr-users] console_getline vs 0ms char delay in UART comms

 

Hello Lawrence,

 

Thank you for your reply. I’m working with 8N1 and the USB-UART is FT232R of which I’m pretty certain that it’s working correctly. It works with other firmware, developed with older Nordics SDK and haven’t experienced issues with it yet. In my experience I’ve narrowed it down to the 0ms delay in Cutecom making the getline console example to loose some characters on hadrware which works ok with different firmware with the same Cutecom settings.

 

As for hardware design it uses a schematic which has been validated by FTDI support as on a different device we’ve been experiencing different issues so I find it unlikely that it would be at blame here.

 

When I have a moment I’ll try to replicate it with nrf52832 DK but I expect that it could be better as the DK enumerates as ttyACM port device which I’ve previously found to behave differently than ttyUSB which I wrote down in https://devzone.nordicsemi.com/f/nordic-q-a/62732/zephyr-hci_uart-on-nrf52840-with-ft232r and unfortunately it’s still unsolved by me. Maybe FT232R and Zephyr sometimes don’t really get along for some reason?

 

Best regards,

Piotr

 

On 17 March 2021 at 14:30:35, Lawrence King (lawrence.king@...) wrote:

Hi Piotr

 

There are may be pieces of equipment along  the path between cutecom and the serial input on your micro-controller. Usually there is a USB to Serial chip. The programs inside screen and cutecom set parameters in the USB2Serial chip. Specifically I would be worried about the number of databits and stop bits, also parity. The ‘normal’ setting is 8N1 which means send a start bit, 8 data bits, no parity bits, and a single stop bit. However if cutecom selected 7N1, or screen selected 8N1 and the serial port on your Zephyr board was set to 8N2 you would see these types of problems.

 

Curiously you are consistently loosing the characters with Even parity. Is your Zephyr board set up to expect 7O1?

 

You need to look at the data being send from the USB2Serial adapter and ensure that it is valid. I have never had a problem with Zephyr dropping characters, but it really depends on your board, and kernel options.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From:users@... <users@...> On Behalf Of Piotr Barszczewski
Sent: Monday, March 15, 2021 12:31 PM
To: users@...
Subject: [Zephyr-users] console_getline vs 0ms char delay in UART comms

 

Hello,

 

I’ve been reviewing code from a colleague, which (code, not the colleague) is heavily based on the https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html I’ve been experiencing some unexpected behaviour when using CuteCom vs screen to communicate with the console. I’ve dug deeper and deeper and eventually it seemed like the value returned by console_getline function was indeed already corrupted. In screen everything worked fine.

 

My assumption was that when I’m using screen each character is passed 1-by-1 to a buffer and everything is golden. On the other hand CuteCom buffers the input until I press enter and fires away at the serial port - pretty much like M2M communications would work over UART.

Eventually I opened up the https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html project and the behaviour was the same. It corrupted the buffer when used in Cutecom and worked ok with screen. 

 

This is an example of the output of FW when sending “1234” over Cutecom with 0ms delay (which is what I have been using +/- forever):

[17:07:53:997] 13␍␊
[17:07:54:012] line: 13␍␊
[17:07:54:012] last char was: 0x33␍␊
[17:07:54:842] 13␍␊
[17:07:54:859] line: 13␍␊
[17:07:54:859] last char was: 0x33␍␊
[17:07:55:794] 13␍␊
[17:07:55:810] line: 13␍␊
[17:07:55:810] last char was: 0x33␍␊
[17:07:57:074] 1S@

In the end I’ve changed CuteComs char delay to 1ms and everything works well:

[17:07:50:368] 1234␍␊
[17:07:50:368] line: 1234␍␊
[17:07:50:384] last char was: 0x34␍␊

 

Is there some simple CONFIG_ argument to change this? I’ve looked in menuconfig but without luck. 

It’s not much of a problem to instruct every user of the FW to change it to 1ms but I’m a bit concerned about using various scripts to communicate with the firmware which will use the console. Depending on the implementation of serial driver it might require additional work to accound for the buffer not handling bursts of data.

 

Best regards

 

 

 

 

 

Hi,

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.

regards,

Krzysztof

---

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.

1. nrf52832-DK-0ms-delay.png - nRF52832 DK with 0ms delay set. All ok
2. nrf52832-DK-1ms-delay.png - nRF52832 DK with 1ms delay set. All ok
3. nrf52832-pcb-UART-0ms-char-delay.png - the tested custom PCB with 0ms delay. Data gets corrupted actually on TX and RX but what is returned is different thatn what is sent
4. nrf52832-pcb-UART-1ms-char-delay.png - As above but 1ms delay. All ok
5. nrf52832-pcb-UART-OSX-0ms-char-delay.png - Same as 3 but on OSX using Coolterm
6. nrf52832-pcb-UART-OSX-1ms-char-delay.png - Same as 4 but on OSX using Coolterm

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.

Best regards,

On 17 March 2021 at 23:49:09, Lawrence King (lawrence.king@...) wrote:

I wasn’t suspecting your FT232R HW, just how the various terminal programs set up the HW may be different. When all other debugging fails, nothing beats the certainty of capturing the waveforms with an oscilloscope and validating that all of the characters were sent, and the signal levels are good. But you are not likely to this level of debugging yet.

 

When you are using cutecom, try setting to 8N2. This adds one extra bit time between characters which a lot less than 1mS and may be enough that you stop dropping characters.

 

What baudrate are you running at? The usual 115200? Do you see the same problem if you try slower speeds like 38400 or 19200? Of course you need to change both ends of the link if you select an alternat baud rate.

 

Finally, what processor and processor clock rate are you running, you may simply be sending characters faster than your processor can respond to interrupts and receive the characters (which would make sense if you are missing every second character).

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Piotr Barszczewski <piotr@...>
Sent: Wednesday, March 17, 2021 3:43 PM
To: Lawrence King <lawrence.king@...>; users@...
Subject: RE: [Zephyr-users] console_getline vs 0ms char delay in UART comms

 

Hello Lawrence,

 

Thank you for your reply. I’m working with 8N1 and the USB-UART is FT232R of which I’m pretty certain that it’s working correctly. It works with other firmware, developed with older Nordics SDK and haven’t experienced issues with it yet. In my experience I’ve narrowed it down to the 0ms delay in Cutecom making the getline console example to loose some characters on hadrware which works ok with different firmware with the same Cutecom settings.

 

As for hardware design it uses a schematic which has been validated by FTDI support as on a different device we’ve been experiencing different issues so I find it unlikely that it would be at blame here.

 

When I have a moment I’ll try to replicate it with nrf52832 DK but I expect that it could be better as the DK enumerates as ttyACM port device which I’ve previously found to behave differently than ttyUSB which I wrote down in https://devzone.nordicsemi.com/f/nordic-q-a/62732/zephyr-hci_uart-on-nrf52840-with-ft232r and unfortunately it’s still unsolved by me. Maybe FT232R and Zephyr sometimes don’t really get along for some reason?

 

Best regards,

Piotr

 

On 17 March 2021 at 14:30:35, Lawrence King (lawrence.king@...) wrote:

Hi Piotr

 

There are may be pieces of equipment along  the path between cutecom and the serial input on your micro-controller. Usually there is a USB to Serial chip. The programs inside screen and cutecom set parameters in the USB2Serial chip. Specifically I would be worried about the number of databits and stop bits, also parity. The ‘normal’ setting is 8N1 which means send a start bit, 8 data bits, no parity bits, and a single stop bit. However if cutecom selected 7N1, or screen selected 8N1 and the serial port on your Zephyr board was set to 8N2 you would see these types of problems.

 

Curiously you are consistently loosing the characters with Even parity. Is your Zephyr board set up to expect 7O1?

 

You need to look at the data being send from the USB2Serial adapter and ensure that it is valid. I have never had a problem with Zephyr dropping characters, but it really depends on your board, and kernel options.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From:users@... <users@...> On Behalf Of Piotr Barszczewski
Sent: Monday, March 15, 2021 12:31 PM
To: users@...
Subject: [Zephyr-users] console_getline vs 0ms char delay in UART comms

 

Hello,

 

I’ve been reviewing code from a colleague, which (code, not the colleague) is heavily based on the https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html I’ve been experiencing some unexpected behaviour when using CuteCom vs screen to communicate with the console. I’ve dug deeper and deeper and eventually it seemed like the value returned by console_getline function was indeed already corrupted. In screen everything worked fine.

 

My assumption was that when I’m using screen each character is passed 1-by-1 to a buffer and everything is golden. On the other hand CuteCom buffers the input until I press enter and fires away at the serial port - pretty much like M2M communications would work over UART.

Eventually I opened up the https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html project and the behaviour was the same. It corrupted the buffer when used in Cutecom and worked ok with screen. 

 

This is an example of the output of FW when sending “1234” over Cutecom with 0ms delay (which is what I have been using +/- forever):

[17:07:53:997] 13␍␊
[17:07:54:012] line: 13␍␊
[17:07:54:012] last char was: 0x33␍␊
[17:07:54:842] 13␍␊
[17:07:54:859] line: 13␍␊
[17:07:54:859] last char was: 0x33␍␊
[17:07:55:794] 13␍␊
[17:07:55:810] line: 13␍␊
[17:07:55:810] last char was: 0x33␍␊
[17:07:57:074] 1S@

In the end I’ve changed CuteComs char delay to 1ms and everything works well:

[17:07:50:368] 1234␍␊
[17:07:50:368] line: 1234␍␊
[17:07:50:384] last char was: 0x34␍␊

 

Is there some simple CONFIG_ argument to change this? I’ve looked in menuconfig but without luck. 

It’s not much of a problem to instruct every user of the FW to change it to 1ms but I’m a bit concerned about using various scripts to communicate with the firmware which will use the console. Depending on the implementation of serial driver it might require additional work to accound for the buffer not handling bursts of data.

 

Best regards

 

 

 

 

 

On 18 March 2021 at 15:08:13, Chruściński, Krzysztof (krzysztof.chruscinski@...) wrote:

Hi,

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.

regards,

Krzysztof

---

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.

1. nrf52832-DK-0ms-delay.png - nRF52832 DK with 0ms delay set. All ok
2. nrf52832-DK-1ms-delay.png - nRF52832 DK with 1ms delay set. All ok
3. nrf52832-pcb-UART-0ms-char-delay.png - the tested custom PCB with 0ms delay. Data gets corrupted actually on TX and RX but what is returned is different thatn what is sent
4. nrf52832-pcb-UART-1ms-char-delay.png - As above but 1ms delay. All ok
5. nrf52832-pcb-UART-OSX-0ms-char-delay.png - Same as 3 but on OSX using Coolterm
6. nrf52832-pcb-UART-OSX-1ms-char-delay.png - Same as 4 but on OSX using Coolterm

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.

Best regards,

On 17 March 2021 at 23:49:09, Lawrence King (lawrence.king@...) wrote:

I wasn’t suspecting your FT232R HW, just how the various terminal programs set up the HW may be different. When all other debugging fails, nothing beats the certainty of capturing the waveforms with an oscilloscope and validating that all of the characters were sent, and the signal levels are good. But you are not likely to this level of debugging yet.

 

When you are using cutecom, try setting to 8N2. This adds one extra bit time between characters which a lot less than 1mS and may be enough that you stop dropping characters.

 

What baudrate are you running at? The usual 115200? Do you see the same problem if you try slower speeds like 38400 or 19200? Of course you need to change both ends of the link if you select an alternat baud rate.

 

Finally, what processor and processor clock rate are you running, you may simply be sending characters faster than your processor can respond to interrupts and receive the characters (which would make sense if you are missing every second character).

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Piotr Barszczewski <piotr@...>
Sent: Wednesday, March 17, 2021 3:43 PM
To: Lawrence King <lawrence.king@...>; users@...
Subject: RE: [Zephyr-users] console_getline vs 0ms char delay in UART comms

 

Hello Lawrence,

 

Thank you for your reply. I’m working with 8N1 and the USB-UART is FT232R of which I’m pretty certain that it’s working correctly. It works with other firmware, developed with older Nordics SDK and haven’t experienced issues with it yet. In my experience I’ve narrowed it down to the 0ms delay in Cutecom making the getline console example to loose some characters on hadrware which works ok with different firmware with the same Cutecom settings.

 

As for hardware design it uses a schematic which has been validated by FTDI support as on a different device we’ve been experiencing different issues so I find it unlikely that it would be at blame here.

 

When I have a moment I’ll try to replicate it with nrf52832 DK but I expect that it could be better as the DK enumerates as ttyACM port device which I’ve previously found to behave differently than ttyUSB which I wrote down in https://devzone.nordicsemi.com/f/nordic-q-a/62732/zephyr-hci_uart-on-nrf52840-with-ft232r and unfortunately it’s still unsolved by me. Maybe FT232R and Zephyr sometimes don’t really get along for some reason?

 

Best regards,

Piotr

 

On 17 March 2021 at 14:30:35, Lawrence King (lawrence.king@...) wrote:

Hi Piotr

 

There are may be pieces of equipment along  the path between cutecom and the serial input on your micro-controller. Usually there is a USB to Serial chip. The programs inside screen and cutecom set parameters in the USB2Serial chip. Specifically I would be worried about the number of databits and stop bits, also parity. The ‘normal’ setting is 8N1 which means send a start bit, 8 data bits, no parity bits, and a single stop bit. However if cutecom selected 7N1, or screen selected 8N1 and the serial port on your Zephyr board was set to 8N2 you would see these types of problems.

 

Curiously you are consistently loosing the characters with Even parity. Is your Zephyr board set up to expect 7O1?

 

You need to look at the data being send from the USB2Serial adapter and ensure that it is valid. I have never had a problem with Zephyr dropping characters, but it really depends on your board, and kernel options.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From:users@... <users@...> On Behalf Of Piotr Barszczewski
Sent: Monday, March 15, 2021 12:31 PM
To: users@...
Subject: [Zephyr-users] console_getline vs 0ms char delay in UART comms

 

Hello,

 

I’ve been reviewing code from a colleague, which (code, not the colleague) is heavily based on the https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html I’ve been experiencing some unexpected behaviour when using CuteCom vs screen to communicate with the console. I’ve dug deeper and deeper and eventually it seemed like the value returned by console_getline function was indeed already corrupted. In screen everything worked fine.

 

My assumption was that when I’m using screen each character is passed 1-by-1 to a buffer and everything is golden. On the other hand CuteCom buffers the input until I press enter and fires away at the serial port - pretty much like M2M communications would work over UART.

Eventually I opened up the https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html project and the behaviour was the same. It corrupted the buffer when used in Cutecom and worked ok with screen. 

 

This is an example of the output of FW when sending “1234” over Cutecom with 0ms delay (which is what I have been using +/- forever):

[17:07:53:997] 13␍␊
[17:07:54:012] line: 13␍␊
[17:07:54:012] last char was: 0x33␍␊
[17:07:54:842] 13␍␊
[17:07:54:859] line: 13␍␊
[17:07:54:859] last char was: 0x33␍␊
[17:07:55:794] 13␍␊
[17:07:55:810] line: 13␍␊
[17:07:55:810] last char was: 0x33␍␊
[17:07:57:074] 1S@

In the end I’ve changed CuteComs char delay to 1ms and everything works well:

[17:07:50:368] 1234␍␊
[17:07:50:368] line: 1234␍␊
[17:07:50:384] last char was: 0x34␍␊

 

Is there some simple CONFIG_ argument to change this? I’ve looked in menuconfig but without luck. 

It’s not much of a problem to instruct every user of the FW to change it to 1ms but I’m a bit concerned about using various scripts to communicate with the firmware which will use the console. Depending on the implementation of serial driver it might require additional work to accound for the buffer not handling bursts of data.

 

Best regards

 

 

 

 

 

I wasn’t suspecting your FT232R HW, just how the various terminal programs set up the HW may be different. When all other debugging fails, nothing beats the certainty of capturing the waveforms with an oscilloscope and validating that all of the characters were sent, and the signal levels are good. But you are not likely to this level of debugging yet.

 

When you are using cutecom, try setting to 8N2. This adds one extra bit time between characters which a lot less than 1mS and may be enough that you stop dropping characters.

 

What baudrate are you running at? The usual 115200? Do you see the same problem if you try slower speeds like 38400 or 19200? Of course you need to change both ends of the link if you select an alternat baud rate.

 

Finally, what processor and processor clock rate are you running, you may simply be sending characters faster than your processor can respond to interrupts and receive the characters (which would make sense if you are missing every second character).

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Piotr Barszczewski <piotr@...>
Sent: Wednesday, March 17, 2021 3:43 PM
To: Lawrence King <lawrence.king@...>; users@...
Subject: RE: [Zephyr-users] console_getline vs 0ms char delay in UART comms

 

Hello Lawrence,

 

Thank you for your reply. I’m working with 8N1 and the USB-UART is FT232R of which I’m pretty certain that it’s working correctly. It works with other firmware, developed with older Nordics SDK and haven’t experienced issues with it yet. In my experience I’ve narrowed it down to the 0ms delay in Cutecom making the getline console example to loose some characters on hadrware which works ok with different firmware with the same Cutecom settings.

 

As for hardware design it uses a schematic which has been validated by FTDI support as on a different device we’ve been experiencing different issues so I find it unlikely that it would be at blame here.

 

When I have a moment I’ll try to replicate it with nrf52832 DK but I expect that it could be better as the DK enumerates as ttyACM port device which I’ve previously found to behave differently than ttyUSB which I wrote down in https://devzone.nordicsemi.com/f/nordic-q-a/62732/zephyr-hci_uart-on-nrf52840-with-ft232r and unfortunately it’s still unsolved by me. Maybe FT232R and Zephyr sometimes don’t really get along for some reason?

 

Best regards,

Piotr

 

On 17 March 2021 at 14:30:35, Lawrence King (lawrence.king@...) wrote:

Hi Piotr

 

There are may be pieces of equipment along  the path between cutecom and the serial input on your micro-controller. Usually there is a USB to Serial chip. The programs inside screen and cutecom set parameters in the USB2Serial chip. Specifically I would be worried about the number of databits and stop bits, also parity. The ‘normal’ setting is 8N1 which means send a start bit, 8 data bits, no parity bits, and a single stop bit. However if cutecom selected 7N1, or screen selected 8N1 and the serial port on your Zephyr board was set to 8N2 you would see these types of problems.

 

Curiously you are consistently loosing the characters with Even parity. Is your Zephyr board set up to expect 7O1?

 

You need to look at the data being send from the USB2Serial adapter and ensure that it is valid. I have never had a problem with Zephyr dropping characters, but it really depends on your board, and kernel options.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Piotr Barszczewski
Sent: Monday, March 15, 2021 12:31 PM
To: users@...
Subject: [Zephyr-users] console_getline vs 0ms char delay in UART comms

 

Hello,

 

I’ve been reviewing code from a colleague, which (code, not the colleague) is heavily based on the https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html I’ve been experiencing some unexpected behaviour when using CuteCom vs screen to communicate with the console. I’ve dug deeper and deeper and eventually it seemed like the value returned by console_getline function was indeed already corrupted. In screen everything worked fine.

 

My assumption was that when I’m using screen each character is passed 1-by-1 to a buffer and everything is golden. On the other hand CuteCom buffers the input until I press enter and fires away at the serial port - pretty much like M2M communications would work over UART.

Eventually I opened up the https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html project and the behaviour was the same. It corrupted the buffer when used in Cutecom and worked ok with screen. 

 

This is an example of the output of FW when sending “1234” over Cutecom with 0ms delay (which is what I have been using +/- forever):

[17:07:53:997] 13␍␊
[17:07:54:012] line: 13␍␊
[17:07:54:012] last char was: 0x33␍␊
[17:07:54:842] 13␍␊
[17:07:54:859] line: 13␍␊
[17:07:54:859] last char was: 0x33␍␊
[17:07:55:794] 13␍␊
[17:07:55:810] line: 13␍␊
[17:07:55:810] last char was: 0x33␍␊
[17:07:57:074] 1S@

In the end I’ve changed CuteComs char delay to 1ms and everything works well:

[17:07:50:368] 1234␍␊
[17:07:50:368] line: 1234␍␊
[17:07:50:384] last char was: 0x34␍␊

 

Is there some simple CONFIG_ argument to change this? I’ve looked in menuconfig but without luck. 

It’s not much of a problem to instruct every user of the FW to change it to 1ms but I’m a bit concerned about using various scripts to communicate with the firmware which will use the console. Depending on the implementation of serial driver it might require additional work to accound for the buffer not handling bursts of data.

 

Best regards

 

 

 

 

 

On 17 March 2021 at 23:49:09, Lawrence King (lawrence.king@...) wrote:

I wasn’t suspecting your FT232R HW, just how the various terminal programs set up the HW may be different. When all other debugging fails, nothing beats the certainty of capturing the waveforms with an oscilloscope and validating that all of the characters were sent, and the signal levels are good. But you are not likely to this level of debugging yet.

 

When you are using cutecom, try setting to 8N2. This adds one extra bit time between characters which a lot less than 1mS and may be enough that you stop dropping characters.

 

What baudrate are you running at? The usual 115200? Do you see the same problem if you try slower speeds like 38400 or 19200? Of course you need to change both ends of the link if you select an alternat baud rate.

 

Finally, what processor and processor clock rate are you running, you may simply be sending characters faster than your processor can respond to interrupts and receive the characters (which would make sense if you are missing every second character).

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Piotr Barszczewski <piotr@...>
Sent: Wednesday, March 17, 2021 3:43 PM
To: Lawrence King <lawrence.king@...>; users@...
Subject: RE: [Zephyr-users] console_getline vs 0ms char delay in UART comms

 

Hello Lawrence,

 

Thank you for your reply. I’m working with 8N1 and the USB-UART is FT232R of which I’m pretty certain that it’s working correctly. It works with other firmware, developed with older Nordics SDK and haven’t experienced issues with it yet. In my experience I’ve narrowed it down to the 0ms delay in Cutecom making the getline console example to loose some characters on hadrware which works ok with different firmware with the same Cutecom settings.

 

As for hardware design it uses a schematic which has been validated by FTDI support as on a different device we’ve been experiencing different issues so I find it unlikely that it would be at blame here.

 

When I have a moment I’ll try to replicate it with nrf52832 DK but I expect that it could be better as the DK enumerates as ttyACM port device which I’ve previously found to behave differently than ttyUSB which I wrote down in https://devzone.nordicsemi.com/f/nordic-q-a/62732/zephyr-hci_uart-on-nrf52840-with-ft232r and unfortunately it’s still unsolved by me. Maybe FT232R and Zephyr sometimes don’t really get along for some reason?

 

Best regards,

Piotr

 

On 17 March 2021 at 14:30:35, Lawrence King (lawrence.king@...) wrote:

Hi Piotr

 

There are may be pieces of equipment along  the path between cutecom and the serial input on your micro-controller. Usually there is a USB to Serial chip. The programs inside screen and cutecom set parameters in the USB2Serial chip. Specifically I would be worried about the number of databits and stop bits, also parity. The ‘normal’ setting is 8N1 which means send a start bit, 8 data bits, no parity bits, and a single stop bit. However if cutecom selected 7N1, or screen selected 8N1 and the serial port on your Zephyr board was set to 8N2 you would see these types of problems.

 

Curiously you are consistently loosing the characters with Even parity. Is your Zephyr board set up to expect 7O1?

 

You need to look at the data being send from the USB2Serial adapter and ensure that it is valid. I have never had a problem with Zephyr dropping characters, but it really depends on your board, and kernel options.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Piotr Barszczewski
Sent: Monday, March 15, 2021 12:31 PM
To: users@...
Subject: [Zephyr-users] console_getline vs 0ms char delay in UART comms

 

Hello,

 

I’ve been reviewing code from a colleague, which (code, not the colleague) is heavily based on the https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html I’ve been experiencing some unexpected behaviour when using CuteCom vs screen to communicate with the console. I’ve dug deeper and deeper and eventually it seemed like the value returned by console_getline function was indeed already corrupted. In screen everything worked fine.

 

My assumption was that when I’m using screen each character is passed 1-by-1 to a buffer and everything is golden. On the other hand CuteCom buffers the input until I press enter and fires away at the serial port - pretty much like M2M communications would work over UART.

Eventually I opened up the https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html project and the behaviour was the same. It corrupted the buffer when used in Cutecom and worked ok with screen. 

 

This is an example of the output of FW when sending “1234” over Cutecom with 0ms delay (which is what I have been using +/- forever):

[17:07:53:997] 13␍␊
[17:07:54:012] line: 13␍␊
[17:07:54:012] last char was: 0x33␍␊
[17:07:54:842] 13␍␊
[17:07:54:859] line: 13␍␊
[17:07:54:859] last char was: 0x33␍␊
[17:07:55:794] 13␍␊
[17:07:55:810] line: 13␍␊
[17:07:55:810] last char was: 0x33␍␊
[17:07:57:074] 1S@

In the end I’ve changed CuteComs char delay to 1ms and everything works well:

[17:07:50:368] 1234␍␊
[17:07:50:368] line: 1234␍␊
[17:07:50:384] last char was: 0x34␍␊

 

Is there some simple CONFIG_ argument to change this? I’ve looked in menuconfig but without luck. 

It’s not much of a problem to instruct every user of the FW to change it to 1ms but I’m a bit concerned about using various scripts to communicate with the firmware which will use the console. Depending on the implementation of serial driver it might require additional work to accound for the buffer not handling bursts of data.

 

Best regards

 

 

 

 

 

On 17 March 2021 at 14:30:35, Lawrence King (lawrence.king@...) wrote:

Hi Piotr

 

There are may be pieces of equipment along  the path between cutecom and the serial input on your micro-controller. Usually there is a USB to Serial chip. The programs inside screen and cutecom set parameters in the USB2Serial chip. Specifically I would be worried about the number of databits and stop bits, also parity. The ‘normal’ setting is 8N1 which means send a start bit, 8 data bits, no parity bits, and a single stop bit. However if cutecom selected 7N1, or screen selected 8N1 and the serial port on your Zephyr board was set to 8N2 you would see these types of problems.

 

Curiously you are consistently loosing the characters with Even parity. Is your Zephyr board set up to expect 7O1?

 

You need to look at the data being send from the USB2Serial adapter and ensure that it is valid. I have never had a problem with Zephyr dropping characters, but it really depends on your board, and kernel options.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Piotr Barszczewski
Sent: Monday, March 15, 2021 12:31 PM
To: users@...
Subject: [Zephyr-users] console_getline vs 0ms char delay in UART comms

 

Hello,

 

I’ve been reviewing code from a colleague, which (code, not the colleague) is heavily based on the https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html I’ve been experiencing some unexpected behaviour when using CuteCom vs screen to communicate with the console. I’ve dug deeper and deeper and eventually it seemed like the value returned by console_getline function was indeed already corrupted. In screen everything worked fine.

 

My assumption was that when I’m using screen each character is passed 1-by-1 to a buffer and everything is golden. On the other hand CuteCom buffers the input until I press enter and fires away at the serial port - pretty much like M2M communications would work over UART.

Eventually I opened up the https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html project and the behaviour was the same. It corrupted the buffer when used in Cutecom and worked ok with screen. 

 

This is an example of the output of FW when sending “1234” over Cutecom with 0ms delay (which is what I have been using +/- forever):

[17:07:53:997] 13␍␊
[17:07:54:012] line: 13␍␊
[17:07:54:012] last char was: 0x33␍␊
[17:07:54:842] 13␍␊
[17:07:54:859] line: 13␍␊
[17:07:54:859] last char was: 0x33␍␊
[17:07:55:794] 13␍␊
[17:07:55:810] line: 13␍␊
[17:07:55:810] last char was: 0x33␍␊
[17:07:57:074] 1S@

In the end I’ve changed CuteComs char delay to 1ms and everything works well:

[17:07:50:368] 1234␍␊
[17:07:50:368] line: 1234␍␊
[17:07:50:384] last char was: 0x34␍␊

 

Is there some simple CONFIG_ argument to change this? I’ve looked in menuconfig but without luck. 

It’s not much of a problem to instruct every user of the FW to change it to 1ms but I’m a bit concerned about using various scripts to communicate with the firmware which will use the console. Depending on the implementation of serial driver it might require additional work to accound for the buffer not handling bursts of data.

 

Best regards

 

 

 

 

 

On 17 March 2021 at 14:30:35, Lawrence King (lawrence.king@...) wrote:

Hi Piotr

 

There are may be pieces of equipment along  the path between cutecom and the serial input on your micro-controller. Usually there is a USB to Serial chip. The programs inside screen and cutecom set parameters in the USB2Serial chip. Specifically I would be worried about the number of databits and stop bits, also parity. The ‘normal’ setting is 8N1 which means send a start bit, 8 data bits, no parity bits, and a single stop bit. However if cutecom selected 7N1, or screen selected 8N1 and the serial port on your Zephyr board was set to 8N2 you would see these types of problems.

 

Curiously you are consistently loosing the characters with Even parity. Is your Zephyr board set up to expect 7O1?

 

You need to look at the data being send from the USB2Serial adapter and ensure that it is valid. I have never had a problem with Zephyr dropping characters, but it really depends on your board, and kernel options.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Piotr Barszczewski
Sent: Monday, March 15, 2021 12:31 PM
To: users@...
Subject: [Zephyr-users] console_getline vs 0ms char delay in UART comms

 

Hello,

 

I’ve been reviewing code from a colleague, which (code, not the colleague) is heavily based on the https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html I’ve been experiencing some unexpected behaviour when using CuteCom vs screen to communicate with the console. I’ve dug deeper and deeper and eventually it seemed like the value returned by console_getline function was indeed already corrupted. In screen everything worked fine.

 

My assumption was that when I’m using screen each character is passed 1-by-1 to a buffer and everything is golden. On the other hand CuteCom buffers the input until I press enter and fires away at the serial port - pretty much like M2M communications would work over UART.

Eventually I opened up the https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html project and the behaviour was the same. It corrupted the buffer when used in Cutecom and worked ok with screen. 

 

This is an example of the output of FW when sending “1234” over Cutecom with 0ms delay (which is what I have been using +/- forever):

[17:07:53:997] 13␍␊
[17:07:54:012] line: 13␍␊
[17:07:54:012] last char was: 0x33␍␊
[17:07:54:842] 13␍␊
[17:07:54:859] line: 13␍␊
[17:07:54:859] last char was: 0x33␍␊
[17:07:55:794] 13␍␊
[17:07:55:810] line: 13␍␊
[17:07:55:810] last char was: 0x33␍␊
[17:07:57:074] 1S@

In the end I’ve changed CuteComs char delay to 1ms and everything works well:

[17:07:50:368] 1234␍␊
[17:07:50:368] line: 1234␍␊
[17:07:50:384] last char was: 0x34␍␊

 

Is there some simple CONFIG_ argument to change this? I’ve looked in menuconfig but without luck. 

It’s not much of a problem to instruct every user of the FW to change it to 1ms but I’m a bit concerned about using various scripts to communicate with the firmware which will use the console. Depending on the implementation of serial driver it might require additional work to accound for the buffer not handling bursts of data.

 

Best regards

 

 

 

 

 

Just to be clear on this, is it true that re-entrancy is not supported by Zephyr for any of the newlib stdio.h or stdlib.h functions, so not just the likes of strok() but also snprintf() and, more fundamentally, malloc()/free()?

If this is the case, are there any other C libraries (so not newlib) for which Zephyr does support re-entrancy and which fulfil the same functions?

Rob

-- 

Dave Nadler, USA East Coast voice (978) 263-0097, drn@..., Skype 

 Dave.Nadler1

On Mar 11, 2021, at 11:45 AM, Jack Rosenthal <jrosenth@...> wrote:

The typical way I've seen this done is:

Phase 1: Create the main branch at the same commit hash as master. Repo maintainers make sure that the main branch is synced to master.
Phase 2: Set the default branch to "main". Continue syncing "main" and "master".
Phase 3: Stop syncing "main" and "master". Master goes stale.
Phase 4: Delete the (now stale) master branch.

I'm not sure if GitHub has tools for branch syncing, but it can be done easy enough from the command line by someone with push access.

On Thu, Mar 11, 2021 at 10:38 AM Kumar Gala <kumar.gala@...> wrote:
Jack,

We are utilizing what GitHub provides and as far as I can tell once we make the change to the default branch from ‘master’ to ‘main’ the ‘master’ branch will no longer exist in the repository.

So downstream users will need to adjust after the change is made.

If you have some means to handle such a synchronization its something that we can discuss.

- k

On Mar 11, 2021, at 10:12 AM, Jack Rosenthal <jrosenth@...> wrote:

Hi,

Will there be a period of time that we have two main branches ("master" and "main") that are auto-synced to give time for people to adjust their tools?

Thanks,

Jack

On Thu, Mar 11, 2021 at 6:32 AM Kumar Gala <kumar.gala@...> wrote:
We will be changing the default branch on github from ‘master' to ‘main' on Friday (Mar 11, 2021).

There is no action required for any open PRs, however you’ll need to update your local git clone as follows:

git branch -m master main
git fetch origin
git branch -u origin/main main

Will announce here when this change is made on Friday.

thanks

- k

On Mar 11, 2021, at 12:04 PM, Rob Meades <Rob.Meades@...> wrote:

Thanks for the swift response. That's a shame. I will go look at the PR at your link as shifting to the re-entrant versions just for Zephyr is going to be painful.

Rob
-----Original Message-----
From: users@... <users@...> On Behalf Of Kumar Gala
Sent: 11 March 2021 17:54
To: Rob Meades <Rob.Meades@...>
Cc: users@...
Subject: Re: [Zephyr-users] C library re-entrancy under Zephyr

*** This is an EXTERNAL email. It was sent from outside of u-blox. ***

Re-entrant support between newlib and zephyr is not currently supported.

There’s an old PR on the subject

https://github.com/zephyrproject-rtos/zephyr/pull/21518

- k

On Mar 11, 2021, at 11:51 AM, Rob Meades via lists.zephyrproject.org <Rob.Meades=u-blox.com@...> wrote:

Should I expect C library functions (e.g. strtok()) under Zephyr to be re-entrant or must I call the re-entrant versions (i.e. in this case strtok_r())?

I ask because I am building/running nRF52840 (cortex-m4) and strok() _appears_ to NOT be re-entrant: I'd like to understand if this is expected or if I've messed up a configuration somewhere. My prj.conf file is attached in case it is helpful in answering the question.

Rob





<prj.conf>