>>
>> That's fine, you may have to power cycle before the settings take effect.
>
> I see! Now it works fine! Thanks for help.
>
>> If you have SRST connected that should also work, reseting using the
>> VC_CORERESET will not work.
>
> Should I write the powercycle (or SRST) trick somewhere in the
On Wed, Feb 10, 2010 at 3:58 PM, Spencer Oliver wrote:
> On 10/02/2010 09:07, Edgar Grimberg wrote:
>>
>> Now, how do I turn the readout protection off? I've tried:
>>
>>> stm32x unlock 0
>>
>> Device Security Bit Set
>> stm32x unlocked
>>>
>>> stm32x options_read 0
>>
>> Option Byte: 0x3fe
>>
On 10/02/2010 09:07, Edgar Grimberg wrote:
>
> Now, how do I turn the readout protection off? I've tried:
>
>> stm32x unlock 0
> Device Security Bit Set
> stm32x unlocked
>> stm32x options_read 0
> Option Byte: 0x3fe
> Readout Protection On
> Software Watchdog
> Stop: No reset generated
> Stand
> Just tried this with two separate boards and working ok here.
> Up until the mdw the log is the same as mine, i am using a ftdi based
> adapter. I can try a parport wiggler tomorrow.
I tried with our JTAG debugger and it fails just the same. I'm doing
the parport tests to be on the neutral side.
On 09/02/2010 15:35, Edgar Grimberg wrote:
> There's the test run. At address 0x0800, according to flash info
> 0, there should be the flash. The RAM is at 0x2000. You can see
> that it fails to read the flash, but it manages to read the RAM just
> fine:
>
> $ sudo src/openocd -f
> /home/ed
There's the test run. At address 0x0800, according to flash info
0, there should be the flash. The RAM is at 0x2000. You can see
that it fails to read the flash, but it manages to read the RAM just
fine:
$ sudo src/openocd -f
/home/edgar/workspace/openocd/tcl/interface/parport.cfg -f
/home
