self-contained SD based AVR programmer

Workbench programming tool

Similar projects worth following
I have a bunch of things in my Tindie store and quite a number of them require programming of microcontrollers. To date my solution for this has been a variety of programming tools and either my Raspberry Pi bench computer or my MacBook Pro.

It struck me today that I could make a standalone programmer with an LCD display, with an SD card slot where the SD card has multiple per-project directories where each directory contains job configuration files, flash content and so on. To use, you would select a directory, connect the target, and press a button to start the programming.

This project isn't perfectly defined yet, but at the outset, the goal is to support as many of the different AVR programming modes as possible. That means ISP, PDI, TPI and UPDI. Of those, PDI, TPI and UPDI are quite similar (a bidirectional async serial pin and for PDI, a clock), and ISP is the oddball. However, it turns out that the XMega64D4 has MOSI, MISO and SCK superimposed on the same pins as TXD0, RXD0 and XCLK. The only extra requirement is the ability to impose the TXD/MOSI pin onto the RXD/MISO pin when using those modes. This can be done with a GPIO pin to switch a buffer on (exact circuit TBD).

With my other programmers, I've used switches to change the programming voltage, but here I think I'd rather have the availability of 5 volts, 3.3 volts or target power available programmatically (of course, the controller itself would have to run at 3.3 volts).

Port C and D both have a USART and SPI interfaces. Since we need 2 SPI interfaces (one for programming, one for the SD card), I had to upgrade to it from the XMega E series. Port C will go to the SD card slot. In addition to the normal 4 SPI signals for the SD card, there will also be a power switch. This will facilitate a "card reload" operation that will re-mount the card and re-probe the filesystem.

Port A will be connected to the LCD - it'll be run in 4 bit mode, so 4 pins for D4-D7, and one pin each for E, R/!W and RS. The LCD itself is designed to run on 5 volts, but it can run on 3.3 volts just fine (the backlight would be dimmer, but we can give the backlight 5 volts independently). The trick is that the Vo pin must be about 4.5 volts lower than Vcc. If Vcc is 3.3, then that means Vo must be negative. That's ok, though. Normally a "contrast" trimpot is used to set this voltage somewhere between Vcc and ground, but if you use a charge pump to invert the 3.3 volt supply then you can anchor the ends of the trimpot on -3.3v and ground instead. Adding a charge pump is a slight annoyance, but it's only one SOT23-6 chip and two caps.

Port B will be for the 4 buttons.

Port D is where most of the programming controls are. The SPI port is 3 of the pins, plus the !SS pin is used as the target !RESET signal. For the synchronous serial modes, the USART's alternate pinning option is selected instead, which winds up being transparent at the hardware level.

To control other aspects, a number of GPIO lines are required - these come from the remaining pins on port D and E. Two of them enable 5 volt or 3.3 volt target power. Alternatively, you can leave both off to force target power. Another line is the TX/RX combiner line. This is required for TPI, PDI and UPDI. It enables a buffer chip to send a copy of the TX line to merge with the RX line, through a protection resistor. This happens on the target side of the buffering system. Another pin is used to change the !RESET target pin from a straight low to a copy of the clock. This is necessary for PDI programming. Another pair of pins are used for HV programming control for TPI and UPDI. In the case of TPI, this asserts 12 volts on top of !RESET to force TPI mode when the !RESET pin is disabled. For UPDI, this asserts 12 volts as a pulse on the UPDI data pin to force UPDI mode similarly when that pin is fused for GPIO use. These HV voltages are enabled with a P MOSFET and Schottky diodes are used to protect the !RESET buffer chip, and a resistor and zener are used to protect the MISO/DATA buffer chip. The HV voltage itself comes from a boost converter that is itself powered by the 5 volt rail.

System power will come via a USB C jack. The data pins are not (currently) used, and PD negotiation is not required, as the whole system will run on 5 volts at less than 5 watts.

The SD card is going to have a FAT filesystem on it. The top directory has a directory for each project. The system will make the top level menu from the names of these directories.

Inside each project directory is a CHIP.TXT file. This...

Read more »

Adobe Portable Document Format - 144.56 kB - 08/30/2020 at 18:57


  • Hardware limitations

    Nick Sayer08/30/2020 at 23:35 0 comments

    At least for the initial version, one limitation on the hardware is going to be that for TPI, PDI and UPDI, the unused pins will not necessarily be quiescent. It's on the user to insure that the NC pins of the programming interface are actually not connected, or that unexpected signals on those pins won't do any harm. They will at least be confined to the target power voltage range, but for example, MOSI will have a copy of the transmit data on it and SCK will have a copy of the clock during PDI.

    Also, target power will only be applied while programming takes place. If configured, target power will be applied and after a brief delay (perhaps 10 ms or so) the programming cycle will begin. When it's over, target power will be dropped.

  • Imagining the menu system

    Nick Sayer08/30/2020 at 23:30 0 comments

    At boot, you get the first project on the disk

    <- Remount, -> Select

     You use up and down to scroll through the projects. If you go left, the power for the SD slot is turned off and you get:

    Insert SD card
    -> when ready

    Click right and you go back to the beginning.

    After picking a project and clicking right, you get

    <- or -> last:NONE

     This is telling you you can use the left button to go back to the selection menu, or right to start an operation with this project. last:NONE is telling you that the result of the last operation is undefined.

    Click right and the operation begins:


    The bottom row is a progress indicator for each sub-task. In general, you can expect first a chip erase operation, then the fuses are set and verified, then flash and lastly EEPROM. 

    At the end, you go back to the previous screen, with "last:GOOD" instead of NONE, assuming there were no errors. If there were, it would be "last:BAD"

    If there are errors, the error is shown and the screen paused for a second before going back with "last:BAD"

View all 2 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates