D7 LED not blinking after burning bootloader into 32DD14 configured for Serial on D4/D5 (Serial0, Swap3)

[microPaul]

Well, the title pretty much states what I'm seeing. I'm working on a new project and for this I'm using the DD14 for the first time. I'm using the Arduino IDE 1.8.13 and the DxCore version 1.5.11 via the IDE board manager.

I'm able to burn the bootloader into the DD14, and have selected to use D4-D5 as the serial port. I'm then able to use the serial port to download a blink sketch, with the hardware LED on the D7 port, which does blink the D7 LED. So all that is good.

But based on the info in https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/Ref_Optiboot.md my expectation was that after I had burned the bootloader into the DD14 that my D7 LED would show the fast triple blink indicating a successful bootload burn. But I never saw the triple blink on the D7 LED. This isn't a big deal, as nothing is impacting progress on my own project, but I thought I should point out the issue in case some adjustment in the bootloader (or the documentation for the bootloader) is needed.

[microPaul]

Another thing I'm seeing with the bootloader on the DD14 is that even though I set it up to disable MVIO (including the "burn bootloader done for sure" option), is that I think MVIO is still enabled. When I read the value of FUSE.SYSCFG1 in my program, I'm getting a value of 0x0C, which tells me that the MCU is configured for dual supply (MVIO enabled) and 8ms start up. So I don't think the burn bootloader command is respecting my choice for MVIO on/off.

[microPaul]

So I connected the DD14 to SNAP using MPLAB X IDE and was able to confirm that MVIO was enabled (even after programming the bootloader with the option to disable MVIO). I was able to use MPLAB to disable MVIO, load the config bits (fuses) back into the DD14 and then download my application using the Arduino IDE serial download. I could then read the value of FUSE.SYSCFG1 and see that it was now 0x14. With MVIO disabled I was then able to get the Analog Comparator to function on PC2-PC3 (which was my initial reason to disable MVIO on this device).

[mikrocoder]

Hi,

where does it specify the led flashing? I can't find anything about it. On the contrary. I think it is questionable and unnecessary that an LED should flash. The programming process tells you whether it was successful or not. Why an additional led pin? If "a circuit" is connected to the LED pin, then it does uncontrolled things.

[SpenceKonde]

The reason I made the LED flash is that otherwise, you have no way of knowing if optiboot is installed or running - you have no debugging if it's not working. If the board receiving power? Who knows! Is it running optiboot? Who could tell? A bad autoreset circuit, normally differentiable from some other problem, suddenly looks the same as everything else.

So even if I included a no-LED version of the bootloader, I'd still need to include a version that blinked the LED but was otherwise identical so that people who don't have Microchip debugging tools (Personally, I detest hardware debuggers, they take more time than they save except in very very bizarre problems. I think I thought one would have been useful once...) have some means of determining whether the reason they can't upload is that it isn't running optiboot, or if optiboot is running and they should be looking at the path from the computer to the target. And so on.

I am alarmed and concerned that the LED is not flashing, because the 32DD14 was what I developed on. Have you done the sanity check where you upload code that blinks that LED? If not, do that. If it uploads,but no light blinks, well then you know your problem is LED or the connections to it.

[microPaul]

I like LEDs. I'm glad it's part of the bootloader.

My 32DD14 hardware protoboard has an LED (cathode to ground) on PD7 and my blink sketch can blink that LED on D7, so I didn't think it's an LED issue.

So I then pulled out my scope. What I'm observing with my 32DD14 proto board, is that when I select UART0 for serial download, then after succesful bootloader burn, I see three repeating positive pulses on Pin 12 (PD6), not PD7. When I select UART1 as the serial download port and again burn the bootloader, I see the three repeating positive pulses on pin 10 (PD4) not PD5 as the documentation ( https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/Ref_Optiboot.md ) indicates. So, I guess you could change the documentation to match the operation of the current bootloader, but I use the DAC (always on D6?) for a lot of projects so I'd prefer to not have an LED on D6. In the absence of A7 and think D7 is a good choice for the bootloader LED.

There's also the issue of MVIO. I don't seem to be able to disable MVIO from the Tools tab in the Arduino IDE. The only way I have been able to turn off MVIO on the 32DD14 is to use MPLAB X IDE and a SNAP or ATMEL ICE. I've only tried to turn off MVIO on the 32DD14. I haven't tried it on other Dx parts, so I don't know if MVIO control is only a DD14 issue, or if it involves other parts as well.

[SpenceKonde]

The documentation has been corrected. I go into excruciating detail I think in the DD14 part specific page on why I chose that. In short, it's that when those pins are used for alternate functions, PD6 and PD4 are outputs. The other two options are the inputs, . So PD6/4 are most likely to be connected to the inputs on the other device, where the LED pulse would be unlikely to burn anything out, just look like noise. On the other hand, on the pins that are inputs when the peripherals are used, they'll likely be hardwired to output pins on other devices, which would fight with the drivers on the AVR and one of them would burn out. It's not foolproof, but it reduces the liklihood of the optiboot triple flash burning out something if you were using both ports for something, and had them wired directly as people do. You see my reason for picking that. I went through all the pins several times, writing out the list and crossing off the unsuitable ones and I kept winding up with every pin crossed off - there are no good choices, only bad and less bad pins. I would suggest either rebuilding the bootloader with the LED you need specified, or simply omitting the optiboot LED.

The portion of the documentation you found was written before the release with optiboot for DD, and before I'd had the realization about the directions of the special functions and theconsequences of matching or not matching it.

Choosing an LED pin on that made me think of a US presidential election... "I'm okay with whoever wins, as long as it's not of the candidates".

[mikrocoder]

Hi,

no matter what you have thought about, you cannot know what is connected to the end user's pins. Nobody can foresee that either. Therefore, please provide a bootloader version with which no unnecessary pins are connected. Thanks.

[microPaul]

Thank you Spence. The PD7 PD5 references for the bootloader LED are also appear in the Options selections under the Tools menu option "Chip" in the Arduino IDE (I'm using Arduino IDE 1.8.13 and the DxCore version 1.5.11), so those should also be updated the next time you are working on that area of the code. I can work with the LED on PD6-PD4. I need a pull down on PD6 for the DAC anyway, so I guess some portion of that pull down current can go into an LED.

[SpenceKonde]

Which I will be doing eminantly to address this MVIO thing.

You know, you could just build your own bootloader specifying PD7 (use the source in the release, not the github repo). The environment setup instructions on windows are pretty simple. They only require a bit of suspension of disbelief (that I use such an ugly hackjob of a build environment)

[mikrocoder]

Hi,

The right source is this? And the file to be edited optiboot_dx.c ?

[SpenceKonde]

No changes are necessary or appropriate in the c file at all. It's just a trivial tweak to the makefile, scroll down to the part for the DD14's and I think it should be clear how to change.