From: Martin N. <amf...@mg...> - 2021-06-07 08:12:12
|
I had problems with my Arduino Mega erasing parts of the flash memory; sometimes the odd byte, sometimes the odd page. I changed 3 things to the flashing code to make the problem go away: 1. Checked the SPMCSR:RWWSB bit. This is a crib from the Atmel example (29.6.13 Simple Assembly Code Example for a Boot Loader). From the docs: "When the RWWSB bit is set, the RWW section cannot be accessed." Cribbed code: ; return to RWW section ; verify that RWW section is safe to read Return: in temp1, SPMCSR sbrs temp1, RWWSB ; The RWW section is not ready yet ret ; re-enable the RWW section ldi spmcrval, (1<<RWWSRE) | (1<<SPMEN) call Do_spm rjmp Return 2. Added a "Crash Trap" after NRWW_START_ADDR and immediately before the flashing code. This performs a reset rather than bumbling on and possibly overwriting some arbitrary FLASH. I chose this snippet: nop ; Some nops to synchronise. nop jmp_ PFA_COLD Certainly a Forth in development can end up executing empty FLASH memory. In the big Megas (store-i_big.asm) in particular, empty memory leads inexorably to the flashing code. All this rather depends on the function of M/C code instruction $FF, which seems undefined, so is probably a noop. 3. Disabled interrupts much earlier. Before any page is erased these should be switched off. Why? The user may be writing to Page 0 or to the page containing "isr:". Since time effectively stands still during flashing, I issue a CLI at the earliest possible moment. The Atmel example above says: "It is assumed that either the interrupt table is moved to the Boot loader section or that the interrupts are disabled." Under these circumstances the CLI in "dospm:" is no longer required. Feel free to dispute any of these points; I'm all ears. Remember: Aunty Atmel always knows best. She is omniscient here. Source files: amforth-6.9/avr8/words/store-i_big.asm amforth-6.9/avr8/words/store-i_nrww.asm -- Regards, Martin Nicholas. E-mail: rep...@mg... (Address will be valid throughout 2021). |