Hi Tom, Your comment did help me further! The datasheet states that the device has to be in "SYSTEM OFF" in order to set the CDBGPRWUPREQ. So I modified my reset_config to:
reset_config srst_only srst_push_pull connect_assert_srst srst_nogate Now I can call the nrf52_recover! But (there is always a but), if I call "reset init" and the program verifies that the chip is locked, I can't call the nrf52_recover anymore. I have to restart openocd in order to do that (without reset init). Thanks so far! Pieter On Wed, Oct 7, 2020 at 7:53 AM Tomas Vanek <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> 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 >>> > [email protected] >>> > https://lists.sourceforge.net/lists/listinfo/openocd-devel >>> > >>> > >>> >> >> >
_______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
