Serial interface locks up on Nano Every #51

technoblogy · 2019-07-31T15:18:06Z

On a Nano Every, if you try and transfer more than about 128 characters from the Serial Monitor to the board via the serial interface it locks up, and the only solution is to unplug the USB cable.

The following program demonstrates the problem:

void setup() {
  Serial.begin(9600);
  while (!Serial);
  Serial.println("Ready");
}

int count = 0;

void loop() {
  if (count % 64 == 0) {
    Serial.println();
    Serial.print(count);
    Serial.write(' ');
  }
  while (!Serial.available());
  Serial.write((int)Serial.read());
  count++;
}

Open the Serial Monitor, copy a line of text of 128 characters, paste it into the input field, and click Send.

I'm running Arduino IDE 1.8.9 on a Mac, and the Arduino megaAVR Boards file version 1.8.3.

It works fine on a Uno WiFi Rev 2.

The text was updated successfully, but these errors were encountered:

Fixes https://github.com/arduino/Arduino/issues/9112

facchinm · 2019-08-02T13:33:43Z

Hi @technoblogy , thanks for reporting. I investigated the problem and indeed it lies in the USB stack for the D11 (muxto).
I patched the binaries here (ee0a9bd) but I would need your help to validate them.

Could you follow the guide at https://www.arduino.cc/en/Guide/NANOEvery (Firmware for SAMD11D14A chapter), trigger the D11 bootloader, extract the attached zip and execute this command?
./bossac --port=$portname -U true -i -e -w -v MuxTO.bin -R
update_muxto.zip
Thanks a lot

technoblogy · 2019-08-03T14:00:51Z

Thanks for the reply - I'll try upgrading my firmware.

technoblogy · 2019-08-16T15:11:35Z

@facchinm I'm struggling with this. Do I have to install the MattairTech core? Do I need to solder a link between the D11 SWDIO and GND pins? Where should I give the command:

./bossac --port=$portname -U true -i -e -w -v MuxTO.bin -R

When I do it in the Mac Terminal I just get:

./bossac: No such file or directory

facchinm · 2019-08-19T08:47:03Z

Hi @technoblogy ,
the first command you used was fine (you need the bossac binary contained in the zip).
Probably OSX blocked the file from being executable, so my advice is:

run chmod +x bossac inside the extracted folder
run ./bossac and see if it starts at least
no need to solder the link, the short circuit should exist just when powering the board (I normally use tweezers to create the short and then connect the type A side of the USB cable to the PC, with the cable on the nano side already inserted)
$portname should be replaced by the actual port name, that you can discover from the IDE serial monitor

technoblogy · 2019-08-19T15:51:36Z

Still not working. I plugged in the board with the SWDIO pin connected to ground. The instructions say:

The board will appear as "MuxTo bootloader"

Where will that appear?

I'm getting:

david$ ./bossac --port=/dev/cu.usbmodem1411 -U true -i -e -w -v MuxTO.bin -R
No device found on /dev/cu.usbmodem1411

technoblogy · 2019-08-19T16:00:28Z

OK, I've worked it out. The Serial Monitor says /dev/cu.usbmodem1411, but if I do:

ls /dev/tty.*

I get:

/dev/tty.Bluetooth-Incoming-Port /dev/tty.usbmodem1411

So I tried:

./bossac --port=/dev/tty.usbmodem1411 -U true -i -e -w -v MuxTO.bin -R

and that worked.

Note that I didn't need to run chmod +x bossac.

technoblogy · 2019-08-19T16:20:01Z

I confirm that the muxto bootloader 1.0.6 fixes the serial problem I reported - many thanks!

One final question. I was thinking of specifying the Nano Every board to users for an application I've developed, but for my application this problem makes the board unusable, and I don't think they will all be able to do this upgrade.

How many boards have shipped with the pre-1.0.6 bootloader? Will it be corrected in future boards, and will there be a way of telling which version you've got?

Thanks, David

facchinm · 2019-08-20T07:53:10Z

Thanks for getting back!

The next batch will be flashed with 1.0.6 but there's very little chance to be able to reflash the boards currently in the market (except the ones we still have "in house").

About reflashing, the procedure you followed is the most complicated (but doesn't need any additional hardware). Any 10$ SWD programmer can reflash the D11 using the same pins on the bottom and is much faster (if you need to do it more than once).

Finding the MuxTO version flashed on a board is not easy at all, we had to strip a lot of information to fit the firmware in 12KB, but we can trace back the fw that was originally flashed using the board's serial number.

technoblogy · 2019-08-20T07:57:58Z

we can trace back the fw that was originally flashed using the board's serial number.

I think that would be useful, so we can say "if your serial number is later than xxx you don't need to do this".

facchinm · 2019-08-20T08:02:13Z

It's a bit more complicated since serial numbers are not consecutive, so we need to query the boards DB to get that information 😑

technoblogy · 2019-08-20T08:12:12Z

Here's a summary of the procedure that worked for me on a Mac, in case it's useful for anyone else:

Download MuxTO 1.0.6 from update_muxto.zip.
Drag the downloaded folder to the desktop.
Open Mac Terminal.
Change to the update_muxto folder with the command (insert your user name as appropriate):

cd /Users/david/Desktop/update_muxto

While connecting the SWDIO pin to GND connect the board to your computer's USB port. You can then remove the link:

In the Terminal find the USB port by giving the command:

ls /dev/tty.*

This should print a list of ports; something like:

/dev/tty.Bluetooth-Incoming-Port /dev/tty.usbmodem1411

The one you want is the usbmodem one.

Give the command:

./bossac --port=/dev/tty.usbmodem1411 -U true -i -e -w -v MuxTO.bin -R

substituting the port printed in the previous command.

If all is well you should see the upgrade information printed by the Bossac installer. When that's finished you can unplug the board, and then plug it back in to use it with the new bootloader.

technoblogy · 2019-08-28T10:13:57Z

I now have a different problem; detecting whether the Serial is ready.

With this simple test:

void setup() {
  Serial.begin(9600);
}

void loop() {
  Serial.println("Hello");
  for(;;);
}

I get nothing printed unless I insert a delay:

void setup() {
  Serial.begin(9600);
  delay(5000);
}

void loop() {
  Serial.println("Hello");
  for(;;);
}

The usual test for whether the Serial is ready is:

while (!Serial);

However, on Nano Every it appears that Serial returns true even when the serial isn't ready, because if I do:

void setup() {
  Serial.begin(9600);
  int start = millis();
  while ((millis() - start) < 5000) { if (Serial) break; }
}

void loop() {
  Serial.println("Hello");
  for(;;);
}

I again get nothing printed.

technoblogy · 2019-08-28T18:25:12Z

Although MuxTO 1.0.6 is a big improvement over the version that was originally installed on my Nano Every, unfortunately there is still corruption occurring in the serial interface. You can demonstrate this as follows:

Load and run the original demonstration program:

void setup() {
  Serial.begin(9600);
  while (!Serial);
  Serial.println("Ready");
}

int count = 0;

void loop() {
  if (count % 64 == 0) {
    Serial.println();
    Serial.print(count);
    Serial.write(' ');
  }
  while (!Serial.available());
  Serial.write((int)Serial.read());
  count++;
}

Select and copy the following text:

 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~�
 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~�
 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~�
 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~�
 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~�
 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~�
 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~�
 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~�
 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~�
 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~�
 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~�

Open the Arduino IDE Serial Monitor. Make sure it's set to Newline, 9600 baud.
Paste the text into the field at the top of the Serial Sonitor and click Send.

The output looks like this; the red circles show the dropped characters.

29th August 2019: Updated screenshot to show additional dropped characters.

hiduino · 2019-08-29T06:39:13Z

Is there any Windows driver for the MuxTo mode? Or do I need to find a Mac to update the firmware?

facchinm · 2019-09-09T13:17:24Z

@technoblogy about the !Serial issue there's little we can do with the current schematics since the RST pin is not connected. A possible workaround is invoking the UPDI reset via fw on port open but the space to implement it is very tight.

Same space issue for holes in transmission, samd11 RAM is not enough to have big buffers, so even if all the data is flushed it still takes the "9600bps-specific" amount of time to deliver it, and the serial starts dropping characters.

@hiduino you can use the exact same package for windows, simply replace bossac binary with bossac.exe from here

hiduino · 2019-09-10T02:37:41Z

@facchinm, thank you, that version of bossac worked on Windows with the Nano Every!
I was able to update the MuxTo.

Side note: I had to make an extra entry in the arduino-samd.inf file to add the VID/PID for the MuxTo bootloader so that Windows could add the serial COM port entry.

technoblogy · 2019-09-10T08:40:06Z

the serial starts dropping characters

@facchinm this makes the serial unusable for many applications. Is there any way of fixing this? The SAMD11 has up to 16Kbytes of SRAM - surely that's enough for buffers?

facchinm · 2019-09-10T09:47:40Z

@technoblogy it has 16KB of flash and 4KB of RAM, the USB buffers can still be enlarged a bit but not that much

facchinm · 2019-09-10T10:12:32Z

I repeated your stress test too with the firmware from #52 and it doesn't lose any character. If you could retest in your environment and report back it would be great.
Thanks you very much for helping.

technoblogy · 2019-09-10T10:18:06Z

OK, I'll test it - thanks!

MCUdude · 2019-09-10T10:27:09Z

@facchinm now that we got an early alpha version of Optiboot running on ATmega4809, would it be possible/make sense (in the future) to turn the SAMD11 into a dedicated USB to serial adapter instead, and not having to use the UPDI interface for programming? Maybe just change the USB PID so it would be able to identify it?

facchinm · 2019-09-10T10:29:44Z

@MCUdude makes sense, but the procedure would be a bit convoluted (we need to burn optiboot using the UPDI layer BEFORE updating the D11, a bit error prone 🙂 )

EDIT: if you meant on new boards, it TOTALLY makes sense

MCUdude · 2019-09-10T10:37:37Z

EDIT: if you meant on new boards, it TOTALLY makes sense

Yes, doing so for old boards would not make sense, I meant new boards. What's awesome about this is that it would now be possible to use avrdude directly, since the 1200bps touch is difficult to perform outside Arduino IDE. If you went for a 5V compatible USB to serial adapters, like the 8u2/16u2 you can also get rid of all level shifting too.

EDIT:
The 8u2/16u2 requires more external components to function and would occupy much more board space. IMO it would be difficult to do this without doing something with the physical board size, which of course is out of the question 😉

hiduino · 2019-09-11T04:11:00Z

Observations from testing firmware from #52, it seems to only work right after an IDE Upload. If you unplug and re-plug the USB then it appears the UPDI doesn't reset the 4809. Also it still appears to lockup after 7 or 8 of the large buffer inputs.

facchinm · 2019-09-11T07:53:09Z

@hiduino can you provide a test case for the large buffers lockup?

If you unplug and replug the usb without externally powering the board the 4809 obviously resets 🙂
The behaviour should match classic UNO/nano (reset on open port)

EDIT: I reproduced the large buffers issue and patched it in the same PR. If you could test it independently it would be great.

hiduino · 2019-09-11T09:43:19Z

@facchinm , Yes, that seems to correct the large buffer lockup issue now.

To clarify, for the board reset, it doesn't seem to work from the IDE Serial Monitor invoke after you unplug/replug the board back in. The UPDI reset only seem to work after a fresh Upload. Could it be the state of UPDI after a replug in?

If I close and re-open the Serial Monitor should it not cause the UPDI reset? It doesn't after a USB unplug/replug.

facchinm · 2019-09-11T10:10:17Z

@hiduino got it, I've been able to reproduce and I'm taking a look immediately, thanks!

EDIT: pushed a new commit & firmware that solves the issue, thanks again for the report.

technoblogy · 2019-09-11T18:14:58Z

If you could retest in your environment and report back it would be great.

@facchinm do I just need to upload a new MuxTO to the board? If so, could you give me a download link for it?

hiduino · 2019-09-11T21:53:36Z

@facchinm , Okay, looks like the UPDI reset works correctly now after an unplug/re-plug of the USB.
Great work!

Edit: Tested on 4 different Nano Every boards, all work great.

hiduino · 2019-09-11T21:56:17Z

@technoblogy , you can go to the pull request #52 page and open up the Files changed tab, then view file to download the MuxTo.bin file.

technoblogy · 2019-09-18T17:23:23Z

@facchinm I've uploaded the latest MuxTO.bin file to my Arduino Nano Every. I can't find any version number to identify it, but it has a modification date of 12 Sept 2019.

Unfortunately I can't detect any improvement - there is still corruption occurring in the serial interface. My demonstration program earlier in this post gives exactly the same sorts of dropped characters.

Should it have improved these?

facchinm · 2019-09-19T07:41:19Z

@technoblogy to identify the new version just upload a sketch with verbose on and you should see these lines.

M_MCU:
  boot-loader FW version:        1
  firmware version:              1.07
  hardware version:              1
S_MCU:
  boot-loader FW version:        1
  firmware version:              6.07
  hardware version:              1

This firmware fixes your test case for me, with no dropped characters

hiduino · 2019-09-19T09:21:50Z

@technoblogy , I've also tested the latest MuxTo and did not experience any drop characters. I've tried copying over 20 times of the large buffer test and no drop characters observed. I'm testing on two different Windows 7 Pro platforms using Serial Monitor from the IDE. Have you try testing with different USB cables or on different systems?

technoblogy · 2019-09-19T09:53:20Z

I'll try when I get home at lunchtime.

technoblogy · 2019-09-19T11:48:52Z

I get this:

M_MCU:
  boot-loader FW version:        1
  firmware version:              6.00
  hardware version:              1
S_MCU:
  boot-loader FW version:        1
  firmware version:              6.00
  hardware version:              1

You said:

@technoblogy , you can go to the pull request #52 page and download the MuxTo.bin file.

I couldn't find a MuxTO.bin file download link on that page so I downloaded the whole ArduinoCore-megaavr project and located the MuxTO.bin file in the MuxTO folder, which had the date 12 Sept 2019.

facchinm · 2019-09-19T12:11:31Z

@technoblogy you did the right thing but it looks like the firmware didn't update properly. Are you sure you are flashing the right .bin? Make sure you remove the one I sent you at the beginning in the zip.

technoblogy · 2019-09-19T12:36:55Z

I've tried again. This is what I get in the terminal:

Phobos-644:update_muxto david$ ./bossac --port=/dev/tty.usbmodem1411 -U true -i -e -w -v MuxTO.bin -R
Atmel SMART device 0x10030000 found
Device       : ATSAMD11D14AM
Chip ID      : 10030000
Version      : v2.0 May 29 2019 12:13:04
Address      : 4096
Pages        : 192
Page Size    : 64 bytes
Total Size   : 12KB
Planes       : 1
Lock Regions : 16
Locked       : none
Security     : false
Boot Flash   : true
BOD          : true
BOR          : true
Erase flash
done in 0.631 seconds

Write 12220 bytes to flash (191 pages)
[==============================] 100% (191/191 pages)
done in 7.166 seconds

Verify 12220 bytes of flash
[==============================] 100% (191/191 pages)
Verify successful
done in 0.487 seconds
CPU reset.
Phobos-644:update_muxto david$

but when I upload a sketch from the Arduino IDE I still get:

Communications protocol version: 1
M_MCU:
  boot-loader FW version:        1
  firmware version:              6.00
  hardware version:              1
S_MCU:
  boot-loader FW version:        1
  firmware version:              6.00
  hardware version:              1
Serial number:                   00:00:00:00:00:00

Please can you give me a direct link to the correct MuxTO.bin file.

facchinm · 2019-09-19T12:43:53Z

The update should read

[martino@arch-elitebook Documents]$ ~/.arduino15/packages/MattairTech_Arduino/tools/bossac/1.7.0-mattairtech-3/bossac --port=/dev/ttyACM0 -U true -i -e -w -v MuxTO.bin -R
Atmel SMART device 0x10030000 found
Device       : ATSAMD11D14AM
Chip ID      : 10030000
Version      : v2.0 May 29 2019 12:13:04
Address      : 4096
Pages        : 192
Page Size    : 64 bytes
Total Size   : 12KB
Planes       : 1
Lock Regions : 16
Locked       : none
Security     : false
Boot Flash   : true
BOD          : true
BOR          : true
Erase flash
done in 0.337 seconds

Write 12288 bytes to flash (192 pages)
[==============================] 100% (192/192 pages)
done in 3.016 seconds

Verify 12288 bytes of flash
[==============================] 100% (192/192 pages)
Verify successful
done in 0.384 seconds
CPU reset.

The new firmware is 12288 bytes long; try redownloading using this link https://github.com/arduino/ArduinoCore-megaavr/raw/master/firmwares/MuxTO/MuxTO.bin

technoblogy · 2019-09-19T13:27:18Z

OK, thanks, now I get:

M_MCU:
  boot-loader FW version:        1
  firmware version:              1.07
  hardware version:              1
S_MCU:
  boot-loader FW version:        1
  firmware version:              6.07
  hardware version:              1

However, sorry, I'm still getting dropped characters:

I'm running this on a Mac with Arduino IDE 1.8.9.

technoblogy · 2019-09-25T07:34:20Z

Please can you reopen this issue as it isn't solved.

Also, I think it should stay open even when it is solved, so users who have received the boards with MuxTO prior to 1.0.6 can find out how to upgrade.

JAndrassy · 2020-01-19T19:11:17Z

I updated the firmware in SAMD11 too. I am on Linux.

Important is to use bossac version 1.7.0-mattairtech-3 installed with MattairTech_Arduino SAMD 1.6.17. The bossac installed with Arduino SAMD and older MattairTech versions report unknown device.

The boards package JSON for MattairTech_Arduino SAMD is hard to find in the middle of the README so here it is: https://www.mattairtech.com/software/arduino/package_MattairTech_index.json

the latest firmware bin is here https://github.com/arduino/ArduinoCore-megaavr/tree/master/firmwares/MuxTO

facchinm referenced this issue in arduino/ArduinoCore-samd Aug 2, 2019

Remove PLUGGABLEUSB and import modern DoubleBufferedEPOutHandler

da5b342

Fixes https://github.com/arduino/Arduino/issues/9112

facchinm closed this as completed in ee0a9bd Aug 2, 2019

facchinm reopened this Aug 2, 2019

facchinm transferred this issue from arduino/Arduino Sep 10, 2019

facchinm mentioned this issue Sep 10, 2019

[MuxTO] Reset 4809 on baudrate change / port open #52

Merged

facchinm closed this as completed in #52 Sep 16, 2019

laurencebarker mentioned this issue Dec 18, 2019

Serial interface problem with Arduino Nano Every #63

Closed

roboticboyer mentioned this issue Jan 6, 2020

Bossac for Linux #65

Closed

ganghuang mentioned this issue Dec 29, 2021

Compiled MuxTo binary too large #103

Closed

Serial interface locks up on Nano Every #51

Serial interface locks up on Nano Every #51

Comments

technoblogy commented Jul 31, 2019

facchinm commented Aug 2, 2019

technoblogy commented Aug 3, 2019

technoblogy commented Aug 16, 2019

facchinm commented Aug 19, 2019

technoblogy commented Aug 19, 2019

technoblogy commented Aug 19, 2019 • edited Loading

technoblogy commented Aug 19, 2019

facchinm commented Aug 20, 2019

technoblogy commented Aug 20, 2019

facchinm commented Aug 20, 2019

technoblogy commented Aug 20, 2019 • edited Loading

technoblogy commented Aug 28, 2019

technoblogy commented Aug 28, 2019 • edited Loading

hiduino commented Aug 29, 2019

facchinm commented Sep 9, 2019

hiduino commented Sep 10, 2019 • edited Loading

technoblogy commented Sep 10, 2019

facchinm commented Sep 10, 2019

facchinm commented Sep 10, 2019

technoblogy commented Sep 10, 2019

MCUdude commented Sep 10, 2019

facchinm commented Sep 10, 2019 • edited Loading

MCUdude commented Sep 10, 2019 • edited Loading

hiduino commented Sep 11, 2019

facchinm commented Sep 11, 2019 • edited Loading

hiduino commented Sep 11, 2019 • edited Loading

facchinm commented Sep 11, 2019 • edited Loading

technoblogy commented Sep 11, 2019

hiduino commented Sep 11, 2019 • edited Loading

hiduino commented Sep 11, 2019 • edited Loading

technoblogy commented Sep 18, 2019

facchinm commented Sep 19, 2019

hiduino commented Sep 19, 2019

technoblogy commented Sep 19, 2019

technoblogy commented Sep 19, 2019 • edited Loading

facchinm commented Sep 19, 2019

technoblogy commented Sep 19, 2019

facchinm commented Sep 19, 2019

technoblogy commented Sep 19, 2019

technoblogy commented Sep 25, 2019

JAndrassy commented Jan 19, 2020

technoblogy commented Aug 19, 2019 •

edited

Loading

technoblogy commented Aug 20, 2019 •

edited

Loading

technoblogy commented Aug 28, 2019 •

edited

Loading

hiduino commented Sep 10, 2019 •

edited

Loading

facchinm commented Sep 10, 2019 •

edited

Loading

MCUdude commented Sep 10, 2019 •

edited

Loading

facchinm commented Sep 11, 2019 •

edited

Loading

hiduino commented Sep 11, 2019 •

edited

Loading

facchinm commented Sep 11, 2019 •

edited

Loading

hiduino commented Sep 11, 2019 •

edited

Loading

hiduino commented Sep 11, 2019 •

edited

Loading

technoblogy commented Sep 19, 2019 •

edited

Loading