BOSSA icon indicating copy to clipboard operation
BOSSA copied to clipboard

MacOS fails programming SAM S70, Windows succeeds

Open mbavaro opened this issue 6 years ago • 12 comments

I spent some time yesterday trying to figure why programming on my MAC wouldn't work.. it kept returning early with this error:

$ bossac -p /dev/tty.usbmodem1443201 -i -U -e -w -v -b BaseboardMCU7.bin 
Device       : ATSAMS70x21
Version      : v1.1 Oct 13 2014 12:02:31
Address      : 0x400000
Pages        : 4096
Page Size    : 512 bytes
Total Size   : 2048KB
Planes       : 1
Lock Regions : 128
Locked       : none
Security     : false
Boot Flash   : false
Erase flash

Done in 7.694 seconds
Write 68208 bytes to flash (134 pages)

Then switched to Windows (GUI) and everything went smoothly, and the operation completed in a few seconds. I suspect something might be up with PosixSerialPort.cpp.. but I have not tried on Linux honestly. Anybody else noticed the same behavior? I tried all sorts of things with stty -f /dev/cu.usbmodemxxx and stty -f /dev/tty.usbmodemxxx taking care to keep the serial port file descriptor open but nothing helped.. and after all the port configuration is probably overridden when BOSSA starts.

mbavaro avatar Sep 12 '19 15:09 mbavaro

I believe I have the same issue, on Mac OSX Mojave

bossac --info --port /dev/tty.usbmodem141201 --erase --write --verify --boot --reset firmware.bin
Device       : ATSAME70x21
Version      : v1.2 Jan  6 2016 09:57:32
Address      : 0x400000
Pages        : 4096
Page Size    : 512 bytes
Total Size   : 2048KB
Planes       : 1
Lock Regions : 128
Locked       : none
Security     : false
Boot Flash   : false
Erase flash

Done in 7.136 seconds
Write 943716 bytes to flash (1844 pages)
[                              ] 0% (0/1844 pages)
SAM-BA operation failed

Any following attempts produce:

bossac --info --port /dev/tty.usbmodem141201 --erase --write --verify --boot --reset firmware.bin
No device found on /dev/tty.usbmodem141201

If I power cycle, I get the first error again.

peter-moran avatar Nov 18 '19 20:11 peter-moran

Same issue, Mac OSX Mojave, Bossa 1.9.1, both GUI and command line versions. Works on Windows.

bossac -i -p /dev/tty.usbmodem14101 -e -w -v -b Duet3Firmware_MB6HC.bin -R
Device       : ATSAME70x20
Version      : v1.2 Jan  6 2016 09:57:32
Address      : 0x400000
Pages        : 2048
Page Size    : 512 bytes
Total Size   : 1024KB
Planes       : 1
Lock Regions : 64
Locked       : none
Security     : false
Boot Flash   : false
Erase flash

Done in 3.626 seconds
Write 560772 bytes to flash (1096 pages)
[                              ] 0% (0/1096 pages)
Flash command failed

droftarts avatar Mar 18 '20 12:03 droftarts

I suspect something might be up with PosixSerialPort.cpp.. but I have not tried on Linux honestly. Anybody else noticed the same behavior?

I've flashed a ATSAME70x20 using bossac from a Raspberry Pi running Raspbian buster, no trouble there.

beikeland avatar Mar 20 '20 21:03 beikeland

Over on the Duet3D forums there a even a few cases of windows failing in a seemingly similar manor, unsure if usb cable issues or the same underlying problem. (confirmed same board, same cable, same binary, change from Windows to Raspbery Pi and flashing work)

Possibly related to https://github.com/shumatech/BOSSA/pull/121 ?

I wasn't able to build bossac.exe to test with current mingw will see if I can try the 7.3.0 version mentioned in another issue when i find the time. (usleep was deprecated in the current mingw).

beikeland avatar May 03 '20 12:05 beikeland

I seem to be hitting a similar problem on a ATSAME70X21 running on Mac OSX High Sierra (no chance to test on windows yet). In my case it always writes 18 pages before failing. Have tested the suggestion with adding an extra wait after flush() in Samba.cpp as per #121 , but made no difference. I also have the 'feeling' that the writing is really slow at about 35s for writing ~9000 bytes (that would be nearly 2400baud? far away from the intended high baudrate of >900kbaud)

./bossac -e -w -v -b -i -p cu.usbmodemFD121 firmware.bin
Device       : ATSAME70x21
Version      : v1.1 Oct 13 2014 12:02:31
Address      : 0x400000
Pages        : 4096
Page Size    : 512 bytes
Total Size   : 2048KB
Planes       : 1
Lock Regions : 128
Locked       : none
Security     : false
Boot Flash   : false
Erase flash

Done in 7.086 seconds
Write 60708 bytes to flash (119 pages)
[====                          ] 15% (18/119 pages)
SAM-BA operation failed

joverbee avatar Oct 27 '20 12:10 joverbee

I dug a bit deeper and found that it stops writing at address 400E0C08 where the _port->read in readword() in Samba.cpp returns only 2 bytes instead of 4. Tried playing a bit with timeouts, but to no avail so far. Checked on pc with SAMBA tool and the file uploads fine.

joverbee avatar Oct 27 '20 19:10 joverbee

I've seen a similar issue. This appears to work for me: https://github.com/shumatech/BOSSA/pull/150

kaysievers avatar Jan 13 '21 00:01 kaysievers

I bought a PC laptop so problem should have resolved itself (at least for me).

joverbee avatar Jan 15 '21 18:01 joverbee

Hi all, same issue here with SAMS70N20B and Mac OS X Monterey. Built the latest BOSSA version including #150. It works fine in Windows 10 and Linux but fails on Mac. Any further thoughts on this issue?

msxmatt avatar Aug 18 '22 00:08 msxmatt

Did a little looking around and it seems like one of the USB buffers may be capped at 384 bytes on Mac. I was able compare HEX dumps of my S70 when I programmed with BOSSA vs my programmer and see that 128 bytes were missing every 512 bytes (S70 page size).

I fixed it by splitting up the SAM-BA write commands into chunks <= 384 bytes for Mac. Here's a snippet of my modified code from the Samba::write command:

    // Split up large USB transfers into multiple writes
    // (Mac only, USB buffer maxes out at 384 bytes)
    if (_isUsb && _port->getSplitLargeXfers() && size > MAX_XFER_SIZE) {

        // Initialize counter and chunk size at max
        int bytes_left = size;
        int chunk_size = MAX_XFER_SIZE;

        // Iterate through the write chunks
        for (int i = 0; bytes_left > 0; i++, bytes_left -= chunk_size) {

            // Last write, transfer the remainder
            if (bytes_left < MAX_XFER_SIZE) {
                chunk_size = bytes_left;
            }
        
            if (_debug)
                printf("%s(addr=%#x,size=%#x)\n", __FUNCTION__, (addr + (i * MAX_XFER_SIZE)), chunk_size);

            // Issue SAM-BA write command for chunk
            snprintf((char*) cmd, sizeof(cmd), "S%08X,%08X#", (addr + (i * MAX_XFER_SIZE)), chunk_size);
            if (_port->write(cmd, sizeof(cmd) - 1) != sizeof(cmd) - 1)
                throw SambaError();

            // Write chunk data out
             _port->flush();
            writeBinary((buffer + (i * MAX_XFER_SIZE)), chunk_size);
        }
    }

MAX_XFER_SIZE is set to 384 bytes.

Now I can program my S70 from Mac no problem. Hopefully this might help others with this problem.

msxmatt avatar Aug 19 '22 19:08 msxmatt