SpenceKonde
commented
1 year ago I thibk what you're missing is rhat you are trying to write to APPCODE from within APPCODE. Obviously no proper security model would permit this because it would allow a single code execution exploit to be leveraged into full control over the chip except for the bootloader itself. You can only write to sections of flash that are after CODEEND (Dx terminology) or APPEND when executing from APPCODE. The flash.h that uses optiboot gets around this by calling into the bootloader (BOOTCODE section) to make writes, since the bootloader section can write all of the flash except BOOTCODE. On dx, for bootloaderless arbitrary address flash writes (ie, allowing the app to scribble over itself) we declare the first 512b bootloader, and before enabling interrupts, redirect them to start at 0 instead of the start of the app and use unholy tricks to bamboozle the linker into ignoring its usual priority list (for exple, anything declared PROGMEM takes megapriority normal) and giving the required write instructions priority access to the first addresses after the vectors so they'll all be in the first 256 words( otherwise theyll give write ptotect errors when you try to write the page... I know how to do this but it is non-trivial, an I'm going to say there is insufficient demand to add this feature - unless someone were.willkng to pay for it.
Doing writes after APPEND from APPCODE is straightforward (but precluded by the way the core configures that parameter)
Doing writes to arbitrary addresses > 0x1FF is much harder.
Both require modifications to the core which I have had not a hint of demand for until your request; the first method, relatively minor. The second method...more considerable
Spence Konde Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: @.***
On Fri, May 5, 2023, 19:58 Unreal-Dan @.***> wrote:
First, I'm so sorry that I have to continue bothering you Spence, I don't know where else to turn at this point.
It seems as though the compile issues and problem with the previous post weren't actually related to the issues I was having with writing flash.
Since my previous post about writing flash memory I have learned a lot, I have come to realize that we are not using a bootloader nor do we need one. We do not need to be able to upload firmwares on the fly, quite simply I need a little more storage than the available 256 bytes of EEPROM.
We do not have a serial connection to the chip so optiboot isn't even really an option, only updi via jtag2updi.
I have studied the optiboot_x source code and I see how it is re-writing flash memory here:
https://github.com/Optiboot/optiboot/blob/master/optiboot/bootloaders/optiboot/optiboot_x.c#L509
I am attempting to write out flash memory in the exact same fashion but all attempts fail.
It seems as though NVMCTRL.STATUS is actually WRERROR after I try to perform an erase + write page with this code:
// store a serial buffer to storage bool Storage::write(ByteStream &buffer) { // Check size const uint16_t size = buffer.rawSize(); if (!size || size > STORAGE_SIZE) { ERROR_LOG("Buffer too big for storage space"); return false; } uint16_t pages = (size / PROGMEM_PAGE_SIZE) + 1; const uint8_t buf = (const uint8_t )buffer.rawData(); for (uint16_t i = 0; i < pages; i++) { // don't read past the end of the input buffer uint16_t target = i PROGMEM_PAGE_SIZE; uint16_t s = ((target + PROGMEM_PAGE_SIZE) > size) ? (size % PROGMEM_PAGE_SIZE) : PROGMEM_PAGE_SIZE; for (uint16_t j = 0; j < s; ++j) { ((uint8_t )storage_data)[target + j] = buf[target + j]; } // Erase + write the flash page _PROTECTED_WRITE_SPM(NVMCTRL.CTRLA, 0x3); while (NVMCTRL.STATUS & 0x3); } return true; }
I am using the raw values 0x3 for CTRLA and NVMCTRL.STATUS because I don't trust the macros in the headers I have available, some of them seemed to be wrong when I compared to the data sheet.
The datasheet is quite clear about which bits are which values so I am using constants like 0x3 for:
_PROTECTED_WRITE_SPM(NVMCTRL.CTRLA, 0x3);while (NVMCTRL.STATUS & 0x3);
As per the data sheet: https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/ATtiny3216-17-DataSheet-DS40002205A.pdf
STATUS:
Bit 2 – WRERROR Write Error This bit will read ‘1’ when a write error has happened. A write error could be writing to different sections before doing a page write or writing to a protected area. This bit is valid for the last operation. Bit 1 – EEBUSY EEPROM Busy This bit will read ‘1’ when the EEPROM is busy with a command. Bit 0 – FBUSY Flash Busy This bit will read ‘1’ when the Flash is busy with a command.
and CTRLA:
Bits 2:0 – CMD[2:0] Command Write this bit field to issue a command. The Configuration Change Protection key for self-programming (SPM) has to be written within four instructions before this write. Value Name Description 0x0 - No command 0x1 WP Write page buffer to memory (NVMCTRL.ADDR selects which memory) 0x2 ER Erase page (NVMCTRL.ADDR selects which memory) 0x3 ERWP Erase and write page (NVMCTRL.ADDR selects which memory) 0x4 PBC Page buffer clear 0x5 CHER Chip erase: Erase Flash and EEPROM (unless EESAVE in FUSE.SYSCFG is ‘1’) 0x6 EEER EEPROM Erase 0x7 WFU Write fuse (only accessible through UPDI)
I have tried so many different things at this point I'm not sure how I could even list all the different approaches I've taken without making a complete mess of this post.
The one thing that I have been able to do is get the EEPROM working, you can see the working EEPROM code in this specific branch of my project:
https://github.com/StoneOrbits/VortexEngine/blob/finger/VortexEngine/src/Storage/Storage.cpp
My latest attempt to make flash working is an ongoing work, but you can see a solid attempt in this specific commit here:
I am using a custom linker script that creates the section .storage and I am using a custom Makefile to run avr-gcc and avrdude with my own custom fuses:
upload: $(TARGET).hex $(AVRDUDE) $(AVRDUDE_FLAGS) \ -Ufuse0:w:0b00000000:m \ -Ufuse2:w:0x02:m \ -Ufuse5:w:0b11000101:m \ -Ufuse6:w:0x04:m \ -Ufuse7:w:0x78:m \ -Ufuse8:w:0x00:m \ -Uflash:w:$(TARGET).hex:i
I have tried all kinds of different values for fuse7 but no matter what I set, and no matter which address of ram I target the flash rewriting won't seem to work.
I decided to take a look at EEPROM.h and see if I could understand why it might be able to work using similar operations with the NVMCTRL and I noticed this:
EERef &operator = (uint8_t in) {
ifdef MEGATINYCORE
// I see no reason why eeprom_write_byte() won't corrupt EEPROM if an ISR tries to write at the wrong instant. The window is 1 clock, but not 0 uint16_t adr = (uint16_t)MAPPED_EEPROM_START + (index & EEPROM_INDEX_MASK); __asm__ __volatile__( "ldi r30, 0x00" "\n\t" // point the Z register at NVMCTRL. "ldi r31, 0x10" "\n\t" "in r0, 0x3f" "\n\t" // read the SREG into r0 to narrow the window between sbrc and cli. "ldd r18, Z+2" "\n\t" // read NVMCTRL.STATUS into r18 "andi r18, 3" "\n\t" // if NVMCTRL is busy.... "brne .-6" "\n\t" // repeat until it's not. "cli" "\n\t" // disable interrupts. 3 clock window during which an interrupt couldstart write since we checked // but this just means millis will lose time - nvmctrl halts CPU to finish last write "st X, %0" "\n\t" // write the value we were passed "ldi %0, 0x9D" "\n\t" // CCP signature loaded in it's place "out 0x34, %0" "\n\t" // protection enabled "ldi %0, 0x03" "\n\t" // command loaded: page erase-write. "st Z, %0" "\n\t" // write the page erase-write command to nvmctrl.ctrla "out 0x3f, r0" "\n" // restore SREG :"+d"(in) // take the value we are writing in any upper register as read/write, : "x"(adr) // and the address (not the index) in X : "r30", "r31", "r18"); // clobber Z and r18. We needed an upper register for the temporary value to andi it. I wonder if this will fix the eeprom bugs too? return *this; #else uint8_t oldSREG = SREG; while (NVMCTRL.STATUS & NVMCTRL_EEBUSY_bm); // check at start - not end. Makes writing single bytes fasterms // Note that we only have interrupts disabled for the dozen or so clock cycles // during which we *start* the write, not for the while loop, and we save SREG // before the while loop. That way there is only a 1 clock window where an // interrupt that starts a write will cause this write to halt the CPU // which would cause millis() to lose time. // Note that writing more than 1 byte in an ISR will **always** cause millis to lose time. cli(); _PROTECTED_WRITE_SPM(NVMCTRL.CTRLA, NVMCTRL_CMD_NONE_gc); _PROTECTED_WRITE_SPM(NVMCTRL.CTRLA, NVMCTRL_CMD_EEERWR_gc); *(uint8_t *)(MAPPED_EEPROM_START + (index & EEPROM_INDEX_MASK)) = in; SREG = oldSREG; // restore SREG and interrupts return *this; #endif}
It looks to be a massive ifdef splitting off the EEPROM write function into a different assembly-only version for megatinycore?
Does this mean there was something special that you had to do, such that it had to be done in raw assembly?
Do I need something similar for rewriting the flash with the nvmctrl?
— Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/megaTinyCore/issues/950, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW7LORRIHUT4BVHHPWTXEWHZZANCNFSM6AAAAAAXXWO6P4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Unreal-Dan
First, I'm so sorry that I have to continue bothering you Spence, I don't know where else to turn at this point.
It seems as though the compile issues and problem with the previous post weren't actually related to the issues I was having with writing flash.
Since my previous post about writing flash memory I have learned a lot, I have come to realize that we are not using a bootloader nor do we need one. We do not need to be able to upload firmwares on the fly, quite simply I need a little more storage than the available 256 bytes of EEPROM.
We do not have a serial connection to the chip so optiboot isn't even really an option, only updi via jtag2updi.
I have studied the optiboot_x source code and I see how it is re-writing flash memory here:
https://github.com/Optiboot/optiboot/blob/master/optiboot/bootloaders/optiboot/optiboot_x.c#L509
I am attempting to write out flash memory in the exact same fashion but all attempts fail.
It seems as though NVMCTRL.STATUS is actually WRERROR after I try to perform an erase + write page with this code:
I am using the raw values 0x3 for CTRLA and NVMCTRL.STATUS because I don't trust the macros in the headers I have available, some of them seemed to be wrong when I compared to the data sheet.
The datasheet is quite clear about which bits are which values so I am using constants like 0x3 for:
As per the data sheet: https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/ATtiny3216-17-DataSheet-DS40002205A.pdf
STATUS:
and CTRLA:
I have tried so many different things at this point I'm not sure how I could even list all the different approaches I've taken without making a complete mess of this post.
The one thing that I have been able to do is get the EEPROM working, you can see the working EEPROM code in this specific branch of my project (specifically lines 56 and 74):
https://github.com/StoneOrbits/VortexEngine/blob/finger/VortexEngine/src/Storage/Storage.cpp
My latest attempt to make flash working is an ongoing work, but you can see a solid attempt in this specific commit here:
https://github.com/StoneOrbits/VortexEngine/blob/c0878c7735ab8d78ee75eb86311fc4339755be1e/VortexEngine/src/Storage/Storage.cpp
I am using a custom linker script that creates the section .storage and I am using a custom Makefile to run avr-gcc and avrdude with my own custom fuses:
I have tried all kinds of different values for fuse7 but no matter what I set, and no matter which address of ram I target the flash rewriting won't seem to work.
I decided to take a look at EEPROM.h and see if I could understand why it might be able to work using similar operations with the NVMCTRL and I noticed this:
It looks to be a massive ifdef splitting off the EEPROM write function into a different assembly-only version for megatinycore?
Does this mean there was something special that you had to do, such that it had to be done in raw assembly?
Do I need something similar for rewriting the flash with the nvmctrl?