openocd-devel

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

[Simon K. <sim...@we...>]

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:

----
F:\Apps\openocd\openocd-0.6.0-rc2\openocd-0.6.0-rc2\bin-x64>openocd-x64-0.6.0-rc2.exe -f board/stm32vldiscovery.cfg -c init -c "halt" -c "stm32f1x options_read 0" -c shutdown
Open On-Chip Debugger 0.6.0-rc2 (2012-08-29-09:26)
Licensed under GNU GPL v2
For bug reports, read
         http://openocd.sourceforge.net/doc/doxygen/bugs.html
adapter speed: 1000 kHz
Info : clock speed 1000 kHz
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Warn : target was in unknown state when halt was requested
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Info : device id = 0x10016420
Info : flash size = 5384kbytes
Option Byte: 0x3fffffe
Readout Protection On
Software Watchdog
Stop: No reset generated
Standby: No reset generated
shutdown command invoked
----

It shows, that the Read Protection is activated.

While this looks rather good, I have noted 3 things:
   - "stm32f1x mass_erase 0" works. Is that correct behaviour? I could not erase the device with the STVP tool before disabling the Read Protection.
   - "flash write_image $file" does not produce any errors. It successfully writes the bytes to the chip, well, at least it says so. After "reset run", nothing happens on the target.
   - "flash write_image erase unlock $file" does produce an error. It complains about the Readout Protection

So, how do I disable the Read Protection? I tried using "stm32f1x unlock 0", which acknowledges the removal of the Read Protection. But no matter if I use a "reset halt" or recycle the power supply afterwards, the Readout Protection won't disable.

----
F:\Apps\openocd\openocd-0.6.0-rc2\openocd-0.6.0-rc2\bin-x64>openocd-x64-0.6.0-rc2.exe -f board/stm32vldiscovery.cfg -c init -c "halt" -c "stm32f1x options_read 0" -c "stm32f1x unlock 0" -c "reset halt" -c "stm32f1x options_read 0" -c shutdown
Open On-Chip Debugger 0.6.0-rc2 (2012-08-29-09:26)
Licensed under GNU GPL v2
For bug reports, read
         http://openocd.sourceforge.net/doc/doxygen/bugs.html
adapter speed: 1000 kHz
Info : clock speed 1000 kHz
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Warn : target was in unknown state when halt was requested
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Info : device id = 0x10016420
Info : flash size = 5384kbytes
Option Byte: 0x3fffffe
Readout Protection On
Software Watchdog
Stop: No reset generated
Standby: No reset generated
Info : Device Security Bit Set
stm32x unlocked.
INFO: a reset or power cycle is required for the new settings to take effect.
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Option Byte: 0x3fffffe
Readout Protection On
Software Watchdog
Stop: No reset generated
Standby: No reset generated
shutdown command invoked
----


For the record, I include the scripts I have used.

openocd.cfg
----
init

proc program {file} {
     reset halt
     stm32f1x unlock 0
     reset halt

     stm32f1x mass_erase 0
     flash write_image $file
     
     reset run
     shutdown
}
----

My Eclipse External Tool Configuration Parameters:
----
-f board/stm32vldiscovery.cfg
-f ${project_loc}\openocd.cfg
-c "program {${project_loc}\${config_name:${project_name}}\${project_name}.hex}"
----

And this is the result:
----
Open On-Chip Debugger 0.6.0-rc2 (2012-08-29-09:26)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.sourceforge.net/doc/doxygen/bugs.html
adapter speed: 1000 kHz
Info : clock speed 1000 kHz
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
program
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000850 msp: 0x20002000
Info : device id = 0x10016420
Info : flash size = 128kbytes
stm32x unlocked.
INFO: a reset or power cycle is required for the new settings to take effect.
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000850 msp: 0x20002000
stm32x mass erase complete
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x41000000 pc: 0x2000003a msp: 0x20002000
wrote 2268 bytes from file F:\Projekte\_EclipseWorkspaces\STM32\Test\Debug\Test.hex in 0.306641s (7.223 KiB/s)
shutdown command invoked
----

As you can see, there is no problem (as noted before). But the target won't execute the code I wrote, which is definitely working using the STM-STVP Tool instead of OpenOCD.

I hope someone of you can help me. I have been made aware, that the combination of SWD and STLINK/V1 is a rather tricky one.
If so, can anybody tell me a better hardware to work with OpenOCD? Will the STLINK/V2 work better?

Thanks in Advance and let me know if you need some more information, which I will be happy to provide.

-- 

Mit freundlichen Grüßen

         Simon Küppers

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

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

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

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

[Simon K. <sim...@we...>]

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

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

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

[Simon K. <sim...@we...>]

Great,
Luckily Im a bloody beginner and in an evaluation phase right now.
I think for the real work, I will switch over to an FT2232H based 
programming hardware, which seems to be supported way better by OpenOCD 
than any STLINK and is even cheaper.

Thanks again and keep up the good work!

Mit freundlichen Grüßen

         Simon Küppers

Am 06.09.2012 21:48, schrieb Spencer Oliver:
> 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
>

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

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

On 06/09/12 21:10, Simon Küppers wrote:
> Great,
> Luckily Im a bloody beginner and in an evaluation phase right now.
> I think for the real work, I will switch over to an FT2232H based
> programming hardware, which seems to be supported way better by OpenOCD
> than any STLINK and is even cheaper.
>

it is worth noting that stlink and versaloon are the only interfaces 
that support SWD.

Spen

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

[Alain M. <al...@po...>]

Em 06-09-2012 17:19, Spencer Oliver escreveu:
>
> it is worth noting that stlink and versaloon are the only interfaces
> that support SWD.

Will ever be SWD with FT2232? Is someone working on it?

That would be a really "native" interface for OpenOCD...

Alain