Hi Spencer and Paul. With the help from John Frenz on this post: <https://my.st.com/8466f8ae> I finally managed to write to the flash memory.
The value that is supposed to be in OPTCR, according to John, is 0x0FFFAAED; he read this value from a board that was writable (and I believe it's unlocked by STM's software). So this is the solution: # First, let's see what's in the OPTCR register (and display CR, to check for errors): > mdw 0x40023C14; mdw 0x40023C10 0x40023c14: 00aaaae1 0x40023c10: 00000000 # Now unlock the OPTCR register by writing to the OPTKEYR register: > mww 0x40023C08 0x08192A3B; mww 0x40023C08 0x4C5D6E7F; mww 0x40023C14 > 0x0fffaaed; mdw 0x40023C10 0x40023c10: 00000000 # Finally display the new value of the OPTCR register: > mdw 0x40023C14; mdw 0x40023C10 0x40023c14: 0fffaaed 0x40023c10: 00000000 ... I think it would make sense if OpenOCD reads the OPTCR register and checks that it contains the right value. If not, it could either... 1: Tell the user that the Flash memory is protected, and how to unprotect it. 2: Unprotect the Flash memory automatically. -It would probably make sense to do this in the 'unlock' procedure; anyone agree/disagree ? Love Jens On Mon, 22 Dec 2014 19:01:10 +0100, Jens Bauer wrote: > Hi Spencer and Paul. > > On Mon, 22 Dec 2014 08:44:53 +0000, Spencer Oliver wrote: >> Looking at the log you attached the cmds all look ok to me. >> May be the watchdog that is causing problems - see >> http://openocd.zylin.com/988 > > I tried doing this right after my first halt ... >> mww 0xE0042008 4096 > ... then issuing unlock followed by mass_erase; but I still get the > same error; I checked the value both before and after the attempt, > and it shows 0x00001000 as expected. > > I now decided to "look at the facts"... > 1: unlock completes without problems. > 2: mdw can read memory. > 3: mdw 0x40023C10 correctly shows that the LOCK bit is cleared (after > unlocking). > 4: The board's demo firmware was correctly erased yesterday (maybe > this *actually* happened before the unlock, because as soon as I > unlocked the device, I could read 0xffffffff from the entire flash > memory). > > My conclusion is that somehow mass_erase must have completed, though > it reports error. > Is it possible that mass_erase can complete even though the device is > not unlocked ? > > Alright, I decided to run openocd with the -d3 option, in order to > see which part of the function ... > static int stm32x_mass_erase(struct flash_bank *bank) > ... goes wrong: > >> halt >> reset halt >> stm32f4x unlock 0 >> stm32f4x mass_erase 0 > > Debug: 725 27150 command.c:145 script_debug(): command - ocd_command > ocd_command type ocd_stm32f2x mass_erase 0 > Debug: 726 27150 command.c:145 script_debug(): command - ocd_stm32f2x > ocd_stm32f2x mass_erase 0 > Debug: 728 27152 hla_target.c:766 adapter_read_memory(): > adapter_read_memory 0x40023c10 4 1 > Debug: 729 27156 target.c:2068 target_read_u32(): address: > 0x40023c10, value: 0x80000000 > > # retval = target_write_u32(target, stm32x_get_flash_reg(bank, > STM32_FLASH_CR), FLASH_MER ... ); = OK { > Debug: 730 27156 target.c:2156 target_write_u32(): address: > 0x40023c04, value: 0x45670123 > Debug: 731 27156 hla_target.c:780 adapter_write_memory(): > adapter_write_memory 0x40023c04 4 1 > # } > > # retval = target_write_u32(target, stm32x_get_flash_reg(bank, > STM32_FLASH_CR), FLASH_MER | FLASH_STRT); - this actually fails { > Debug: 732 27160 target.c:2156 target_write_u32(): address: > 0x40023c04, value: 0xcdef89ab > Debug: 733 27160 hla_target.c:780 adapter_write_memory(): > adapter_write_memory 0x40023c04 4 1 > > # I'm pretty sure that until now, we have success, because I can do a > # > reset halt > # > mdw 0x40023C10;mww 0x40023C04 0x45670123; mww 0x40023C04 > 0xCDEF89AB; mdw 0x40023C10 > # 0x40023c10: 80000000 > # 0x40023c10: 00000000 > # -So up until now, I'm sure there are no problems. > > Debug: 734 27164 hla_target.c:766 adapter_read_memory(): > adapter_read_memory 0x40023c10 4 1 > Debug: 735 27168 target.c:2068 target_read_u32(): address: > 0x40023c10, value: 0x00000000 > > # > mdw 0x40023c10 > # also succeeds and shows the value 0x00000000 > > Debug: 736 27168 target.c:2156 target_write_u32(): address: > 0x40023c10, value: 0x00000004 > Debug: 737 27168 hla_target.c:780 adapter_write_memory(): > adapter_write_memory 0x40023c10 4 1 > > # Bit 2 is MER, Mass Erase of bank 1 sectors... > # mww 0x40023c10 4 > # (still OK, no error) > > # just checking 0x40023c0c: > # > mdw 0x40023c0c > # 0x40023c0c: 00000000 > > > Debug: 738 27172 target.c:2156 target_write_u32(): address: > 0x40023c10, value: 0x00010004 > Debug: 739 27172 hla_target.c:780 adapter_write_memory(): > adapter_write_memory 0x40023c10 4 1 > > # > mww 0x40023c10 0x00010004 > # > mdw 0x40023c0c > # 0x40023c0c: 00000010 > > # woops. mww 0x40023c10 0x00010004 fails! > # -That's CR, the control register. What's the contents of this > register now ? > # > mdw 0x40023c10 > # 0x40023c10: 00000004 > # Alright, setting bit 16 failed, because we've set bit 2 > successfully above. > # Bit 31 (LOCK) is still clear; good. > # What's bit 16 ? > # In RM0090, section 3.9.7, it says it's "STRT": > # "This bit triggers an erase operation when set. It is set only by > software and cleared when the BSY bit is cleared." > > > Debug: 740 27176 hla_target.c:766 adapter_read_memory(): > adapter_read_memory 0x40023c0c 4 1 > Debug: 741 27180 target.c:2068 target_read_u32(): address: > 0x40023c0c, value: 0x00000010 > # } > > # retval = stm32x_wait_status_busy(bank, 30000); = Fails { > Debug: 742 27180 stm32f2x.c:206 stm32x_wait_status_busy(): status: 0x10 > Error: 743 27180 stm32f2x.c:218 stm32x_wait_status_busy(): stm32x > device protected > # } > Debug: 744 27181 target.c:2156 target_write_u32(): address: > 0x40023c0c, value: 0x00000010 > Debug: 745 27181 hla_target.c:780 adapter_write_memory(): > adapter_write_memory 0x40023c0c 4 1 > User : 746 27184 command.c:546 command_print(): stm32x mass erase failed > Debug: 747 27184 command.c:628 run_command(): Command failed with > error code -4 > User : 748 27185 command.c:666 command_run_line(): Runtime Error: > embedded:startup.tcl:525: > in procedure 'stm32f4x' > in procedure 'stm32f2x' called at file "embedded:startup.tcl", line 525 > > ... > > I decided to dump all the Flash interface registers: > 0x40023C00, ACR: 00000000 > 0x40023C04, KEYR: 00000000 > 0x40023C08, OPTKEYR: 00000000 > 0x40023C0C, SR: 00000010 (looks OK, 'protected' error) > 0x40023C10, CR: 00000004 (looks OK, LOCK is clear, the MER > bit is set, but the STRT bit was never set) > 0x40023C14, OPTCR: 00aaaae1 (looks strange) > 0x40023C18, OPTCR1: 110000c0 (looks even more strange) > > Looking in Section 3.9.10, I read about nWRP: "nWRP: Not write protect" > These bits contain the value of the write-protection and > read-protection (PCROP) option > bytes for sectors 0 to 11 after reset. They can be written to > program a new write-protect or > PCROP value into Flash memory. > If SPRMOD is reset: > 0: Write protection active on sector i > 1: Write protection not active on sector i > If SPRMOD is set: > 0: PCROP protection not active on sector i > 1: PCROP protection active on sector i > > The reset value is 0xFFF for these bits (all are set). > Is the 0xAAA value correct ? > If I read the note above, then I understand it as there are 12 > sectors (sector 11 to 0), which each have a protection bit. > SPRMOD is reset (clear), which means write protection is active on > sectors 1, 3, 5, 7, 9 and 11 - do I understand this correctly ? > > For the RDP-bits, the 0xAA looks correct: "0xAA: Level 0, read > protection not active" > The low 7 bits have nRST_STDBY, nRST_STOP, WDG_SW and OPTLOCK set. > > OPTCR1 does not make any sense to me; bit 28, which is reserved, > seems to be set; the low 16 bits are also reserved, but bits 7 and 6 > seem to be set. > > > Love > Jens > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > OpenOCD-devel mailing list > OpenOCD-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openocd-devel ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
