I have an STlink-v2 connected to a Waveshare Open 107V board with openOCD (0.6.0-dev-00599-ga21affa-dirty) runing on Ubuntu 64-bit (Precise).
When I run the following sequence through ARM gdb (arm-none-eabi-gdb), I get a flash size of 14Meg reported instead of 256K (see below - extra info lines added to the source for diagnostics). (gdb) target remote localhost:3333 (gdb) mon reset halt (gdb) mon flash probe 0 EXTRA INFO >> read (1 byte) = 31 EXTRA INFO >> read (1 byte) = 18 device id = 0x10016418 EXTRA INFO >> read (1 byte) = 31 EXTRA INFO >> cpuid = 411fc231 EXTRA INFO >> flash_size_reg = 1ffff7e0 EXTRA INFO >> read (1 byte) = c8 EXTRA INFO >> flash_size_in_kb = 36c8 EXTRA INFO >> read success (0=ok) = 0 EXTRA INFO >> (device_id & 0xfff) = 418 flash size = 14024kbytes flash 'stm32f1x' found at 0x08000000 (gdb) If I now connect to a Windows VM, run the STlink utility, it is unable to read the microcontroller due to the protection bit set in option bytes. Clearing this and reconnecting it to the Linux host results in correct detection: (gdb) target remote localhost:3333 (gdb) mon reset halt (gdb) mon flash probe 0 EXTRA INFO >> read (1 byte) = 31 EXTRA INFO >> read (1 byte) = 18 device id = 0x10016418 EXTRA INFO >> read (1 byte) = 31 EXTRA INFO >> cpuid = 411fc231 EXTRA INFO >> flash_size_reg = 1ffff7e0 EXTRA INFO >> read (1 byte) = 0 EXTRA INFO >> flash_size_in_kb = 100 EXTRA INFO >> read success (0=ok) = 0 EXTRA INFO >> (device_id & 0xfff) = 418 flash size = 256kbytes flash 'stm32f1x' found at 0x08000000 Trying to unlock the device results in failure (gets 0x03 until timeout) (gdb) mon flash protect 0 0 last off EXTRA INFO >> read (1 byte) = ff EXTRA INFO >> read (1 byte) = fe Device Security Bit Set EXTRA INFO >> read (1 byte) = ff EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 timed out waiting for flash failed setting protection for areas 0 to 7011 in procedure 'flash' If I increase the timeouts in stm32f1x.c (stm32_wait_status_busy function - force the timeout to 1000), it works: (gdb) mon flash protect 0 0 last off EXTRA INFO >> read (1 byte) = ff EXTRA INFO >> read (1 byte) = fe Device Security Bit Set EXTRA INFO >> read (1 byte) = ff EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 3 EXTRA INFO >> read (1 byte) = 20 EXTRA INFO >> read (1 byte) = 20 EXTRA INFO >> read (1 byte) = 20 EXTRA INFO >> read (1 byte) = 20 EXTRA INFO >> read (1 byte) = 20 EXTRA INFO >> read (1 byte) = 20 EXTRA INFO >> read (1 byte) = 20 cleared protection for sectors 0 through 7011 on flash bank 0 When I try to write an image to the flash it succeeds but reading it back with dump_image results in the data: 0x00000000 80 00 1F 41 03 00 03 00 00 00 00 00 00 (00 repeated) 0x00000200 80 00 1F 41 03 00 03 00 00 00 00 00 00 (00 repeated) 0x00000400 80 00 1F 41 03 00 03 00 00 00 00 00 00 (00 repeated) etc. I am using the config file contents: log_output ~/openocd.log debug_level 3 source [find interface/stlink-v2.cfg] source [find target/stm32f1x_stlink.cfg] and running via: openocd -f myopenocd.cfg Has anyone got the STM32F107V working with openOCD, or know what the above problems may be caused by? Thanks, Chris ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
