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
