GD32F103CB

[tomli at tomli.me]

On Fri, May 11, 2018 at 05:41:48AM +0900, NIIBE Yutaka wrote:
> Tom Li <tomli at tomli.me> wrote:
> > Thanks for your great work! There is little extra time for me in these
> > days so I temporaryly stopped the project I mentioned earlier in this
> > year, but will continue soon. 

> Only a single real problem to be fixed is... a tool like OpenOCD.  To
> unlock the protection, GD32F103 requires writing 0x5aa5, but for some
> reason, "stm32f1x unlock 0" didn't work for me.  I manually did
> following to unlock the device:
> 
>     mww 0x40022004 0x45670123
>     mww 0x40022004 0xcdef89ab
>     mww 0x40022008 0x45670123
>     mww 0x40022008 0xcdef89ab
>     mdw 0x40022010
>     mdh 0x1ffff800 8
>     mww 0x40022010 0x0210
>     mwh 0x1ffff800 0x5aa5
>     mdw 0x4002200c

I'm not entirely sure, but GD32 has its own additional protection modes,
including Readout Protection and Page Write Protection, which cannot be
deactivated by a standard "stm32f1x unlock 0", also, it seems that the
Readout Protection would be switched on, to an enable state whenever the
power is re-applied, even if it has been disabled previously. I think
it's an anti-tamper feature.

This is why I have reported these quirks to the mailing list by the end of
February, in case someone needs a link:

https://lists.gnupg.org/pipermail/gnuk-users/2018-February/000020.html

IMHO, the real long-term solution is contributing a patch to OpenOCD,
introducing these additional commands for those who are working with
GD32. But it seemed even these hacks I mentioned did not work reliably.

We probably should check the datasheet for confirmation and do some
additional tests.

Happy Hacking

Tom Li,
Beijing GNU/Linux User Group
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 851 bytes
Desc: Digital signature
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20180511/5f0686e3/attachment.sig>