Data to analyze knockoff FTDI bootloader problems

[microPaul]

Spence –

In Issue 191 (now closed) I had reported problems when trying to burn a bootloader into the AVR128DB64 when using a knock-off FTDI chip as the “Serial UPDI w/4.7K” programming device, although that same device would work fine for Arduino compiled code download over UPDI (including sketches under 512 bytes).

You had asked “Would you be able to dump the flash to a hex file” so that you could take a look at the potential cause of the problem. I’d be happy to do so but I’m not exactly sure what that means. I do have MPLAB X IDE and a Snap. Do you mean that I should use those devices to read out whatever did get programmed into the DB64 flash after the failed bootloader programming? Or is this something I should be able to do with the Arduino IDE? Also, what’s the address range where the bootloader is expected to reside in the flash?

Thanks,

[SpenceKonde]

Using whichever tool you want to get the contents of the flash after the failed attempt as a .hex file. (btw - I still see replies to closed issues - I just close things that don;t represent action items for me)
Not something the IDE can do. Can be done from command line with serialupdi (don't know off the top of my head the syntax) or wth avrdude and jtag2updi (and maybe a snap even? Probably not with the stock avrdude,conf, but the one i package with the core is supposed to work (I can't test it, my snaps don't even work with mplab. And when you have a bunch of programmers that work, it's hard to get excited about a programmer that doesn't). And definitely will work with mplab and a snap assuming your snaps work, unlike mine.

Bootloader goes in the first 512 bytes . they started putting it at the beginning of the flash now. I liked the old way better - the new way means you can't use the same application binaries for bootloader and non, while the old way could use the same binaries. no idea why they changed it.

[microPaul]

Ok, thanks. I'll try to get a hex dump in the next day or three.

[microPaul]

Well, this effort seemed like a good idea, but now it's clear that it's not.

I used my FTDI-knock-off and the Arduino DXcore to program a blink sketch into an AVR128DB64. Works well. I then tried to use the FTDI-knock-off to burn a bootloader into the same device. It goes through the whole process and then at the end tells me there's some sort of an array problem. Programming failed.

I then try to use MPLAB-X-IDE (what a mouthfull) and SNAP to read out the program memory after the failed bootloader programming. I get a message saying "Error code 28 received from the debugger". So I then try to use MPLAB and SNAP to burn an MPLAB blink sketch into the AVR128DB64. In that case I get a different error. "Error code 23 received from the debugger".

So I disconnect SNAP and go back to the FTDI-knock-off and the Arduino DXcore. Compile and program my original Arduino blink sketch into the AVR128DB64. Works as before. I then go back to the MPLAB and SNAP and now I am able to read out the contents of the AVR128DB64 program memory. Not helpful to debugging the FTDI-knock-off burn bootloader problem, but now I can again use MPLAB and SNAP to control the device, so I then used MPLAB and SNAP to program the MPLAB version of a blink program into the AVR128DB64. That works too now.

Anyway, it's clear that trying to figure out why the FTDI-knock-off can't program a bootloader won't be easy, and since the FTDI-knock-off is an odd duck, then why bother. I'll just use the CH340x to burn a bootloader when I need a bootloader enabled board.