Re: [OpenOCD-devel] STM32VLDiscovery, OpenOCD and Read Protection Bit

[Spencer O. <sp...@sp...>]

On 06/09/12 20:32, Simon Küppers wrote:
> 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 ;-)

That's correct, however we can hope.

> 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?
>

ST use a small loader program, this is what we do for flash but not the 
option bytes.

The current patch only fixes the issue for stm321x family, i prefer a 
generic patch that adds a stlink 16bit read/write routine.

> My question is, if this problem is also present in STLINK/V2 or FT2232H
> Programmers.
>

all stlink's have the issue at the moment - all other interfaces are ok.

> 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.
>

the error thrown now will prevent this from happening now.

Spen