Closed RobertPatzke closed 2 years ago
Please try to launch bossac manualy in terminal window and give us feedback.
2017-12-26 22:38 GMT+01:00 Prof. Dr.-Ing. Robert Patzke < notifications@github.com>:
I could not imagine, that this is an error coming with the new version 4.2 on Linux/64bit, so I compared the switches of bossac with older versions, installed again everything, etc. etc. But after downloading simply version 4.1 it just works. My environment: LinuxMint, Cinnamon/64bit, latest version 18.3, on USB-Stick.
Here is the error message of 4.2: Starting upload using arduino loader Forcing reset using 1200bps open/close on port/dev/ttyACM0 Continuing to use/dev/ttyACM0 Ending reset
Launching .... /home/......./ bossac/1.6.1-arduino/bossac --port=ttyACM0 -U false -e -w -b ... /..../Release/XYZ.bin -R Output: no device found on /dev/ttyACM0 bossac finished upload done
The reset before with 1200 bit/s worked, the old program was cleared, but the new program was not downloaded.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Sloeber/arduino-eclipse-plugin/issues/892, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHOU8ufSO42m-nDtBf-rRfoY3Sxk3Ofks5tEWc9gaJpZM4RNBS1 .
I should have done this, when I tested the download and before I deleted 4.2 and installed 4.1. Sorry for missing it. But currently I have higher priority in preparing software for my students, now based on version 4.1. I will come back to that issue later. Thanks for reading.
Sure. Good luck with your lectures.
I can confirm that what Robert says is correct with version 4.2. With version 4.1, upload to DUE worked fine. With version 4.2 the error is exactly how Robert states. I compared the platform.txt files between 4.1 and 4.2 and they look the same for DUE.
The only way I can now upload to DUE is to run bossac manually without the -port option as follows:
$ ./bossac -U false -e -w -b -R /home/dev/workspace_arduino/mycode/Release/main.bin
This problem occurs with either upgraded 4.1 to 4.2 and fresh 4.2 package.
When I do try to upload to DUE, it will do the initial erase of the connected board, but that is where it stops with the error as stated in Robert's first post.
I first noticed this problem some time ago, but continued to version 4.1. Now my 4.1 has been upgrade to 4.2.
System is GNU/Linux Mint LMDE.
Why was this close? I'm facing the same issue
With Sloeber from bundle, Linux x64
Why was this close? I'm facing the same issue
I guess because op didn't answer the question whether it worked from command line and stated he would continue using 4.1
Should I reopen it? To workaround it I've change the platform.txt but eclipse is still taking the same option. I think I'm not modifying the well document.
When I create a new project, changes are being taken... I guess it may copy them from the platform.txt when project creation.
I confirm that removing --port={serial.port.file}
from tools.bossac.upload.pattern
in used platform.txt file, works. This is using the programming port.
As for the native port, all work out of the box, with the exception that Sloeber says Serial port /dev/ttyACM0 not found. Did you select the right one from the project properties -> Arduino -> Arduino? Port name - /dev/ttyACM0; Method name - openPort(); Exception type - Port not found.
when programming finishes. I guess that is looking for the port (it just used to flash) but the reset after flashing has enumerated the USB port different and that' s why it fails.
Sorry, I had forgotten this issue. Meanwhile I solved the problem with the help of a colleague. The error is not with the bossac itself, but with the automatic download of bossac when using arduino environment for DUE. It seems, that in Sloeber 4.3 an old version of bossac is installed (but I have no chance to check that, my know-how is to low to understand the update-environment of Sloeber.). What I did is as follows: From the error message in Sloeber 4.3 I found the location of bossac on my computer. I downloaded bossac (the latest Linux-version) here from github and replaced the bossac in Sloeber 4.3 (Arduino tools path) with this github version. And it works !!! Good luck for You Robert
I have just looked to bossac here at github and I do not remeber, which version I used to overwrite the bossac from Sloeber 4.3. I think it is this https://github.com/shumatech/BOSSA/releases/tag/1.6.1-arduino But it seems to be the older version. May be this is the correct one https://github.com/shumatech/BOSSA/releases/download/1.7.0/bossac-1.7.0-x86_64-linux-gnu.tar.gz Just try (I do not have time because I have to prepare my lectures for online teaching because of Corona) and tell Jantje what You find out.
From your original post I can see bossac 1.6.1-arduino is used. According to the packages.index that is the version that should be used
I see in the package.index file that there are multiple linux versions and I doubth Sloeber takes al subtilities into account
"name": "bossac",
"version": "1.6.1-arduino",
"systems": [
{
"host": "arm-linux-gnueabihf",
"url": "http://downloads.arduino.cc/bossac-1.6.1-arduino-arm-linux-gnueabihf.tar.bz2",
"archiveFileName": "bossac-1.6.1-arduino-arm-linux-gnueabihf.tar.bz2",
"checksum": "SHA-256:8c4e63db982178919c824e7a35580dffc95c3426afa7285de3eb583982d4d391",
"size": "201341"
},
{
"host": "i686-mingw32",
"url": "http://downloads.arduino.cc/bossac-1.6.1-arduino-mingw32.tar.gz",
"archiveFileName": "bossac-1.6.1-arduino-mingw32.tar.gz",
"checksum": "SHA-256:d59f43e2e83a337d04c4ae88b195a4ee175b8d87fff4c43144d23412a4a9513b",
"size": "222918"
},
{
"host": "x86_64-apple-darwin",
"url": "http://downloads.arduino.cc/bossac-1.6.1-arduino-i386-apple-darwin14.5.0.tar.gz",
"archiveFileName": "bossac-1.6.1-arduino-i386-apple-darwin14.5.0.tar.gz",
"checksum": "SHA-256:2f80ef569a3fb19da60ab3489e49d8fe7d4699876acf30ff4938c632230a09aa",
"size": "64587"
},
{
"host": "x86_64-pc-linux-gnu",
"url": "http://downloads.arduino.cc/bossac-1.6.1-arduino-x86_64-linux-gnu.tar.gz",
"archiveFileName": "bossac-1.6.1-arduino-x86_64-linux-gnu.tar.gz",
"checksum": "SHA-256:b78afc66c00ccfdd69a08bd3959c260a0c64ccce78a71d5a1135ae4437ff40db",
"size": "30869"
},
{
"host": "i686-pc-linux-gnu",
"url": "http://downloads.arduino.cc/bossac-1.6.1-arduino-i486-linux-gnu.tar.gz",
"archiveFileName": "bossac-1.6.1-arduino-i486-linux-gnu.tar.gz",
"checksum": "SHA-256:1e211347569d75193b337296a10dd25b0ce04419e3d7dc644355178b6b514f92",
"size": "30320"
}
]
Can you check your [sloeber install]/arduinoPlugin/downloads folder to see which bossac 1.6.1-arduino file has been downloaded and check whether you think this is the correct one?
Hi, the Bossac used on my pc is 1.6.1, I did the modification on platform.txt file and after a new project creation is working fine
@javierfileiv Where is that file platform.txt? I did not find it.
@jantje If I use a fresh installation of Sloeber (4.3), it is bossac version 1.6.1 in path ...arduinoPlugin/packages/arduino/tools/bossac/1.6.1-arduino/ and it is not programming the DUE but creating the error message described in my start comment. So I simply overwrite the bossac in that folder by the latest Linux-version of github/shumatech, which is version 1.7.0, and everything is fine. The command line help starts with Basic Open Source SAM-BA Application (BOSSA) Version 1.7.0 Flash programmer for Atmel SAM devices. Copyright (c) 2011-2012 ShumaTech (http://www.shumatech.com)
Another hint that version 1.6.1 produces the error on Linux is as follows: Some of my students are very eager to use PlatformIO with VisualStudioCode instead of Sloeber. The main reason is, that the debugging with Segger/JTAG works at once (on Windows). I was not able to get that running with Sloeber 4.3 (4.2 works on Windows, the tests on Linux are the next steps). So far, I tested PlatformIO and VSC on Linux and I get the same error as with Sloeber 4.2/4.3: The download to DUE does not work. But I was not able to fix the problem by overwriting the bossac, because in PlatformIO everything is somehow hidden behind the Python environment and overwriting the bossac, which I found by searching, did not work. So the usage of PlatformIO is not possible for me on Linux and I will continue to use Sloeber. Even, if the problems with DUE-programmig will be solved on PIO, I will stay on using Sloeber, because the environment is much more transparent and I (so far) know, what I am doing (in the borders of my small know-how).
@RobertPatzke you have to find where your Sloeber take the android config from.
In my case you can find it in $HOME/.arduino15/packages/arduino/hardware/sam/1.6.12/
Otherwise you can find ~ -name platform.txt
and check where it is located :) (remember to recreate a new project to pick the new changes )
for platformio search for your tool in ~/. platformio
folder
Easiest way to find the platform.txt is in sloeber goto you project->core->variant->right click->select open in system explorer. Goto the parent folder Note that to have your saved platform.txt changes to be taken into account you need to open the project properties->arduino->apply and close
@RobertPatzke is your system a amd system? I don't think so because I would expect you to get an error if you are running amd. Just asking to be sure.
Based on the arduino provided package_index.json file a intel 64 bit linux should use this bosac from this file:
http://downloads.arduino.cc/bossac-1.6.1-arduino-x86_64-linux-gnu.tar.gz
Can you check whether this one works for you?
@RobertPatzke Thinking about this. Do you use 64 bit Sloeber 4.1 ? I'm asking because I really do not see any differences that can explain the different behaviour between 4.1 and 4.3 that you report I assume a 32 bit Sloeber would install the 32 bit package http://downloads.arduino.cc/bossac-1.6.1-arduino-i486-linux-gnu.tar.gz which should run fine when 32 bit Sloeber is running fine.
Hello jantje, thank You for taking care. I just tested again with the known results.
After replacing the bossac by that of Your link, it is the same behaviour. !!!! But After replacing the bossac by that of github/shumatech Version 1.7.0 everything is OK, without any other change. The same on both PCs. So far I am happy with this. The only problem is, not to forget to replace bossac 1.6.1 by bossac 1.7.0 when I make a new installation (in case of an update). Stay healthy Robert
I have recently setup a intel i5 with ubuntu for my build tests. I'll try to do the upload test on that machine. But I first need to do my upload tests on windows and the build tests on Linux. That will take a couple of days.
A question though: Does it work with arduino IDE? If it doesn't work there It won't work in Sloeber. Sometimes the arduino IDE does installation stuff that enables things (like setting udev rules). When I setup the arduino IDE in Linux I noticed a install script.
@jantje indeed there is such script but you can launch it manually with sudo
Yes, I just installed Arduino 1.8.12 and after loading additional DUE software it runs (programs the board). But I cannot see relevant information on the screen, so I do not know, whether they might use other command line parameters for bossac or so. And I cannot find the bossac, I do not know, where Arduino stores the additional software, I can only see the AVR environment. If I could find their bossac, I would replace that of Sloeber and see what happens.
In arduino preferences you can turn on verbose upload This will tell you the command and as sutch the bosac location
After doing lots of research there are 2 stable results.
Somehow strange with bossac 1.6.1 Yesterday afternoon everything seemed to be working with the Arduino IDE. But after starting the PC this morning and testing Arduino IDE first (after switching console error messages ON), there was the same error as with Sloeber. Then closing AIDE and starting Sloeber to check the command parameters: get the same error. But after this, closing Sloeber and starting AIDE again, the error at AIDE vanished. Though the information about the bossac's is the same with AIDE and Sloeber, I copied the bossac from AIDE to Sloeber. Now I have identical bossac's with both. And .... AIDE running stable, Sloeber does not. I made many switches between AIDE and Sloeber, closing the one, opening the other. Looks like a too early time-out with Sloeber, because the error message comes at once. May be AIDE makes another try and the second try works or something like that.
Very stable with bossac 1.7.0 I tried to create an error with bossac 1.7.0 and Sloeber (just replaced the bossac 1.6.1 in path ... Tools ... with 1.7.0). So I changed the USB-port, started again the PC, etc. , but bossac 1.7.0 never gave an error with Sloeber. So there is something new with 1.7.0 which provides a better handling.
Seems like a timing issue indeed. I have done some research and it seems there is due R3 and DUE R3-E models. The DUE R3 has the upload issue and the DUE R3-E seems to have fixed it. I guess the bossac 1.7.0 has a software fix for Due R3. To know the difference between DUE R3 and DUE R3-E you need to look at the components. The R3 looks like this Where the R3-E looks like There are some very long threats on this on the arduino forum like https://forum.arduino.cc/index.php?topic=256771.0 I didn't get to the end of the threads but someone proposes soldering a resistor and many people confirmed this works. https://forum.arduino.cc/index.php?topic=256771.msg2512504#msg2512504
I have a R3. It would be nice to know what you have and whether you have the upload problem.
I can confirm, that replacing the bossac
1.6.1-arduino
that ships with Sloeber V4.3.3 with bossac
1.7.0
from the shumatech github page (https://github.com/shumatech/BOSSA/releases) seems to solve the problem with my Arduino DUE R3 board.
Too bad that the business of downloading/extracting/finding the right destination/replacing the bossac
is a little too involved. I would appreciate it if Sloeber downloaded the 1.7.0 automatically by itself.
Thanks for the confirmation of the Arduino DUE R3 board.
I would appreciate it if Sloeber downloaded the 1.7.0 automatically by itself.
It is the Arduino json file maintained and supported by Arduino itself that defines the tools to be used. It is not up to Sloeber to modify that.
Best way forward is to convince Arduino to upgrade the bosac used in the json
I have found some issues in Sloeber in regards to opening and closing the port (to reset the board) that may be part of the problem here. So Sloeber V4.4 may be better behaved. The json file still references bosac 1.6.1
I tried today with the nightly on linux and upload worked as should. So I close this issue. You may need the nightly though.
I could not imagine, that this is an error coming with the new version 4.2 on Linux/64bit, so I compared the switches of bossac with older versions, installed again everything, etc. etc. But after downloading simply version 4.1 it just works. My environment: LinuxMint, Cinnamon/64bit, latest version 18.3, on USB-Stick.
Here is the error message of 4.2: Starting upload using arduino loader Forcing reset using 1200bps open/close on port/dev/ttyACM0 Continuing to use/dev/ttyACM0 Ending reset
Launching .... /home/......./ bossac/1.6.1-arduino/bossac --port=ttyACM0 -U false -e -w -b ... /..../Release/XYZ.bin -R Output: no device found on /dev/ttyACM0 bossac finished upload done
The reset before with 1200 bit/s worked, the old program was cleared, but the new program was not downloaded.