Error when using /dev/ttyS0 on Raspberry Pi

[mni-korfhage]

I'm writing a simple blink program to a board with an ATtiny 416. It works fine when I use a USB-serial adapter /dev/ttyUSB0, but fails with an error when I try using the Raspberry Pi's standard serial port /dev/ttyS0. I have enabled the serial port and disabled the console on it with raspi-config. Here's the text dump. I added some statements to print the flags just before the failing call.

Arduino: 1.8.19 (Linux), Board: "ATtiny3226/3216/1626/1616/1606/826/816/806/426/416/406, ATtiny416, 20 MHz internal, 1.8V (5 MHz or less), Disabled/Disabled, EEPROM retained, Enabled (default timer), UPDI (no reset pin), 8ms, Master or Slave (saves flash and RAM), Default (doesn't print floats, 1.4k flash use), PB0-2, PA3-5, 1-series: PC0/1 (default), On all pins, with new implementation., Disabled (recommended), No delay before window "opens""

Sketch uses 462 bytes (11%) of program storage space. Maximum is 4096 bytes.
Global variables use 10 bytes (3%) of dynamic memory, leaving 246 bytes for local variables. Maximum is 256 bytes.
SerialUPDI
UPDI programming for Arduino using a serial adapter
Based on pymcuprog, with significant modifications
By Quentin Bolsee and Spence Konde
Version 1.2.3 - Jan 2022
Using serial port /dev/ttyS0 at 57600 baud.
Target: attiny416
Set fuses: ['0:0b00000000', '2:0x02', '6:0x04', '7:0x00', '8:0x00']
Action: write
File: /tmp/arduino_build_619189/Blink.ino.hex
iflag 0
oflag 0
cflag 0x1df1
lflag 0
ispeed 4097
ospeed 4097
Traceback (most recent call last):
File "/home/test/.arduino15/packages/megaTinyCore/hardware/megaavr/2.6.10/tools/prog.py", line 286, in
main()
File "/home/test/.arduino15/packages/megaTinyCore/hardware/megaavr/2.6.10/tools/prog.py", line 128, in main
return_code = pymcuprog_basic(args, fuses_dict)
File "/home/test/.arduino15/packages/megaTinyCore/hardware/megaavr/2.6.10/tools/prog.py", line 199, in pymcuprog_basic
status = pymcu._start_session(backend,
File "/home/test/.arduino15/packages/megaTinyCore/hardware/megaavr/2.6.10/tools/libs/pymcuprog/pymcuprog_main.py", line 545, in _start_session
backend.start_session(sessionconfig)
File "/home/test/.arduino15/packages/megaTinyCore/hardware/megaavr/2.6.10/tools/libs/pymcuprog/backend.py", line 359, in start_session
self.programmer.setup_device(
File "/home/test/.arduino15/packages/megaTinyCore/hardware/megaavr/2.6.10/tools/libs/pymcuprog/programmer.py", line 78, in setup_device
self.device_model = get_nvm_access_provider(self.transport,
File "/home/test/.arduino15/packages/megaTinyCore/hardware/megaavr/2.6.10/tools/libs/pymcuprog/nvm.py", line 42, in get_nvm_access_provider
accessprovider = NvmAccessProviderSerial(transport, device_info, baud=frequency, options=options)
File "/home/test/.arduino15/packages/megaTinyCore/hardware/megaavr/2.6.10/tools/libs/pymcuprog/nvmserialupdi.py", line 54, in init
self.avr = UpdiApplication(port, baud, self.dut)
File "/home/test/.arduino15/packages/megaTinyCore/hardware/megaavr/2.6.10/tools/libs/pymcuprog/serialupdi/application.py", line 70, in init
self.phy = UpdiPhysical(serialport, baud_temp)
File "/home/test/.arduino15/packages/megaTinyCore/hardware/megaavr/2.6.10/tools/libs/pymcuprog/serialupdi/physical.py", line 29, in init
self.initialise_serial(self.port, self.baud)
File "/home/test/.arduino15/packages/megaTinyCore/hardware/megaavr/2.6.10/tools/libs/pymcuprog/serialupdi/physical.py", line 50, in initialise_serial
self.ser.open()
File "/home/test/.arduino15/packages/megaTinyCore/hardware/megaavr/2.6.10/tools/libs/serial/serialposix.py", line 272, in open
self._reconfigure_port(force_update=True)
File "/home/test/.arduino15/packages/megaTinyCore/hardware/megaavr/2.6.10/tools/libs/serial/serialposix.py", line 442, in _reconfigure_port
termios.tcsetattr(
termios.error: (22, 'Invalid argument')
termios.error: (22, 'Invalid argument')

FWIW, on a good run with the USB serial adapter, the flag information is

...
File: /tmp/arduino_build_619189/Blink.ino.hex
iflag 0
oflag 0
cflag 0xdfd
lflag 0
ispeed 4097
ospeed 4097
iflag 0
oflag 0
cflag 0x1df1
lflag 0
ispeed 4097
ospeed 4097
Pinging device...
...

Running as root yields the same error, so it doesn't seem to be a permission problem. Any ideas?

[SpenceKonde]

The python serial library is getting an error.

My theory (which is purely baseless conjecture) is that that serialport does not support reconfiguring the port after enabling it in some way. But we have to do that at initialization (we start at a safe slow speed, and once we have set the ASI clock to a fast enough speed to support the baud we actually want, we switch to it. And in the event of an error, it tries to use the double-break, which requires backing the baud rate way down and sending a 0x00 . But you really need to ask someone who Knows python far better than I, particularly serial and python. When I work on Serial UPDI, my google search history fills up with things like "How to concatenate strings python" "What does such-and-such keyword mean in python?" "for loop syntax python". I understand UPDI very well, but this python shit? Hell no

Did you know that python runs on machines with gigabytes of memory? My brain only supports 16-bit addressing. The small amount of working python code I had a hand in modifying for serialUPDI is so bad that when I showed it to my director of quality assurance (ZuZu, the Cat), she hopped off the desk and hacked up a hairball. (which I'm pretty sure is not an approval)... And I didn't even let her see the parts microchip wrote, for her own safety.

If someone could explain what that error means - what it is failing to do - I might be able to bypass it, or I might be able to say "Uh, sorry, if I took that out, it wold be broken for everyone.

This has nothing to do with UPDI per se, it's some serial thing that doesn't behave the same way with the builtin serial port. It may be that it is not possible to use the raspi builtin serial port for UPDI programming. Due to the potential for accidental shorts to other wires in handling, I'd opine that the USB serial method more robust anyway, because most serial adapters are impressively resistant to abuse, while the serial port native on the raspi is likely not....

Note that this is not a priority issue, as current evidence suggests that the problem is not triggered by serialupdi, per your post there is a simple workaround. These are good things, because I'd have as much chance of figuring this out as decipheringthe Voynich Manuscript. So like, definitely don't hold your breath....

[SpenceKonde]

Set to Mystery because current information is insufficient to conclusively differentiate whether it's a hardware incompatibility that you can flail your fists impotently at Broadcom about, a software bug that you can complain to raspi about, or a bug in the actual application code - but it sure looks like it's not application code at faulty from the small amount of information there.

I'd ask for m,ore debugging info, but I don't know what that would be nor could I interpret it if it was provided... soo...

[mni-korfhage]

Your conjecture is a decent starting point. My particular use case is programming an ATtiny already on a Raspberry Pi hat, so it is convenient to use the serial lines already present rather than go out to USB. I was wondering if anyone else has run into this. I'll poke at it a bit more, see if I can get more diagnostic information and then bring it to a Raspberry Pi community where people might recognize the issue. I'll report back if I learn anything useful.

[mni-korfhage]

Setting even parity is the problem. The default serial port on a Raspberry Pi is a mini UART which isn't capable of parity and parity is required for UPDI. It does have other more-capable UARTs that can be enabled. I'll go into detail here for future reference.

A Raspberry Pi 4 has 6 UARTs. The most straightforward ones to explain are uart2 through uart5, which are activated by putting one or more of

dtoverlay=uart2
dtoverlay=uart3
dtoverlay=uart4
dtoverlay=uart5

in /boot/config.txt to activate one of the UARTs as an alternate function on some pins which results in /dev/ttyAMAn (n = 0 and above) appearing. Run "raspi-gpio funcs" to get a list of all the functions on all the GPIO pins. There is a useful thread on activating additional UART ports.

I verified that with dtoverlay=uart5 in /boot/config.txt, TX connected to GPIO12, RX to GPIO13, and using /dev/ttyAMA0, the ATtiny programmed just fine.

Using the standard GPIO 14 and 15 as TX and RX is a little more complicated because 2 UARTs, one of which is the default console, can use these pins and the Bluetooth functions also depend on one of these UARTs. There appear to be 5 different config directives that could affect these, but in the end what worked for me was disabling the serial console but enabling the serial port using raspi-config, then putting

[all]
dtoverlay=miniuart-bt

into /boot/config.txt and programming the device using /dev/ttyAMA0. Apparently the miniuart-bt overlay connects the parity-less mini UART to bluetooth and puts the standard UART on the GPIO pins (see /boot/overlays/README for details). I am not using bluetooth, but I did see that it can find devices, so it is probably functional.

[mni-korfhage]

By the way, the programmer worked at 230400 baud. SerialUPDI - FAST with write delay and SerialUPDI - Turbo with write delay also worked, even though the ATtiny is running at 3.3V. I was using the small Blink sketch, so I wouldn't call these thoroughly tested.