AVR32DD20 READOUT protection

[X0NARU]

Hello world )))

How can protect my AVR32DD20 from code readout , that only full erase will unlock it ?
Maybe I can change something in configuration file of Arduino ? Or maybe direct via avrdude using this code : avrdude -c jtag2updi -p avr32dd20 -P COM13 -U lock:w
Thanks

[SpenceKonde]

Anything acting as a UPDI programmer can in theory. However. it's not well documented (hell, it's not well documented in the datasheet) what that procedure is for all programming tools. I'm pretty sure SerialUPDI has that feature hidden in it, but it is horrible code to read (we inherited it from Microchip, yasee)

I'll try asking my codeveloper who actually knows python again if he can figure out what these options are called, or thread through the entry points (through seven layers of abstraction - another task Im not good at).

But we all know it's possible on the hardware, so you don't need to know how to do it until you start distributing pre-programmed chips, which gives you some time.

avrdude should definitely work via that method, assuming you can get a jtag2updi programmer working (I had astronomical failure rates with those, Almost invariably it turned out to be just that I needed to change the dupont terminals. But I've had that happen 4-5 programmers one after another, and started thinking something else was wrong.

[X0NARU]

in another dissuasion I found this command
avrdude -c jtag2updi -p avr32da28 -P COM10 -U lock:w:0xa3:m
lock:w:0xa3:m - should I modify this for my avr32dd20 ?

[X0NARU]

UP

[SpenceKonde]

There are 4 bytes of lock on Dx-series, as opposed to 1 on the tinyAVR, though even writing one of them to anything other than the value they hold after a chip erase (0x5CC5C55C) will lock the chip.

0xA33A3AA3 is the recommended value to write to them. This goes for the DA too. It's sort of surprising that they felt a need to enlarge the lockbits, when they'd had just a single bit controlling it on classic AVRs, on tinyAVRs they use one lockbyte that holds 0x5C after reset (0xA3 & 0x5C = 0; 0xA3 | 0x5C = 0xFF; since writes can only turn 1's into 0's (and erase is needed to turn 0's into 1's, I suspect that this inverted bit pattern serves to zero-out the lockbits, and the further the lockbits are from the unlocked state, the harder it is for someone to manipulate the chip into becoming unlocked.

[X0NARU]

You are the best , thank you !!!