Re: [OpenOCD-devel] NRF52840 approtect erase and unlock

[Tomas V. <to...@us...>]

This is really strange.
The log shows that your nRF52840 does not acknowledge debug power up 
(CDBGPWRUPACK, bit[29])
although CDBGPRWUPREQ, bit[28]  is correctly set. With powered off the 
debug domain there
is no wonder that CTRL-AP can't be read.

I loaded almost original nRF sdk17 examples 'ble dfu bootloader' and 
'buttonless dfu app' with softdevice s140/7.2.0
to my nRF52840. Then I locked APPROTECT. I tested the locked chip with a 
CMSIS-DAP adapter
and also with a bitbang based adapter (imx_gpio). In both cases nRF52840 
normally set debug power,
OpenOCD detected APPROTECT lock and unlocked the chip with 
nrf52_recover. Moreover, OpenOCD started
without 'catch init' hack.

I have no idea what is so different in your setup.

Tom

On 01/10/2020 15:04, Pieter De Gendt wrote:
> It does prevent the bail out, but I can't read IDR.
>
> Output: https://pastebin.com/UZHWuh0V
>
> On Thu, Oct 1, 2020 at 2:52 PM Tomas Vanek 
> <to...@us... <mailto:to...@us...>> 
> wrote:
>
>     Try this hack to persuade OpenOCD to keep running without
>     connectable target:
>
>     openocd ..... -c "catch init"
>
>     Using "catch init" instead of "init" prevents bail out in the case
>     of failed connection.
>
>     Then nrf52_recover could work. Please -d log again if not.
>
>     Tom
>
>     On 01/10/2020 13:45, Pieter De Gendt wrote:
>>     Hi Tom,
>>
>>     As I expected, I'm still stuck on my initial problem.
>>
>>     I can't get to the point to even try nrf52_recover. If APPROTECT
>>     is off (with nrfjprog --recover) I can program with openocd.
>>
>>     Full output: https://pastebin.com/xEpvSxbj
>>
>>     My board config file:
>>
>>     *# cat /etc/openocd/beam-nrf52840.cfg *
>>     adapter driver sysfsgpio
>>
>>     sysfsgpio_swdio_num 88
>>     sysfsgpio_swclk_num 89
>>     sysfsgpio_srst_num 117
>>
>>     transport select swd
>>
>>     reset_config srst_only srst_push_pull
>>     adapter srst pulse_width 1000
>>
>>     set CHIPNAME nrf52840
>>     source [find target/nrf52.cfg]
>>
>>
>>     On Thu, Oct 1, 2020 at 1:17 PM Pieter De Gendt
>>     <pie...@gm... <mailto:pie...@gm...>> wrote:
>>
>>         Hi Tom,
>>
>>         I will test it, I did, however have to change dap init with
>>         the patch
>>         attached, otherwise I got errors on init. See log for output.
>>
>>         Also if APPROTECT is enabled on my nrf52840 I am unable to
>>         read the
>>         IDR like you do in nrf52_recover.
>>
>>         Do you have an idea on what could be wrong?
>>
>>         Thanks,
>>         Pieter
>>
>>         On Thu, Oct 1, 2020 at 1:03 PM Tomas Vanek <va...@fb...
>>         <mailto:va...@fb...>> wrote:
>>         >
>>         > Please test
>>         > http://openocd.zylin.com/5845
>>         >
>>         > Create an account in Gerrit http://openocd.zylin.com/ if
>>         you don't have one
>>         > and post comments there.
>>         >
>>         > If the fixed nrf52_recover doesn't work for you, please put
>>         full -d3 log to
>>         > a paste.bin-like service and send the pointer.
>>         >
>>         > Thanks
>>         >     Tom
>>         >
>>         > On 30/09/2020 16:39, Pieter De Gendt wrote:
>>         >
>>         > Hi,
>>         >
>>         > The following commit adds nrf52_recover to erase and unlock
>>         nrf52 APPROTECT
>>         >
>>         https://sourceforge.net/p/openocd/code/ci/73a5f58adba73306b08b7bb22ff8a9511e79869f/
>>         >
>>         > However this doesn't seem to work for my nrf52840.
>>         > There are multiple issues:
>>         >
>>         > Several calls are done to ocd_$dap which isn't a valid
>>         command, just use $dap
>>         > apreg 1 8 is read-only, but is written
>>         > ERASEALLSTATUS is compared to 1, while 0 is the value for ready
>>         >
>>         > I used the datasheet
>>         https://infocenter.nordicsemi.com/pdf/nRF52840_PS_v1.1.pdf to
>>         verify the values.
>>         >
>>         > I think http://openocd.zylin.com/#/c/5384/ is closer to a
>>         solution.
>>         >
>>         > Changing all this, however, still doesn't allow me to
>>         unlock the controller as it restarts with approtect still
>>         active. Any suggestions on how to proceed and debug?
>>         >
>>         > Thanks in advance,
>>         > With kind regards,
>>         > Pieter
>>         >
>>         >
>>         > _______________________________________________
>>         > OpenOCD-devel mailing list
>>         > Ope...@li...
>>         <mailto:Ope...@li...>
>>         > https://lists.sourceforge.net/lists/listinfo/openocd-devel
>>         >
>>         >
>>
>