Duet 2 Wifi - bossa "No device found"
I just received a Duet 2 Wifi V1.04 Clone that only registers as an Atmel BOSSA Device (vendor 0x03eb product 0x6124) upon connecting via USB, but bossa won't connect to it whatever I tried.
I've tried bossac 1.7.0 (which still is the current version in FreeBSD packages and ports) and also compiled the current bossac 1.9.1 but both versions always fail with "No device found on cuaU0".
I've tried several combinations of erase & reset or just one or the other, as well as re-plugging it after the erase. I even tried using the ttyU0 device, setting the baudrate to different speeds via stty but I never got bossac/bossash to connect to the processor but wasted the better part of the day with bossa...
I CAN connect to the serial terminal e.g. via cu or screen (although there is no output), and I get disconnected when I reset the duet, so the device is there, but bossa ignores or doesn't recognize it.
As far as I could see in the "documentation" (or better say the sorry excuse for the non-existent manpage you get with --help) there is no "force" option for bossa to skip any probing and just do what I told it to...
From the many results when doing a search for this issue, bossa also seems to be quite buggy and even randomly connects on 1 out of 10 tries for some folks. Rather than wasting even more hours on an hopelessly unreliable piece of software, I'd rather try another (more reliable) variant, but as there is no SAM-BA available for UNIX but only for Linux and Windows and I exclusively have UNIX machines (FreeBSD, OpenBSD and illumos) running, I'm pretty much stuck now....
Are there any other options to flash the firmware? (e.g. SPI?)
I did some development with Atmel AVR Tiny and smaller ATMega processors and still have several SPI and a Diamex ISP/TPI/PDI Programmer lying around. Is it possible to flash the SAM4 via the JTAG interface? (I vaguely remember this was possible with some chipsets...)
(vendor 0x03eb product 0x6124)
vid 03eb pid 6124 is the correct usb id, so you may just have to specify which port to use?
alternatively it could be a mac issue and iirc someone posted newer binary here recently, could be worth trying search for it.
I don't use a mac, I've tried it on FreeBSD 12.1 and 11.3 with bossa 1.7 and 1.9.1 (current version from github) with identical results...
% bossac -d -i -pcuaU0 Set binary mode Send auto-baud Set binary mode No device found on cuaU0 % bossac -d -i -p/dev/cuaU0 Set binary mode Send auto-baud Set binary mode No device found on /dev/cuaU0 % bossac -d -i -pttyU0 Set binary mode Send auto-baud Set binary mode No device found on ttyU0 % bossac -d -i -p/dev/ttyU0 Set binary mode Send auto-baud Set binary mode No device found on /dev/ttyU0
cuaU0 is the correct device (and ttyU0 the matching terminal) and I can open connections to both without any error. It seems bossa is doing some "intelligent" probing, which fails and prevents any further operations...
On 1.04a and later the JTAG header is removed
if you have a later revision maybe virtuailizing linux or something is simpler?
It's a Version 1.04 board and the header isn't populated and 3 resistors next to it are missing, but the vias are there, so I could still use some e-z probes / SMD grabbers to connect or solder in the header...
As a last resort or to circumvent having to use the unreliable bossa-path I still wouldn't dismiss the JTAG variant IF it allows firmware flashing.
With virtualization there's the problem that USB-passthrough especially for low-level stuff is rather unreliable. So on top of a buggy software (bossa) I also add several layers of possible breakage.
If I can't find another solution, I might try to find a windows pc at work next week to try if it works there. But from what I saw here in the forums and elsewhere, with windows it's already uncertain if the serial connection will work...
I finally managed to also build bossac 1.8 . It seems to properly connect, but it fails with "SAM-BA operation failed"...
a few people have had to install drivers on windows, very few people have had issues with bossa on windows. most issues have been on macs. at least one mac user had success with virtualization. most of the issues have been with the sam7 on the Duet3 and some timing bug it seems.
anyways, i've bookmarked this but not tried it yet https://www.omzlo.com/articles/programming-samd21-using-atmel-ice-with-openocd atsam4e8e looks to suppord debug wire as well
I managed to borrow a Laptop with Windows 7, but I'm getting the typical Windows-experience:
bossa 1.9.1 can't connect
bossa 1.8 segfaults when connecting
sam-ba 3.3.1 won't even start
sam-ba 2.18 dies when connecting with an error in TCL_Open
Should the Diag-LED turn off at any point when the erase-Jumper is set? The Diag-LED on this board has been always constantly lit, no matter what I did (erase/reset).
I tried another Win7 PC at work today.
Bossa still wouldn't connect in any version (1.7, 1.8, 1.9.1), so I installed Atmel Studio and finally was able to connect to the board and flash the current Firmware!
Being curious I erased the flash again, bossa again wasn't able to connect, but SAM-BA can now connect and flash the firmware.
Don't know why the board was locked up, but it seems Atmel Studio (which should use plain SAM-BA in the background as far as I understand!?) fixed it and now its working again.
Thanks for the help @bearer , I'll keep the link about JTAG programming in my bookmarks in case I should need it in the future...
but I'm getting the typical Windows-experience
lol, yeah I hate when things works as well;)
not a common problem having problems across operating systems; out of curiosity could you share a close up picture of the atmel chip and elaborate on the source? (not sure how kosher it is to share links to clones, but a nod in the general direction should be okay i hope)
The chip seems to be genuine (Atmel ATSAM4E8E) and the board comes from one of the 'bigger' manufacturers in the MAKER community... (The PCB is black BTW...).