`specs-avr128db28` missing?

[Floessie]

Hi DrAzzy,

I've just got some t1614 and AVR128DB28 from Microchip direct. I smoothly got started with the t1614, but now I've got a problem with the AVR-DB using DxCore. Whenever I try to compile, I get this:

avr-g++: error: device-specs/specs-avr128db28: No such file or directory

I've got IDE 1.8.13 and DxCore 1.2.0. Do I need to update the Arduino toolchain?

Thanks, Flössie

[SpenceKonde]

Use board manager to install 1.2.0a - note that if you are on Linux, the x bit on the permissions of the executables get lost by the installer (but not when the archive is unpacked normally). I do not understand why - but that's why there are two versions of the core, one with the new toolchain that I dont know how to make work on Linux, and the other that doesn't pull in new toolchain, but doesn't work on the db parts.

I have been trying to get the Arduino team to do a build, since their builds work - the arduino toolchain is far behind https://github.com/arduino/toolchain-avr/issues/70

[Floessie]

Thanks for the tip! Just one more question: Where do I find the archive? It's a bit tedious to find all related binaries and chmod them...

[SpenceKonde]

Install through board manager, attempt compile, it will error, error (at least with verbose compile) shows you where the bad file is; I think there are a couple of directories full of executables, you set everything there +x. Retry, it'll be something in the next directory... I think it's only 2 or 3 directories of executables? Or, you could download the tarball for your architecture from the json file, extract it manually and copy it over the stock 1.8.13 toolchain.... Actually, you don't even have to copy the executables; what's incredibly frustrating is that I haven't even changed the executables, those are the same unchanged arduino7 ones, but for some reason, when the board manager but not someone doing it manually) extracts it, they aren't executable... and I don't have a linux system to test it on soooo yeah.

[SpenceKonde]

Honestly, I wonder if someone more artfully molested the archives on a linux system, they could generate tarballs that work - but I don't really have a good system for this, and there are a lot of more interesting things to work on... I would really rather not also have to be the one who updates the toolchain, in addition to maintaining three cores designing breakout boards and doing all the other stuff related to supporting them...

[SpenceKonde]

Depending on platform

https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azzy1-x86_64-pc-linux-gnu.tar.bz2

https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azzy1-i686-pc-linux-gnu.tar.bz2

https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azzy1-aarch64-pc-linux-gnu.tar.bz2

https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azzy1-arm-linux-gnueabihf.tar.bz2

[Floessie]

Thanks again, Spence. Those links are exactly what I was looking for. I guess the IDE sets an umask preventing anything extracted to become executable. And I'm hoping with you that arduino/toolchain-avr#70 gets solved soon.

I'll try your toolchain tomorrow. :+1:

[Floessie]

Hm, in your toolchain tarball every file is rwx, which is the other extreme. So I'll do the chmod dance with the files obtained via the board manager.

[Floessie]

@SpenceKonde I just wanted to let you know, that I got the DB running with your chmodded 1.2.0-a and ElTangas jtag2updi. As with the t1614 I didn't manage to upload anything with your jtag2updi fork on an Arduino Nano. It just blinks the builtin LED but won't sync. Nevertheless, I am completely content with the current situation. :+1: