Fixed: upload fails for due; root cause missing checkForRemoteSketchUpdate()

EDIT2: Reflashed the yunshield but still no luck
EDIT1: I did some mods I also did on yun and They might be the root cause of the failure. I'll get back

Hi
I tested the yun shield with a due and I fail to upload.
I used
windows 10
Arduino IDE 1.6.9
sam package 1.6.8
yun firmware "This Yún runs a version of OpenWrt-Yun built on May 10, 2016"

The error I get is

Sketch uses 25,452 bytes (4%) of program storage space. Maximum is 524,288 bytes.
/usr/bin/run-bossac -i -d --port=ttyATH0 -U false -e -w -v -b /tmp/sketch.bin -R
Send auto-baud
Set binary mode
No device found on ttyATH0
done: Success
/usr/bin/run-bossac -i -d --port=ttyATH0 -U false -e -w -v -b /tmp/sketch.bin -R
Send auto-baud
Set binary mode
No device found on ttyATH0
done: Success

Note that the port ttyATH0 exists

Best regards
Jantje

I tried with a arduino mega R3 and that works fine

Build options changed, rebuilding all

Sketch uses 4,344 bytes (1%) of program storage space. Maximum is 253,952 bytes.
Global variables use 206 bytes (2%) of dynamic memory, leaving 7,986 bytes for local variables. Maximum is 8,192 bytes.
/usr/bin/run-avrdude /tmp/sketch.hex -v -patmega2560

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9801 (probably m2560)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file ""
avrdude: writing lfuse (0 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 0 bytes of lfuse written
avrdude: verifying lfuse memory against :
avrdude: load data lfuse data from input file :
avrdude: input file  contains 0 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 0 bytes of lfuse verified
avrdude: reading input file ""
avrdude: writing hfuse (0 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 0 bytes of hfuse written
avrdude: verifying hfuse memory against :
avrdude: load data hfuse data from input file :
avrdude: input file  contains 0 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 0 bytes of hfuse verified
avrdude: reading input file ""
avrdude: writing efuse (0 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 0 bytes of efuse written
avrdude: verifying efuse memory against :
avrdude: load data efuse data from input file :
avrdude: input file  contains 0 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 0 bytes of efuse verified
avrdude: reading input file "/tmp/sketch.hex"
avrdude: writing flash (261406 bytes):

Writing | ################################################## | 100% 4.56s

avrdude: 261406 bytes of flash written
avrdude: verifying flash memory against /tmp/sketch.hex:
avrdude: load data flash data from input file /tmp/sketch.hex:
avrdude: input file /tmp/sketch.hex contains 261406 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 6.47s

avrdude: verifying ...
avrdude: 261406 bytes of flash verified

avrdude done.  Thank you.

Hi Jantje,

the Due is a special case because before uploading a new sketch you need to erase the flash (this is autmatically made in USB upload and there is an erase button on the board for fail safe operation).

For triggering the erase in remote upload with the Yun Shield you need to put as first instruction of the sketch a special function called "checkForRemoteSketchUpdate()"

As you can see in this example:

So I suggest you to upload this sketch using the USB port (either Native or Programming) then try again a remote upload of another sketch including the "checkForRemoteSketchUpdate()" function.

Thanks for the feedback, we are going to improve the documentation in the next hours.

This worked.
Yes please update the documentation.
Jantje

Hey Jantje,
Is the checkForRemoteSketchUpdate() everything you changed?
I'm experiencing the same problem - bossac says "No device found on ttyATH0", even with checkForRemoteSketchUpdate().

I think it is successfully instructing the Due to delete the flash (the firmware seems to be gone afterwards), but still no luck getting bossac to flash the new one...

Any thoughts?

All the best,

Merthin

Once you uploaded a sketch without the checkForRemoteSketchUpdate() you no longer can upload remotely.
So you need to upload a sketch containing checkForRemoteSketchUpdate() directly via com port.
Note that if the bootloader is no longer on the due you will have to burn a bootloader to the due first.

Yeah, the sketch runs checkForRemoteSketchUpdate(), but I still get the "device not found" error.

root@Arduino:~# /usr/bin/run-bossac -i -d --port=ttyATH0 -U false -e -w -v -b /t
mp/firmware.bin -R
Send auto-baud
Set binary mode
No device found on ttyATH0
done: Success

It seems like the flash actually gets deleted, since the microcontroller doesn't seem to have any firmware afterwards. (I then flash it again via the programming port...)

Is there any way to tell if the bootloader is gone? I thought that's hardwired into the Due...

Is there any way to tell if the bootloader is gone?

If you can upload via com port the bootloader is there.
Unfortunately there are 2 usb ports on the due and I'm not so known with this part of the story.

The bootloader was indeed gone, so I had to restore the Arduino firmware via programming port. (subsequently, the native port worked again).

However, still no luck with bossac. The flash-wipe via pin7 / checkForRemoteSketchUpdate() works, but bossac still complains about not finding a device on /dev/ttyATH0

I already commented out the console line on inittab, and as far as I can see the run-bossac script kills any processes open on /dev/ttyATH0

However, I get this readout:

root@Arduino:/usr/bin# dmesg | egrep 'serial|tty'
[    0.000000] Kernel command line:  board=Yun_Shield console=ttyATH0,250000 mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,14656k(rootfs),1280k(kernel),64k(nvram),64k(art),15936k@0x50000(firmware) rootfstype=squashfs,jffs2 noinitrd mem=64M rootfstype=squashfs,jffs2 noinitrd
[    0.650000] ar933x-uart: ttyATH0 at MMIO 0x18020000 (irq = 11, base_baud = 2500000) is a AR933X UART
[    0.650000] console [ttyATH0] enabled

Does this mean there is a console on ttyATH0 open after all that might interfere with bossac? Any ideas of how to close it?

I'm trying to establish communication between the shield and Due, e.g. just receiving Serial messages from the Arduino via cat < /dev/ttyATH0 - but also no results. (I'm using Serial class on the Arduino for that. Is that right? Or should it be SerialUSB / Bridge?)

Does the Yun Shield communicate via SPI or pins 0 / 1 (Tx / Rx)?

Some more thoughts:
Are you sure the bootloader on the Due is the issue? From the Due documentation:
"The bootloader is preburned in factory from Atmel and is stored in a dedicated ROM memory."

I believe that when the flash is erased I can upload via the programming port, but not via the native port. (Native port upload is restored, when a sketch runs)

The run-bossac script together with checkRemoteFirmwareUpdate() successfully deletes the flash.

Everything seems to be working, except that bossac can not find any device on /dev/ttyATH0... Seriously, not sure what to test / try next.

Does the Yun Shield communicate via SPI or pins 0 / 1 (Tx / Rx)?

IMHO these pins are connected to /dev/ttyATH0.
I don't know whether these are needed for upload.

base_baud = 2500000

I never use more than 115200. Higher is unstable for me.

I use following command to be able to read /dev/ttyATH0. Note you have to stop the bridge to get reliable input.

stty -F ${PortName}  ${SerialSpeed}  raw -clocal -echo icrnl

If all this fails contact support
Best regards
Jantje

Hi Jantje,

Thanks for your help!

So simple Serial communication to / from Arduino Due with cat works now, thanks to changing the baud to 9600. (I also had the sketch Serial.begin still running at 9600...).

The only mysterious player is still bossac.

  • Sketch definitely successfully runs updateRemoteFirmwareUpdate() when instructed by run-bossac via pin7
  • normal communication to /dev/ttyATH0 works
  • but bossac consistently gives this output
root@Arduino:/usr/bin# run-bossac -i -d --port=ttyATH0 -U false -e -w -v -b /tmp/firmware.bin -R
Send auto-baud
Set binary mode
No device found on ttyATH0
done: Success

(The last done: Success comes from the reset-serial command in the run-bossac script). Very frustrating and strange.

Which is exactly the same error I got when I tried to upload a sketch and the running sketch did not contain checkForRemoteSketchUpdate

Yeah, I know.

checkForRemoteSketchUpdate()

is definitely in the sketch, as the first line in setup().

Indeed, that is why after running run-bossac, the flash is successfully erased, since the shell script sets pin 7. (Doesn't happen without checkFor...).
[On a side: It's a bit strange to me that it is indeed required, since you should also be able to read from the flash using bossac.]

This is the definition of checkForRemoteSketchUpdate:

#if defined(ARDUINO_ARCH_SAM)
void checkForRemoteSketchUpdate(uint8_t pin) {
  // The host force pin LOW to signal that a new sketch is coming
  pinMode(pin, INPUT_PULLUP);
  delay(50);
  if (digitalRead(pin) == LOW) {
    initiateReset(1);
    while (true)
      ; // Wait for reset to SAM-BA
  }

  // Restore in standard state
  pinMode(pin, INPUT);
}

So the magical line is the "initateReset", but haven't found the declaration yet.

So the magical line is the "initateReset", but haven't found the declaration yet.

That is in core/Reset.cpp
I think the thing you are looking for is

void banzai() {
	// Disable all interrupts
	__disable_irq();

	// Set bootflag to run SAM-BA bootloader at restart
	const int EEFC_FCMD_CGPB = 0x0C;
	const int EEFC_KEY = 0x5A;
	while ((EFC0->EEFC_FSR & EEFC_FSR_FRDY) == 0);
	EFC0->EEFC_FCR =
		EEFC_FCR_FCMD(EEFC_FCMD_CGPB) |
		EEFC_FCR_FARG(1) |
		EEFC_FCR_FKEY(EEFC_KEY);
	while ((EFC0->EEFC_FSR & EEFC_FSR_FRDY) == 0);

	// From here flash memory is no more available.

	// BANZAIIIIIII!!!
	const int RSTC_KEY = 0xA5;
	RSTC->RSTC_CR =
		RSTC_CR_KEY(RSTC_KEY) |
		RSTC_CR_PROCRST |
		RSTC_CR_PERRST;

	while (true);
}

I don't know how it does it but it forces a reset.

Hello Jantje,

I am also trying to use the DUE with the Yun board, but I am not as far as you with the task.

I am still trying to figure out how to include the BOSSAC into my distribution for the yun.
I am using a Dragino Board, thats the same like the Yun Shield.

Can you please provide me a link for an installation package to run BOSSAC on the Yun shield.

Thank you very much,
Michael