Thanks for you Answer. I can see the problem.
I assume it would be impossible to implement such a 16 bit write routine
into the original firmware, which is owned by STM ;-)
I think the warning is appropriate, could save some time to those having
the same problems as I have.
Im curious, what the suggested fix for the problem is and how STMs Tool
manages this 16 bit write access. Am I right in assuming, that a
bootloader is loaded into the processor, which accepts the data from the
programmer and does the 16 bit write from user code instead of via the
JTAG/SWD interface?
My question is, if this problem is also present in STLINK/V2 or FT2232H
Programmers.
I now removed the protection using the "STM32 ST-Link Utility"-Tool by
STM then reinstalled the WinUSB driver and loaded the flash using
OpenOCD again. I then tried my script again, and like before, nothing
worked.
I reverted back to the mass-storage driver and looked via the ST-Link
Utility and discovered that the Read Protection Bit has been set again
by OpenOCD!
I found out, that the current and broken version of "stm32f1x unlock 0"
actually sets the Readout Protection! Now I am doing only a mass_erase
followed by write_image and everything works now.
Yeehaw!
Thanks for your time and help.
PS: Not only throw a warning with stm32f1x unlock, but also remove the
erratic behaviour of enabling the Readout Protection.
Mit freundlichen Grüßen
Simon Küppers
Am 06.09.2012 20:42, schrieb Spencer Oliver:
> On 06/09/12 18:57, Simon Küppers wrote:
>> Dear Folks,
>>
>> Im currently trying to use OpenOCD together with a STM32VLDiscovery,
>> which basically is a STLINK/V1 tied to an STM32F100 via SWD.
>>
>> Actually, everything works OK, but one thing I can not figure out is
>> how to disable the Read Protection.
>>
>> I wrote a small test application, which would flash an LED on the
>> board. Then I tried to load the firmware onto the STM32F100 using
>> STM's STVP-Tool, with the STLINK/V1 being installed as a mass-storage
>> device.
>>
>> This works as expected, after disabling the Read Protection.
>>
>> Now I am trying to move to OpenOCD. I installed the WinUSB driver
>> using the "Zadig" Tool, with no problems. A quick test with OpenOCD
>> shows that everything is fine with the STLINK/V1:
>>
>
> The issue is caused because the stlink does not support 16bit writes
> that are needed for option byte writing.
>
> we do have a patch pending - http://openocd.zylin.com/480
> however a better approach is to add a 16bit read/write routine for the
> stlink.
>
> unlock the device using other means and do not perform a flash protect
> or unlock and you be fine.
>
> Think what i may do is add a warning before the 0.6 release to state
> that option byte writing is not supported for stlink.
>
> Cheers
> Spen
>
>
------------------------------------------------------------------------------
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
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
