Changes for Optiboot_x bootloader support...

[WestfW]

Discussion of changes to support the new Optiboot_x bootloader. (actually happening over here: https://github.com/WestfW/MegaCoreX ) Based on experience with the megaTinyCore, the intent is to add an additional "bootloader" menu item with choices "none" and "optiboot_x", with the following behaviors:

"none", "Burn Bootloader" - programs fuses only (no bootloader.) "none", "Upload" - same as "upload using programmer" (note1) "none", "Upload using Programmer" - upload sketch at 0x0 and set all fuses. "optiboot_x", "Burn Bootloader" - upload optiboot_x using programer, set fuses for bootloader use. "optiboot_x", "Upload" - Use -carduino to upload sketch only (at 0x200), using bootloader "optiboot_x", "Upload using Programmer" - ?? (note 2)

note1: is this what we want? I feel like it might be useful to have an "uploaded using the programmer", but don't touch the fuses" that could go here.

note2: I'm not sure what should happen for "upload using programmer: should do if the bootloader support is set to "optiboot_x"

[WestfW]

Does anyone else have an ATmega4809 Xplained Pro? I put Optiboot_x on mine, and it fails in mysterious ways (small stk500 commands work fine. "read" works fine. "program" hangs - apparently somehow losing 4 bytes from the first page that avrdude transmits to the Arduino.) The same bootloader works fine on my Curiosity and home-made boards. (though those do use different UART pins...)

[MCUdude]

Sadly, I don't. And I can't really justify buying one. However, if someone (Microchip) would like to donate one, I'd accept the donation 😉.

Is there a good reason to why you've added -P{serial.port} -b{upload.speed} to tools.avrdude.bootloader and tools.avrdude.program? These parameters are usually passed through {program.extra_params}.

"none", "Burn Bootloader" - programs fuses only (no bootloader.) "none", "Upload" - same as "upload using programmer" (note1) "none", "Upload using Programmer" - upload sketch at 0x0 and set all fuses. "optiboot_x", "Burn Bootloader" - upload optiboot_x using programer, set fuses for bootloader use. "optiboot_x", "Upload" - Use -carduino to upload sketch only (at 0x200), using bootloader "optiboot_x", "Upload using Programmer" - ?? (note 2)

I agree. For the "optiboot_x", "Upload using Programmer" option, is there any way this can be done without erasing the bootloader?

BTW do you know if the ATmega808/809..3208/3209 are binary compatible, so that we only need a few pre-compiled binaries to cover all targets?

[WestfW]

Is there a good reason to why you've added -P{serial.port} -b{upload.speed} to tools.avrdude.bootloader and tools.avrdude.program? These parameters are usually passed through {program.extra_params}.

Huh. I didn't know. The -b{upload.speed} was already in the "upload" recipe, so the initial attempt had a speed but no port...

For the "optiboot_x", "Upload using Programmer" option, is there any way this can be done without erasing the bootloader?

Hmm. I don't know. It will depend on whether the programmer being used does page erases before programming. (I believe that's possible, but I don't know if/when it's done.)

do you know if the ATmega808/809..3208/3209 are binary compatible, so that we only need a few pre-compiled binaries to cover all targets?

I believe that they are binary compatible. The xTiny chips were astoundingly compatible across multiple sub-families, and they're more diverse that the current Mega line. We'll need different binaries for the different UART possibilities, though.

[WestfW]

My mysterious Xplained Pro problems seem to only happen when trying to use it from my Mac :-(

[mraardvark]

You could try setting the EDBG in "strict" mode when using it on the Mac. To find out what mode you are in: atprogram.exe -t edbg parameters --get-ep-size and to change to "strict mode": atprogram.exe -t edbg parameters --set-ep-size strict Might be worth a try. It helps on Linux systems in some cases...

[MCUdude]

For the "optiboot_x", "Upload using Programmer" option, is there any way this can be done without erasing the bootloader?

Hmm. I don't know. It will depend on whether the programmer being used does page erases before programming. (I believe that's possible, but I don't know if/when it's done.)

We can perhaps figure this out later. For me it's ok if it behaves the same way as current Arduinos do; the bootloader gets erased but the fuse bit values stay.

I believe that they are binary compatible. The xTiny chips were astoundingly compatible across multiple sub-families, and they're more diverse that the current Mega line. We'll need different binaries for the different UART possibilities, though.

Yes, we need multiple binaries, maybe one for each hardware UART + pin swap; a total of 8 binaries? How does the bootloader "leave" the LED pin? I'd prefer not to have additional binaries for boards that have an inverted LED configuration, such as the curiosity nano. If we have two or more blinks, and the GPIO goes high-Z when leaving the bootloader, I think it's OK to use the same binary for inverting and non-inverting configurations.

[WestfW]

atprogram.exe -t edbg parameters --set-ep-size strict

Yes, that worked! (Where did you find that? A preliminary search to see what it was going to do showed up practically nothing, including "to see the atprogam documentation, run it on your system with the -help option" in microchip's online docs.)

And to check my understanding... This SHOULDN'T be necessary, right? A USB host ought to be sending messages that match the endpoint size that was negotiated during enumeration...

Do I have to switch back for HID (normal programmer use)?

C:\Users\billw\Documents>atprogram -t EDBG parameters --get-ep-size
Firmware check OK
MODE: default
  Default settings are 512 byte for HID and 64 byte for CDC.
  Strict mode uses 64 byte for HID and 512 byte for CDC
  Minimal mode uses 64 byte for both HID and CDC.

C:\Users\billw\Documents>atprogram.exe -t edbg parameters --set-ep-size strict
Firmware check OK
OK

C:\Users\billw\Documents>atprogram -t EDBG parameters --get-ep-size
Firmware check OK
MODE: strict
  Default settings are 512 byte for HID and 64 byte for CDC.
  Strict mode uses 64 byte for HID and 512 byte for CDC
  Minimal mode uses 64 byte for both HID and CDC.

[WestfW]

How does the bootloader "leave" the LED pin? [if] the GPIO goes high-Z when leaving the bootloader

All of the "exit" paths of the bootloader should be via a full WDT-based RESET, so the LED pin will end up Hi-Z regardless. (In fact, I sort-of like the "LED_START_ON" feature where the bootloader just turns it on and leaves it on until exit, becasue I can tell when it LEAVES the bootloader as well. But that's a rather bootloader-centric view of the world, I think.)

[WestfW]

Is there a way anyone knows about to specify a "pre-upload" recipe? AFAIK, the Atmel Dev boards don't do the "DTR/Reset" hacks, and it would be nice to have a separate program trigger the reset via the programmer, even when using the bootloader to upload.

[mraardvark]

atprogram.exe -t edbg parameters --set-ep-size strict

Yes, that worked! (Where did you find that? A preliminary search to see what it was going to do showed up practically nothing, including "to see the atprogam documentation, run it on your system with the -help option" in microchip's online docs.)

I think the only trace is in the PDF user guides' firmware revision history as "Made USB endpoint size configurable".

Apparently (I have no source to quote here) bulk endpoints (like CDC) on USB HS devices must use the 512b endpoint-size. Some OS's are more strict (read: OSX and Linux) on this than others...

The "parameters" function of atprogram has all sort of non-target-related functions - it is also useful for setting the Vout on PowerDebugger or board voltage on Curiosity Nanos...

atprogram.exe help parameters

[WestfW]

Is there a good reason to why you've added -P{serial.port} -b{upload.speed} to tools.avrdude.bootloader and tools.avrdude.program? These parameters are usually passed through {program.extra_params}.

Huh. I didn't know. The -b{upload.speed} was already in the "upload" recipe, so the initial attempt had a speed but no port...

Ah, I think I see. upload.speed normally comes from boards.txt and is in the upload rule, but -P{serial.port} usually comes from programmmers.txt so that either serial or USB can be selected based on the particular programmer.

[MCUdude]

I have a local MegaCoreX "bootloader branch" where optiboot works well on all UARTs. I'm thinking about changing the default LED pin (bootloader LED and LED_BUILTIN) to PA7, because all chips have this pin, and PA7 is always Arduino pin 7 (except on the UNO Wifi).

[WestfW]

Seems pretty reasonable. I like the "all chips have the pin" argument. "It's always pin7" is a lot weaker (Not Xplained, not Curiosity, not AVR-IoT wg, not Nano Every...) (OTOH, I'm wondering whether there is a serious use case for a bootloader on any of the platforms with built-in programmers, anyway.)

What do you think about having LED_BUILTIN (and maybe some more of the meta-names) be defined on the compile command-line instead of a variants file? That way, you could use the same variant files and still get some customization via boards.txt instead. LED_BUILTIN is probably the most commonly used symbol that isn't at least partially fixed by the hardware...

[WestfW]

Re: programmers.txt... Sigh. So one way of handling the desire for different fuses, depending on whether we're using the bootloader or not, is to use a new 'tool.' In platform.txt: tools.avrdude_opti.bootloader.pattern="{cmd.path}" "-C{config.path}" {bootloader.verbose} -p{build.mcu} -c{protocol} -P{serial.port} -b{upload.speed} -e {program.extra_params} {bootloader.fuse8} {bootloader.lock} And in boards.txt: 4809.menu.bootmenu.optiboot.bootloader.tool=avrdude_opti

This looks like it works fine for ".bootloader.tool" and ".upload.tool", but ".program.tool" gets overridden by the values in programmers.txt :-(

(This also probably means that "burn bootloader" is probably broken on pretty much ALL platforms, if they ever needed to use a different tool for different boards :-( Fortunately (?), all existing AVR boards always use avrdude, and all ARM platforms use openocd...)

[MCUdude]

I don't really understand the problem. For me, f9e4090 works just fine.

[MCUdude]

• Burn bootloader

  • Erase the flash memory and sets the fuses
  • Then upload the correct Optiboot hex file

• Upload using programmer

  • Uploads the user program hex file and sets the fuses

• "Regular" upload

  • Uses -carduino to upload

[tgtakaoka]

I tried https://github.com/MCUdude/MegaCoreX/commit/f9e4090bdc6cea93367c039701bce6ebc0cfeb7a with ATmega4809P/UART1 alternate pin from Arduino IDE, and it works fine! Great work and thanks a lot!

[tgtakaoka]

But I have no luck on ATmega4808-28pin/UART0 both default and alternate pin. Note that MegaCoreX and microUPDI works fine with no bootloader on the same chip.

/home/t2/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17/bin/avrdude -C/home/t2/Arduino/hardware/MegaCoreX/megaavr/avrdude.conf -v -patmega4808 -carduino -P/dev/ttyACM0 -b115200 -D -Uflash:w:/tmp/arduino_build_969532/Blink.ino.hex:i

avrdude: Version 6.3-20190619 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch

     System wide configuration file is "/home/t2/Arduino/hardware/MegaCoreX/megaavr/avrdude.conf"
     User configuration file is "/home/t2/.avrduderc"
     User configuration file does not exist or is not a regular file, skipping

     Using Port                    : /dev/ttyACM0
     Using Programmer              : arduino
     Overriding Baud Rate          : 115200

avrdude: stk500_getsync(): can't communicate with device: resp=0xfc

avrdude done. Thank you.

An error occurred while uploading the sketch

[MCUdude]

That is strange. I don't have a 28-pin ATmega4808, but I do have an ATmega4808 in a 32-pin package. I'm able to upload using UART0 default and UART0 alternative without any issues or errors. Are you 100% sure you have connected your USB to serial adapter to the right IO pins?

Are you able to print to the serial monitor using UART0 default and UART0 alternative?

[tgtakaoka]

I confirmed that ATmega4808/28-pin UART0-default and UART0-alternative work fine with Arduino IDE's File>Examples>Communication>ASCIITable and no bootloader. No idea...

[tgtakaoka]

Hmm, even on ATmega4809P, other clock settings than "Internal 16MHz" seems not working.

[can't upload sketch via optiboot]

• ATmegq4808-28pin, 16MHz, UART0-default
• ATmega4808-28pin, 16MHz, UART0-alternative
• ATmega4809-40pin, 20MHz, UART1-alternative

[can upload sketch via optiboot]

• ATmega4809-40pin, 16MHz, UART1-alternative

[MCUdude]

I've just tested all serial ports on the ATmega4809, both default and alternative pin positions.

At first, I also experienced the issues you describe, but then I realized, I might have to power-cycle the board for the registers to clear itself. And it turned out that that was the solution.

DID NOT WORK: Burn UART3 default bootloader -> upload blink sketch -> Burn UART3 alternative bootloader -> re-wire RX/TX lines -> cannot upload anything.

DID WORK: Burn UART3 default bootloader -> upload blink sketch -> Burn UART3 alternative bootloader -> re-wire RX/TX lines -> power cycle board -> can now upload.

[WestfW]

I might have to power-cycle the board for the registers to clear itself.

Does the UPDI programming not end with chip reset? Because the datasheet definitely says that the pinmux registers are supposed to be cleared on reset (the only things that requires a power-cycle that I've found is returning the UPDI pin to a non-UPDI function after HC activation, which doesn't apply to the mega0 chips.) If the UPDI programming ens with just a "disable UPDI", that could conceivably continue the CPU at the prior PC; that could run the bootloader (eventually), but not set the pinmux (but only for the case where it WAS using the alternative pin, and needed to switch to non-alternative?) I can change the code to always set/clear the pinmux...

Edit: I check the jtag2updi code, and it DOES do (or at least attempt) a chip reset when it gets a "leave programming mode" command. And avrdude DOES say that it sends a "leave progmode" command...

[MCUdude]

Other times, it didn't work if I used an optiboot file where the alternative pins were used, and I loaded a file that uses de default position.

I cannot be sure, but it seems like the UPDI communication just ends without a hardware reset. Would be great if I could try to compile some new files where the pinmux is always set/cleared.

[WestfW]

I did commit changes to Optiboot tonight, that always sets the PMUX register...

[MCUdude]

Thanks! Seems like it did the trick.

BTW I will upload the Optiboot X source files on this repo too, not just host the binaries. However, I think I'll make my own makefile to clean things up a little.

[MCUdude]

@WestfW apart from the missing source files (for now), are you satisfied with the Optiboot implementation? Can I close this issue?

[tgtakaoka]

Heck, my bad. Please ignore my comments about optiboot on ATmega4808 and etc.

I totally forgot to reset MCU before uploading sketch via optiboot :(.

[MCUdude]

I'm closing this issue because Optiboot seems to be stable, and setting fuses/burning bootloader and uploading using programmer works perfectly fine. Please re-open if something still isn't right.

[DEMP1993]

I have a problem to burn the chip (Mega 4808) more than one time over UART0 default without burning the bootloader again.

Burn Bootloader (UART0 default) -> Burn via CP2102 over (UART0 default) works -> Burn again via CP2102 over (UART0 default) did not work

Burn Bootloader (UART0 default) -> Burn via CP2102 over (UART0 default) works -> Burn Bootloader (UART0 default) -> Burn via CP2102 over (UART0 default) works

Did someone has the same problem or has a solution for it ?

[MCUdude]

Sounds like your auto-reset circuit (100n capacitor and 10k pullup on the reset line doesn't work properly.

[DEMP1993]

I use a minimal board with only the Mega 4808 and two 100nF capacitors. I add now a 10k pullup and a 100nF capacitor to the reset pin and nothing changed. What are the conditions for bootloader start?

[MCUdude]

The bootloader starts when it gets a reset pulse. If you connect an LED to pin PA7, does it flash twice if you reset the chip?

It's also important to compile the code with one of the bootloader option in Arduino IDE. The bootloader sits at the first 512 bytes in the flash memory, so the user program has to be offset from this.

[DEMP1993]

I expected that a reset is not needed, so i did not reset the microcontroller. Now it works. Thanks for you fast answer.