Using avrdude and an AVR microcontroller as a proxy to program another one connected to it via TWI

[3-14152898]

Hi people.

I am busy with a project of mine that involves two AVR microcontrollers, one ATmega328 and one ATtiny24/45/85. Before I finalize the release PCB I'd like to know if it is possible to use avrdude and the ATmega328 as a proxy to program the other microcontroller, knowing that they're both linked via I²C¹:

  6-pin
   ICSP   <------- ( MOSI/MISO/SCK/Reset ) -----> ATmega328 <-------- I²C ( SDA/SCL ) -------> ATtiny25
connector
    ^                                                                                             ^
    |                                                                                             .
AVRISPmkII                                                                                        .
    |                                                                                             .
    \----> avrdude   .      .      .      .      .      .      .      .      .      .      .      . 

The major feature I'm interested in is to program the ATtiny's EEPROM from the 6-pin ICSP connector (therefore using MOSI/MISO/SCK/Reset) that is physically wired to the ATmega328 right now. But I don't exclude flashing its program memory too. My priority right now is to access the tiny's EEPROM without having to desolder the chip or making it socket-able. Could that by chance be achieved by tweaking avrdude.conf?

For the record I'm using Manjaro Linux².

Thanks in advance and have a great day.

¹ It is understood that I am to write the required code and protocol between the two microcontrollers, and more if needed.
² No idea if that is relevant to the discussion though.

[stefanrueger]

Interesting problem. I don't see a way to access the ATtiny's EEPROM externally via I2C. Theoretically you might be able to write a bespoke bootloader that sits on the ATtiny, internally accesses its EEPROM and communicates with the m328 via I2C (or software USART using SDA/SCL); that might require an additional line from one of the m328's gpio to the t25's reset pin.

But no, not really.

I assume you thought about putting both m328 and the t25 onto the SPI bus and have a jumper on board that directs the ICSP reset line from the AVRISPmkII to either m328 or the t25? Then the jumper would decide which part gets programmed.

[3-14152898]

Theoretically you might be able to write a bespoke bootloader that sits on the ATtiny, internally accesses its EEPROM and communicates with the m328 via I2C [...]

That is indeed what it's about. Although it would not really be a bootloader in my case, at least not how I see it as my first idea would be to extend the existing protocol (which I already wrote) to support data transfers, which would cause the ATtiny to read/write the EEPROM.

And if there had to be a bootloader at all then I imagined it to sit in the ATmega328 instead since the ATtiny is always available via I²C and is not supposed to be reset externally. Fact its reset line is not connected (thus far).

The only gray area is about how to tell avrdude to not use the reset line to program the ATmega but hack its protocol so that the programming module "talks" to the ATmega328 via SPI. You might find/suggest a better approach since (I assume) you know avrdude guts way better (read: perfectly) than I do (I don't at all :D ).

I assume you thought about putting both m328 and the t25 onto the SPI bus and have a jumper on board that directs the ICSP reset line from the AVRISPmkII to either m328 or the t25?

Hmmm... I didn't and it's a nice idea. It would however imply non trivial changes to the PCB though, which I'd prefer to avoid.

I initially had thought about using a DIP package for the ATtiny¹ but then changed my mind for a TSSOP that I could streamline with the DIP footprint. The DIP package would be socketed but the streamlined TSSOP would then be soldered in place (although I have an adapter board TSSOP <-> DIP). I also thought about making an adapter board between the ICSP connector from the programming module with clamps, shaped like a alligator clip to latch onto a DIP-8 IC or using pogo pins to match the PCB holes.

But my reflections led me to conclude the software method demands less hardware work.

I'm not short of ideas, as you can see ;)

¹ So that it is programmed outside its PCB, e.g. on a breadboard.

[stefanrueger]

Yes: bootloader on the m328 could work too. Either way, the software on the t25 would need to be well thought through and implemented as the t25 can no longer be reprogrammed once it's soldered on. Accessing the m328 bootloader normally is via its USART using an USART/USB cable to the host PC (requiring a suitable connector), and not the ICSP interface via the external AVRISPmkII programmer.

[3-14152898]

Exactly, you've nailed it. Now I could always build my own board but since I (believe I) am pretty close to the goal with the tools I have, I have been wondering about how to make (or hack/tinker with) avrdude use the SPI bus as an intermediate, not as the programming target's interface.

[ndim]

Why is write access to just (specific parts of?) the ATtiny EEPROM a job for a general purpose MCU programmer like avrdude?

The description of the situation on the board sounds more like it should be a normal part of the ATtiny firmware's job to write values received from the ATmega via I2C to its EEPROM, and part of the ATmega firmware's job should be to issue such commands to the ATtiny.

Not having programmer access to the ATtiny is a design decision which has consequences. Implementing a general (any value to any address) or special purpose (specific values to certain addresses) EEPROM write commands accessible via I2C would be one such consequence. The latter would have the advantage of not requiring knowledge of the EEPROM memory layout inside the ATtiny firmware outside of the ATtiny firmware.

When the ATmega issues such EEPROM write commands to the ATtiny is another decision.

The ATmega could do that by itself e.g. on any board poweron, or on the first board poweron.

Or the ATmega firmware could do that only as part of the board bringup procedure, as a step to be triggered by some special bringup software communicating with the ATmega from the outside e.g. via SPI after avrdude has successfully written the firmware to the ATmega.

[3-14152898]

Well, I initially asked because to achieve what I want, I'd have to build a dedicated board to act as a gateway (SPI <-> USB) that would use the ICSP connector. Since I already have the (obsolete) programming module AVRISPmkII and avrdude my second thought was to see if it's possible to hack the latter instead (I don't know, add a module, edit its configuration... whatever makes sense to you).

I was under the impression this was clearly understood during the conversation. I am fully aware that I'd need to write the required piece of firmware, both for the ATmega328 and the ATtiny but with that I don't need more information thus far. Only about the feasibility of hacking avrdude.

If you want me to share technical details on my project (e.g. schematic, bits of code...) let me know.

[ndim]

So the actual question is whether it is possible to use the AVRISPmkII as a general purpose USB to SPI interface which could connect to the ATmega via the ICSP connector. Both the AVRISPmkII hardware and the AVRISPmkII firmware would need to support that.

The next question is then then whether maybe avrdude already happens to contain code that can be helpful for using the AVRISPmkII in that manner.

[stefanrueger]

Given the initial setup, there is no way for AVRDUDE to talk to the t25: an unmodified AVRISPmkII programmer with a standard 6-cable connection to a standard target board would always send the m328 into reset making it an SPI periphery for in system programming of the m328 no matter what AVRDUDE does.

If the project really wants to use SPI communication between the AVRISPmkII programmer and the boards's m328 then the m328's firmware would, out of necessity, operate in periphery mode as the programmer expects to drive SPI in host mode. This implies that the m328's SPI select pin PB2 should be connected to the 6-pin ISP connector instead of the m328's reset pin. This in turn requires a hardware mod, eg, a 3-pin jumper that can be set to either map the reset pin of the 6-pin ISP connector to the m328 reset (to program the m328) or to the m328's SPI select pin (to allow the m328 to operate in SPI periphery mode). When prompted by AVRDUDE, the AVRISPmkII programmer will issue a certain 4-byte communication on the SPI interface for reading from the target's EEPROM: [$A0] [0000 00aa] [aaaa aaaa] [data byte out]. If above jumper is set to operate the m328 in SPI periphery mode, the m328's firmware will be able to see the $A0 byte on the SPI bus. If the m328 makes it its business to maintain a cache of the t25's EEPROM contents then I imagine the m328 might be able to send the correct [data byte out] (ie, the t25's EEPROM contents) to the programmer in time: the SPI clock will be driven by the programmer, so that determines how much time the SPI periphery, ie, the m328 has to reply. The m328 would also need to emulate/ignore all the other SPI commands that the AVRISPmkII sends during a avrdude -c avrispmk2 -p t25 -U eeprom:r:-:h, eg, programming enable. This does not require a change of AVRDUDE functionality or behaviour.

Alternatively, the host running AVRDUDE could be connected directly to the m328 using an USB/USART cable. Selecting a bootloader programmer (wiring, arduino, urclock, ...) will make AVRDUDE enter communications according to that bootloader protocol, and the m328 firmware could emulate that and return the t25's EERPOM values if needed. Again, no change of AVRDUDE needed.

[3-14152898]

Thanks a whole bunch for this detailed explanation, really. I didn't expect this to be straightforward but at least your response perfectly highlights the challenges.

Another implementation I also thought of, which you (kind of) hint to in your response, is to actually flash the 328 with the EEPROM contents of the Tiny (at a dedicated location, of course) then the 328, say during the next boot, uploads the contents of that EEPROM section to the Tiny via the I²C protocol I wrote. No hack required, only standard procedures and hardware.

Thanks a lot again for sharing. Keep on rocking guys 👍