From: Jens B. <jen...@gp...> - 2014-12-22 18:01:33
|
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 |