Thank you for your reply. Your suggestion about the unlock option in
'flash' command solved the problem.

 > reset halt
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08000420 msp: 00000000
 > flash info 0
#0 : stm32f2x at 0x08000000, size 0x00100000, buswidth 0, chipwidth 0
        #  0: 0x00000000 (0x4000 16kB) not protected
        #  1: 0x00004000 (0x4000 16kB) not protected
        #  2: 0x00008000 (0x4000 16kB) not protected
        #  3: 0x0000c000 (0x4000 16kB) not protected
        #  4: 0x00010000 (0x10000 64kB) not protected
        #  5: 0x00020000 (0x20000 128kB) not protected
        #  6: 0x00040000 (0x20000 128kB) not protected
        #  7: 0x00060000 (0x20000 128kB) not protected
        #  8: 0x00080000 (0x20000 128kB) not protected
        #  9: 0x000a0000 (0x20000 128kB) not protected
        # 10: 0x000c0000 (0x20000 128kB) not protected
        # 11: 0x000e0000 (0x20000 128kB) not protected
STM32F4xx - Rev: Z
 > flash write_image erase /home/mtbg/dummy_os/test.hex
auto erase enabled
wrote 16384 bytes from file /home/mtbg/dummy_os/test.hex in 1.276813s
(12.531 KiB/s)
 > flash write_image erase unlock /home/mtbg/dummy_os/test.hex
auto erase enabled
auto unlock enabled
stm32x device protected
failed erasing sectors 0 to 0
in procedure 'flash'
 > flash info 0                                               
Device Security Bit Set
#0 : stm32f2x at 0x08000000, size 0x00100000, buswidth 0, chipwidth 0
        #  0: 0x00000000 (0x4000 16kB) protected
        #  1: 0x00004000 (0x4000 16kB) protected
        #  2: 0x00008000 (0x4000 16kB) protected
        #  3: 0x0000c000 (0x4000 16kB) protected
        #  4: 0x00010000 (0x10000 64kB) protected
        #  5: 0x00020000 (0x20000 128kB) protected
        #  6: 0x00040000 (0x20000 128kB) protected
        #  7: 0x00060000 (0x20000 128kB) protected
        #  8: 0x00080000 (0x20000 128kB) protected
        #  9: 0x000a0000 (0x20000 128kB) protected
        # 10: 0x000c0000 (0x20000 128kB) protected
        # 11: 0x000e0000 (0x20000 128kB) protected
STM32F4xx - Rev: Z
 > 

It looks like it is indeed messing with the option bytes. The odd thing
is that the 'flash write_image erase unlock' works perfectly well on
another Discovery board (MB997C) - both STM32F407 chips are of revision
Z, so I don't know if it is the matter of the chip itself or the stlink.
Anyway, the issue looks like solved.
Thanks for help.

Regards,
mtbg


On Wed, 25 Sep 2013 11:33:14 +0100, Spencer Oliver
<s...@spen-soft.co.uk> wrote:
> On 24 September 2013 21:20,  <m...@mtbg.eu> wrote:
>> Hi all,
>>
>> I have a problem with using OpenOCD to access flash memory in STM32F4
>> discovery MB997C. The same setup and commands work perfectly well with
>> the older revision of the board (i.e. MB997B). When using flash
>> autodetection, OpenOCD detects 8192kB of flash (the MCU has 1024kB
>> according to the specification) contained into over 60 sectors of which
>> only 12 first sectors are consistent with the datasheet. Moreover, the
>> 'stm32f2x unlock 0' and 'flash protect 0 0 last off' commands success
>> most times, but then writing to flash fails in the erase phase with
>> 'stm32x device protected' message.
>>
> 
> I do not have access to the newer version but should be no reason why
> it would not work.
> 
> At a guess ST have not correctly programmed the flash size register,
> not uncommon - this is the reason you can manually override the bank
> size.
> 
>>
>> I tried setting the flash memory size to a fixed value of 1024kB. It
>> shows only the proper sectors then, but I'm still unable to access the
>> flash.
>>
> 
> I would suggest you first manually override the bank size then unlock
> the target.
> Looking at your logs you are not doing this successfully, also power
> cycle after the unlock and check it is unlocked before attempting
> anything else. Try something like
> 
> reset init
> stm32f4x unlock 0
>  - power cycle here then
> reset init
> flash info 0
> 
> And provide a full debug log (-d3) if possible.
> 
> Unless you are using the write protection i would not use unlock as
> part of the flash write_image as you will be writing to the option
> bytes.
> 
> Cheers
> Spen


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to