AVR Freaks

I've almost finished implementing the UPDI instruction set, so I was playing writing and reading stuff from the peripherals (not actually programming flash yet).

However, I found an undocumented feature while using the reset controller (one of the simplest peripherals of the XTiny). This peripheral has a register that holds flags indicating the causes of the resets, called the Reset Flag Register, RSTFR.

While reading this register, everything went as expected, the power on reset flag was set, of course, and after causing a reset via UPDI the corresponding flag is also set. All fine.

Then, I wanted to clear these flags. The documentation says that these flags are cleared by writing a "1" to them, so I just wrote 0xFF via the UPDI.

But to my surprise, all the flags where in fact set by this procedure. To clear them, I actually needed to write "0".

I also tested with interrupt flags, same thing.

My conclusion is that flags that are cleared when the CPU writes "1" to them, do not operate the same way when the UPDI is doing the writing. The UPDI can set and clear these flags at will, like normal bits.

I wonder if it's possible to trigger interrupts from the UPDI by writing the corresponding flags. If I remember I'll test this when I get to the stage when I'm actually able to upload a program.

It's a real tiny 1614 and not a simulator. Don't tell me this feature is a bug and you want to disable it...

Finally I finished a semi-working version of the STK500 to UPDI interface.

It can be connected to Atmel Studio as a STK500 programmer, though it lacks most functionality. Basically you can program the target or read back memory contents. But fuses can't be changed and never will in this version, only in the avrdude version when it's ready (one day...). EEPROM can't be changed either, but I will implement it later.

The target can't be fully erased or unlocked, but I use the erase/write command so it is possible to program flash in an unlocked chip without a full erase.

Now, studio doesn't support the xtiny series for the STK500, so I had to hack some way to get it working. The 3rd signature byte is replaced by 0x0A so that studio thinks it's another chip (with the same amount of flash).

So here is a screenshot:

As you can see, programing was successful but erase before programing must be unchecked. Notice that Studio thinks this is a Mega164P, but in fact it's a Tiny1614

I will attach the hex file so you guys can test this with other xtiny chips, if you want. You will need to burn the binary to an Arduino, then disable auto reset with a capacitor and make the proper connections:

Using this program, low budget hobbyists can now program the xtiny series with a simple Arduino.

When the source code is a bit more polished, I will post it in the projects section. This is kind of pre-alpha.

Oh, almost forgot, don't change the target voltage parameter from the 5.0V default. Other values enable secret functions of the software.

Oh, I mean it translates the STK500v2 protocol to the UPDI protocol, working as a STK500 emulator or something like that.

Sorry, you thought it was an adapter for the STK500?

I think such a thing would also be possible to do, in theory. Translate ISP commands to UPDI ones. Very messy, though.

A minor cog in the inner workings of avrdude is interfering with my plans! So I decided to report it as a bug, even though it doesn't manifest itself unless you get creative with the avrdude.conf file, like I'm doing...

Probably it will just be ignored by the developers, but maybe not since it's very simple to fix. The problem is if it breaks something, hopefully not.

So, what did I want to do? Since UPDI chips have so many fuses, why not access them all as a block? I found that the xtiny has a total of 32 fuse bytes, though most are undefined, and they form a contiguous block.

I thought: "Easy peasy, I'll define the "fuse" memory in avrdude.conf to be 32 bytes instead of 1 byte. Damn, I'm smart!", and added this line to my t1614 definition in avrdude.conf:

     memory "lfuse"                      /* All the Fuses */
        size            = 32;
        read            /* One of the bytes must contain an "o" to mark pollindex byte */
                        =       "0  0  0  0   0  0  0  0   o  0  0  1   0  0  1  0",
                                "1  0  0  a4  a3 a2 a1 a0  0  0  0  0   0  0  0  0";
        ;

I'll skip the details, but bytes 1 and 2 ( o 0 0 1 0 0 1 01 0 0 a4 a3 a2 a1 a0) form the fuse address, 0x1280 + |a4 a3 a2 a1 a0|. So what do I get from my experimental code?

C:\Users\JMR_2\Desktop\temp>avrdude -c stk500v2 -b 500000 -P com5 -p t1614 -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e9422 (probably t1614)
avrdude> dump lfuse
>>> dump lfuse
0000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

avrdude>

All zeroes? But it was working fine with other memory types, for example:

     memory "lock"                      /* All the Fuses */
        size            = 32;
        read            /* One of the bytes must contain an "o" to mark pollindex byte */
                        =       "0  0  0  0   0  0  0  0   o  0  0  1   0  0  1  0",
                                "1  0  0  a4  a3 a2 a1 a0  0  0  0  0   0  0  0  0";
        ;

C:\Users\JMR_2\Desktop\temp>avrdude -c stk500v2 -b 500000 -P com5 -p t1614 -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e9422 (probably t1614)
avrdude> dump lock
>>> dump lock
0000  00 00 02 ff 00 f6 06 00  00 ff c5 ff ff ff f1 02  |................|
0010  40 2a 45 e4 86 44 a4 54  d1 d3 85 46 94 54 0f 00  |@*E..D.T...F.T..|

avrdude>

That's how it's supposed to look! So finally I figured out that avrdude just ignores address bits a4 a3 a2 a1 a0 in the conf file for fuse memories, and replaces it by hardcoded addresses 0, 1 and 2 for lfuse, hfuse and efuse, so the same byte is read repeatedly.

So for now (forever?), I will use the "lock" memory to read/write all the fuses. That's bad because I wanted to access other UPDI memories using the different fuses (peripherals, RAM, etc.), it would probably allow using avrdude in interactive mode to do some limited debugging...

Sure, you can use this tool: https://github.com/ElTangas/jtag...

Other things you need:

• Write your program, for example with Atmel Studio or Arduino IDE
• Learn how to use the "avrdude" program
• An arduino to load my tool and use as programmer

I don't know exactly what you are asking, but the UPDI/reset pin is tolerant to high voltage (up to 12V), so the target's VCC can be lower than 5V even if the programmer uses 5V.

However, the UPDI pin must be able to output some voltage that is interpreted as "high" by the 5V programmer, so probably VCC on the target chip needs to be at least 3V.