Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standard output is truncated and sent to the shell input on Arduino Nano 33 BLE for the default example #20544

Open
bmewen opened this issue Apr 5, 2024 · 3 comments

Comments

@bmewen
Copy link
Contributor

bmewen commented Apr 5, 2024

Description

The default example is supposed to print two lines then let the user type the commands, but on the Nano 33 BLE the two lines are not printed correctly and some characters are mixed in the shell input which imply that the user has to erase them.

Steps to reproduce the issue

With a Nano 33 BLE linked to the computer :

BOARD=arduino-nano-33-ble RIOT_TERMINAL=picocom make -C default flash term 

Note that I'm using picocom instead of pyserial which doesn't change anything to the result.

Expected results

The output is clean with the lines printed in the right order and the input is empty and let the user type his command without erasing anything.

The output is supposed to be the following one :

main(): This is RIOT! (Version : 2024-)
Welcome to RIOT!
>

Actual results

The actual output is :

Welcome to RIOT!
> mai):Th is

The first line is not printed and instead seems to be partially sent to the input of the shell.

Versions

All tests performed on a fresh master branch.

Operating System Environment

Operating System: "Ubuntu" "22.04.4 LTS (Jammy Jellyfish)"
Kernel: Linux 6.5.0-26-generic x86_64 x86_64
System shell: /usr/bin/dash (probably dash)
make's shell: /usr/bin/dash (probably dash)

Installed compiler toolchains

native gcc: gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
arm-none-eabi-gcc: arm-none-eabi-gcc (15:10.3-2021.07-4) 10.3.1 20210621 (release)
clang: Ubuntu clang version 14.0.0-1ubuntu1.1

Installed compiler libs

arm-none-eabi-newlib: "3.3.0"

Installed development tools

cmake: cmake version 3.22.1
doxygen: 1.9.1
git: git version 2.34.1
make: GNU Make 4.3
openocd: Open On-Chip Debugger 0.11.0
python: Python 3.12.2
python3: Python 3.12.2

@maribu
Copy link
Member

maribu commented May 3, 2024

Thanks for the report and sorry for the long wait.

I believe the issue you have faced is that two instances of picocom have been attached to the same TTY interface, with some chars going into one and some chars into the other.

Could you give this another spin? Ideally use the default terminal (pyterm), by not specifying RIOT_TERMINAL. That one opens the TTY interface exclusively, preventing two instances attached to the same TTY.

If you can still reproduce the issue could you try to capture the USB traffic e.g. using WireShark and confirm that the chars are already missing in the data send to the host?

@bmewen
Copy link
Contributor Author

bmewen commented May 3, 2024

I've tried picocom and pyterm, both are giving me same result. I never used Wireshark to debug USB communication but it seems that the packets sent on both side have the same problem as those I get when using the serial terminal. From what I understand, the characters that are printed before the shell is executed seems to be partially redirected to its input.

Using my previous example : main(): This is RIOT! (Version : 2024-) is printed before the shell started and when I try to type help or any command, the first time this command will be mixed with main(): This is RIOT! (Version : 2024-)

@bmewen
Copy link
Contributor Author

bmewen commented May 14, 2024

Here's a zip containing the Wireshark capture of the problem in the file named nano-33-ble-term-trace.pcapng. You can especially pay attention to the lines around 697 and 713 which corresponds to when the commands were typed.

I also included a typescript of terminal session so you can see exactly what happened, you can replay the script using : scriptreplay -t file.tm script.out. You will notice there that I was using pyterm as you mentionned.

The zip file : trace_and_script_33_ble.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants