Closed thomaschandler closed 4 years ago
I found out that reading/writing the USERROW is possible using normal read/write (-r/-w) arguments, but the chip must be in programming mode in order for the read/write to succeed.
ie. ./cupdi -c /dev/ttyUSB0 -d tiny3217 -v 6 -u --read="1300:64"
I missed this part in the datasheet:
Section 6.6 User Row: The CPU can write and read this memory as normal EEPROM and the UPDI can write and read it as a normal EEPROM memory if the part is unlocked.
The user row is dumped successfully when using --dump
because nvm_enter_progmode
is called implicitly. Tests below:
GDB invoked with: gdb --args ./cupdi --dump -c /dev/ttyUSB0 -d tiny3217 -v 6 -f out.hex
Stepping through cupdi.c
:
234 if (write || fuses || flag) {
(gdb) p flag
$1 = 256
(gdb) n
235 result = nvm_enter_progmode(nvm_ptr);
I'm going to try to auto-enter progmode in the event that the user row region is read similar to the way --dump
auto-enters progmode.
Hi, Thomas: Yes, any action for UPDI accessing chip memory, it should execute the unlock operation first. After that Userorw area could be read by address access directly, and written by the nvm_write_userrow() function call by nvm_write_auto() <= updi_program().
Of cause you could export the interface of nvm_read_userrow/nvm_write_userrow individually by yourselves.
Best Regards.
The following already exists:
nvm_read_userrow
, but isn't used anywherenvm_write_userrow
I'm going to work on exposing read/write functionality to/from IntelHex files with two new command line arguments;
--userrow-read
and--userrow-write