|
From: Tomas V. <to...@us...> - 2020-10-07 05:54:34
|
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 >> > >> > >> > |