Harden boards.txt and platform.txt against IDE bug where programmer definition supplied with another core is used.

[devarishi7]

Hi,

I had some trouble uploading to an ATtiny2313, First time i tried this particular ATtiny. Sought help on the Arduino forum, and after verifying that it was not hardware related (managed upload with another core) Someone pointed at the board name being 'attiny2313a' was not being recognised, but 'attiny2313' Fiddled around with it a bit found a workaround and 2 solutions, but finally decided that it is the best if it would be modified in the cores boards.txt file. This is the link to the thread in Arduino forum : https://forum.arduino.cc/t/trouble-uploading-to-attiny-2313a/853510

[SpenceKonde]

Please post the first line from a verbose upload attempt that exhibits the problem - this is the line that shows the exact avrdude command invoked by the IDE. Because the avrdude.conf that I supply with the core has attiny2313 and attiny2313a (and no, you can't just change boards.txt to call it a non-a because that tells the compiler to treat it as a non-a too. But there are a couple of features that the A has and non-A does not. Which means some features aren't supported and some other things are defined differently IIRC I originally had it like that, but changed it because someone complained about the fact that I was compiling for their 2313a as if it was a 2313 and it wouldn't support some of the pcints or called a register something different (I think buried in Arduino.h is also a bunch of compatibility #defines to try to paper over some of that garbage.

I do not see this proiblem.

I strongly recommend avoiding the ATtiny x313 family. They have the second most issues reported out of all the parts this core supports, despite being probably the second least interesting part the core supports and accounting for only a small fraction of use of the core (that is, they are overrepresented in bug reports relative to their popularity) The flash and memory is microscopic, there is no ADC, they're ancient and so have idiosyncratic oddities, and to top it all off, they're not even particularly cheap! The modern tinies (stuff supported by megaTinyCore) are cheaper, with much better peripherals and larger memory, and the core is updated frequently.

[devarishi7]

I had that on the Arduino forum, but i understand you don't want to follow links, anyway C:\Users\deva_\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino18/bin/avrdude -CC:\Users\deva_\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino18/etc/avrdude.conf -v -V -pattiny2313a -cstk500v1 -PCOM3 -b19200 -Uflash:w:C:\Users\deva_\AppData\Local\Temp\arduino_build_345956/AlarmClock.ino.hex:i and looking through avrdude.conf the definition is actually missing. If you can provide me with the definitions like they should be in avrdude.conf i am totally happy with that. What i did first was remove the 'a' and send the avrdude command from the command line pointing to an exported binary, then i modified the avrdude.conf to recognize 2313a (with the settings of a 2313) Then i went into your boards.txt and decided that this would be the easiest fix. And in some way, if i chose the option for 2313(a) it doesn't let me chose between them, so that it is specified in your boards.txt is arbitrary. Sure mine is a 2313a, but if there is a difference i should be able to chose between them. I have 2 of them, and for the project i think i will manage with the small Flash & RAM, and from what i have lyting around i think it is the best fit for what i want to do. I want to use the UART, i can connect a crystal, and there are more pins than i'll need. The main reason for choosing an ATtiny for this project is that i want to build an alarm-clock that will keep running when mains power fails, for that i need something with lower power consumption, that can run of a LIPO.

[SpenceKonde]

Huh, how did you get it to use that avrdude.conf file? That's the one that comes with the AVRdude package the IDE includes. This is far from the only problem (which is why my core should never use it!)

I see things like: C:\arduino-1.8.13-portable\portable\packages\arduino\tools\avrdude\6.3.0-arduino18/bin/avrdude -CC:\arduino-1.8.13-portable\portable\packages\ATTinyCore\hardware\avr\1.5.0/avrdude.conf -v -pattiny2313a -cstk500v1 -PCOM11 -b19200 -Uflash:w:C:\Users\Spence\AppData\Local\Temp\arduino_build_579291/sketch_apr25a.ino.hex:i

[SpenceKonde]

I used to happily follow links to the arduino forum, but the update has made it incredibly unpleasant to use. I'd skimmed through it and missed that line.

[devarishi7]

I used to happily follow links to the arduino forum, but the update has made it incredibly unpleasant to use.

The improvements from the first few days have made it workable. I wonder if the people that implemented the change were really ready for a community like that one (sure they were ready for the complaints, they were expecting them, but still...)

Huh, how did you get it to use that avrdude.conf file? That's the one that comes with the AVRdude package the IDE includes.

Well yeah i dunno, i just hit 'upload using programmer' from inside the IDE just like i always do. Aren't i supposed to ? or eh, what is it i am supposed to do ? Actually your line looks very similar, other than that you are on v1.5.0 of your own library... ah now i see there is a avrdude.conf in the core as well. Well that changes things, On first sight i only noticed the difference in defined EEPROM size (128 vs 256) i wasn't planning to use that, but i do find it odd that you would describe both id's (t2313 & t2313a) as ATtiny2313a I understand that you are not really developing this core anymore, and i have something that works, but how should i be getting the IDE to use your avrdude.conf ?

[SpenceKonde]

Boom! Managed to reproduce/ You're getting tripped up by the stupid IDE bug, where you're using the non-ATTinyCore version of the Arduino as ISP. In Tools menu, you'll notice that no programmer is currently selected - in this case, it is pointed to a programmer defined by a different hardware package. Sometimes this errors out, but in cases like these, you get this kind of wacky half-working behavior. For uploads (but not burning bootloader) it uses the other hardware package's platform.txt to build the arguments passed to avrdude, including the path to the config file. It happens to me all the time as I switch between megaTinyCore and DxCore (they pass a ton of arguments alongside a updi upload - they set several fuses which vary by tools submenu options in order to support writing to the flash from within the app among other things.

Actually, there are probably ways I could make this break in a way that told you what to do.... If the error you saw was that avrdude did not recognize a part named "Select_Tools->Programmer", I think you'd have known what to do!

[SpenceKonde]

You get this sort of behavior whenever you select a programmer and then change to a board in another hardware package which passes different options to the programmer.

[devarishi7]

So If you are saying it's a bug in the IDE ?

In Tools menu, you'll notice that no programmer is currently selected

I always have 'Arduino as ISP' as selected programmer it's never empty.

If the error you saw was that avrdude did not recognize a part named "Select_Tools->Programmer", I think you'd have known what to do!

I would have been mistified just the same. Why now ? it works for the ATtiny13's i've used. Probably would have gone to the Arduino forum as well, and might have gotten the answer. Problem remains that i can't get the IDE to use your avrdude.conf file, but now that i know that it should use the info in that, i will copy that info into the IDE's avrdude.conf and restore your boards.txt or well what the hack, i might even add an entry in there to separate the 2313 from the 2313a, just to see how this works. I switch cores all the time, AVR-core ESP-core ATTiny core, Microcore etc and i can't really keep an eye on it. Mind you i am not so sure that the bug is that it selects the wrong avrdude.conf , but more that there are multiple versions of the avrdude.conf. In my opinion there probably really should be only one, or in that one a reference to others. Why would the avrdude.conf file that the IDE selects that is part of a different core, have information in there that belongs to another core (or at least appears to) But this is a different matter. Anyway welcome top the world of Java. When programming i found that using an interpreter has disadvantages and using a compiler has disadvantages, and Java is both !

[SpenceKonde]

(assuming it is in Arduino 1.8.13) After you change to a board within another core, you no longer have the programmer "selected". In this circumstance, The IDE has an invalid programmer selected (one not supplied with the same hardware package - the arduino team recently recognized - I think in 1.8.13 - what third party hardware package creators like myself have been saying for years: attempting to use a programmer definition from another hardware package was highly likely to malfunction - because it had to either ignore the instructions that the programmer definition came with, in favor of the ones that the board's package came with, or the other way around. This had forced every hardware package to include it['s own copy of all the programmers that worked with it, leading to an absurd proliferation of tools -> programmer options - each only guaranteed to work with the core it came with. Sometimes I had to remove cores just to keep the list from being so long it didn't fit on one screen.

So they made it so you could only select programmers that came with the board package as it should be. Unfortunately, while they hide what you had selected before, it is not entirely unselected - it will still get used for upload using programmer - despite that the developers clearly knew it wasn't a valid option. But this change did only go into the most recent version which... has been out for quite a while now.

Anyway, when it's in that state, it uses the "program" recipe (which is where the conf path is - and you have to allow for a core to be able to supply it's own avrdude.conf; what if they need to add a new programmer specific to those parts or fix some problem that's present in the official avrdude.conf? I mean, acer]] - they can't fix the official release.... so If I couldn't use mty own avrdude,conf,I'd have had no choice but tio but to copy avrdude, rename it, and tghen =scvrfe===iiiiiiiiiiiiiiiiiiiiiiiiiii from the platform.txt of the package the programmer you had selected is from, as well as the programmer definition, but everything else is, of the one corresponding to the currently selected board. The impact of this varies depending on what the differences in the program recipe are. Some of them have no differences from the stock core. On ATTinyCore, there aren't any other than the fact that we supply our own avrdude.conf because there were issues with the official one, and I've long since lost patience with the official Arduino folks regarding patches; I just try to never depend on them for anything nor force my users to do so.

My other two cores have my own toolchain package version too, after I got sick of my requests for updates falling on deaf ears. I wish I could just use an existing package, but they don't update it - Microchip has dropped like 4 ATPACK updates that added support for new parts since avr-gcc 7.3 Arduino7 came out.... (which only happened after I nagged and nagged and nagged to get the DA-series support) They don't seem to know how to build with support for the new parts, they've asked me how I do it! But I don't either; I have no clue how to compile it for anything other than x64 linux. I can't even work out how they wanted me to submit the corrections to code that gets used in creating the toolchain packages from when they were doing that last package for the Dx-series.... they talk about something called a patch file as if I'm supposed to know what that is or how to make one. But if I don't make it work, I can't support the parts I want to use myself, let along what I want other pleople to be able to use. Hence, a partial build that successfully generates the files needed to support the new parts from the ATPACKs and those files + that last arduino7 version gets the 4 'RE's: copy w/REplace onto last copy of the oficial toolchain, REname, REpackage, RElease.

Anyway - there is nothing I can do as a core author to cause the IDE to use the correct file without you selecting the same programmer you always use from the tools -> programmer submenu when you change board packages. See the attached image for demonstration of what the issue looks like, I wager you see exactly this behavior but don't realize because this is just the first time that the behavior with the wrong avrdude.conf file didn't work,

[devarishi7]

Well that does motivate me to update to 1.8.13, it's just somewhere in the back of my mind that there were reports of 'some issue' on the forum. Can't remember what it was. On a different note, and i mentioned it here a few posts back is that in your avrdude.conf the 2313(a) appears to have 256bytes as an EEPROM size, but the datasheet states that this is 128 (for both) As i said i am not going to use the eeprom in this project, but now i am not sure, what is it ? Anyway, let me once more express my appreciation for the work you've done and shared, and for the support you've provided. One of the reasons i never put any of my work online or make tutorials is that just to provide support for clients that use my stuff (for which i've built hardware) take up enough of my time as it is. Cheers !

[SpenceKonde]

Huh, I don't know of any issues specific to 1.8.13 - it definitely seems like the best version currently. Prior to Arduino 1.8.13, it was documented that you need to choose a programmer with (ATTinyCore) after the name or all bets were off. I think I got really excited about being able to remove that when 1.8.13 came out and forgot that there are still people using older versions.

Correction to the EEPROM size in avrdude,conf (and correction to to the instruction format for EEPROM read/write on 4313) will be in 2.0.0. Note that this has no impact on Arduino behavior - the upload process for AVR parts never reads or writes the EEPROM.

EEPROM? See https://github.com/SpenceKonde/ATTinyCore/blob/master/avr/libraries/EEPROM/README.md

[devarishi7]

Ok, Thanks again.