SpenceKonde
commented
2 years ago You sure this isn't just the bogus programmer bug that's been there for ages, and you getting thrown off by the order sensitivity of the phenomenon?
It is triggered as follows: Start with board from package A selected and valid programmer from package A selected. Select a board from package B.
Any attempt to upload that would use a programmer now is virtually certain to fail because it will use the boards.txt from package B with the platform.txt from package A and the programmer definition (which looks to be totally inappropriate).
This bugged state can be easily checked for by opening the tools menu and seeing if the name of a programmer is listed. (eg "Programmer" vs "Programmer "jtag2updi"). If no programmer name is listed, you are in the bugged state and uploads that would use a programmer will not work (unless they would work with the same platform.txt and programmers.txt - might be the case on many classic AVRs, but not the case on any modern AVRs, or almost anyting else). To rectify the problem, just select something from tools -> programmer. This must be repeated when changing between boards in different packages.
The IDE does a poor job of remembering which set of recent options you had selected when it starts up, for reasons I don't fully understand - I think it depends on how the IDE is opened (if you have two IDE windows open, but changing the board selection in one window effects the other window, those are the same process. If you have two IDE windows open, you can change the board selections independently, they are not the same process and whichever one you close last will usually be able to save it's settings (but if they're exited in very rapid succession, I've seen apparent violations of that ). How the IDE is opened determines whether the new file is handled by a new or existing arduino process.
The reason that this settings retention behavior sucks is that they are saving in one global preferences file per installation data that should instead be saved on a per-sketch basis. (ex, a "sketchname.config" or something in the sketch folder - since one arduino user may have many sketches each written for a different part from a different hardware package)
I think the combination of the blank programmer bug and settings being stored globally instead of per sketch is combining to produce confusing behavior that you are interpreting as a novel bug - rather than the less-bad bug that replaced the insane-programmer-list bug fixed by 1.8.13 in combination with the wacky behavior with two ways of opening a sketch having different results and sketch specific settings being stupidly saved globally. Evidence of the latter two bugs has been found scratched into the walls of caves by the first neandertal embedded software designers - they've been around basically for ever. In fact, a TON of programs will do odd stuff if you have multiple instances running and open them in a different order than you close them.. If you open as board with eaglecad, it wil lload the last board you were looking at, ask you if you want to load the schematic for that board, then immediately switch to the new board and ask you if you want to load the schematic for the new boards. I'm sure if you ponder that you can think of more examples.
The 1200bps touch is a signal sent over USB (not serial - it's the USB command to open a virtual COM port at that speed), and that is recognized by the Arduino Micro's USB handler (and maybe some other boards with native USB) as the signal to reset the microcontroller into the bootloader.I don't think it does a thing on the megaAVR boards, though I use my own boards, not the official nano everys because I disagree with almost every major design decision made about them.
cattledogGH
mcuee
There are two ways to open a .ino file.
1) With the IDE window open, you can use File>Open and the selected file will compile, link and upload correctly to a Nano Every using MegaCoreX 1.1.0.
2) With the IDE closed, you can double click on the .ino file and the Ide will open, show all the correct startup messages, and finally show the .ino file.
In case2 , the file compiles, links and the detailed verbose output messages all look the same as case 1 up to the point of upload. Indeed, you even see the message "Forcing reset using 1200bps open/close on port COMX" with the correct Com port shown.
Then instead of any averdude you messages you see "An error occurred while uploading the sketch"
I don't have a scope to see if the 1200bps is actually being sent.
Opening the IDE from a .ino files works successfully on a Nano Every with the megaAVR core, and for a Uno with the standard AVR core.
Any ideas as to what the issue is with megaCoreX 1.1.0, the Nano Every, and the process of opening the IDE by double clicking the file and then attempting to upload?