-
Notifications
You must be signed in to change notification settings - Fork 253
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
MacOS fails programming SAM S70, Windows succeeds #106
Comments
I believe I have the same issue, on Mac OSX Mojave
Any following attempts produce:
If I power cycle, I get the first error again. |
Same issue, Mac OSX Mojave, Bossa 1.9.1, both GUI and command line versions. Works on Windows.
|
I've flashed a ATSAME70x20 using bossac from a Raspberry Pi running Raspbian buster, no trouble there. |
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 #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). |
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)
|
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. |
I've seen a similar issue. This appears to work for me: #150 |
I bought a PC laptop so problem should have resolved itself (at least for me). |
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? |
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
Now I can program my S70 from Mac no problem. Hopefully this might help others with this problem. |
@msxmatt it looks like you changed the |
@msxmatt I'm struggling to get Bossa working on MacOS to flash SAM S70, and I saw your comment. I found where to put your code snippet in Samba.cpp, replacing lines 521 to 525. Line 521 in 3532de8
And added a define for MAX_XFER_SIZE just before your code: However, I get this error message during compilation:
If I leave out "_port->getSplitLargeXfers() &&", Bossa compiles and runs, but I get an error when trying to connect to the port, and it returns "SAM-BA operation failed". Did you add code elsewhere, as @dc42 suggests? If so, could you post that code too, please? Unfortunately, I'm not much of a programmer! And if you don't mind, if I can get this working, I'll post it as a Pull Request so other people can compile a working MacOS version. Thanks! |
I spent some time yesterday trying to figure why programming on my MAC wouldn't work.. it kept returning early with this error:
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
andstty -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.The text was updated successfully, but these errors were encountered: