[SOLVED] J-link portable NRF52 recover

Tomek · Sep 20th 2016, 11:12am

Hi,
Currently we are setting up production in ems factory. We need to provide solution for flash program . J-link portable seems to be very convinient for us, and also very expensive.
We want to program our own software to BMD-300 (NRF52832 based module), but this module has locked software on board. It must be recovered. To do this i have used nrfjprog (nordic software) with J-Link base, and im wondering whether is it possible to do this using one button in jlink-portable
I've read some topic about unlock/flashing using standalone mode and it is unclear for me.
forum.segger.com/index.php?page=Thread&threadID=2724
So my question is: Is it possible to recover ,erase and program NRF52832 using J-link Portable (in battery mode)?
Best
Tomek

SEGGER - Niklas · Sep 20th 2016, 12:12pm

Hi Tomek,

this depends on how the device is locked.
The nRF52 can either be locked retractable or permanent. In the later case, The Flasher portable can do nothing about it.
If the lock is retractable, you need to check the reference manual of the device on how to unlock the chip, and then use the "Init steps" feature of J-Flash in order to tell Flasher which registers should be written before programming.

I attached a nRF51 J-Flash project which unlocks the device in the init steps for reference.

Best regards,
Niklas

baker.matt.j · Sep 26th 2016, 7:22pm

Hi Niklas,

This constraint is affecting us as well. We have two flasher portables used in production programming, and for updating firmware before shipping our products to customers.

The nRF52 lock is retractable. However, they took a very different approach from the nRF51. On the nRF52, the primary debug interface gets completely disabled. There is a secondary debug interface that contains only a full chip erase, soft reset and a couple other registers. There is a lot of information on the new process in this White Paper from Nordic, section 1.2 is most relevant. github.com/NordicSemiconductor…lob/master/white-paper.md

In order to unlock it, the SWD target needs to be changed to point to the secondary interface to issue a chip erase.

Any ideas on how to change the SWD target? I don't think there is a way to do it with only the init steps. At least for me, JFlash cannot connect to the device at all while locked, because it only attempts to connect to the primary endpoint.

The ideal case for the flasher chip init would look something like this:

Connect to Secondary Interface by default
Check status of Flash protect
If protected, issue chip erase and reset
Reconnect to device on primary debug interface

Could this be achieved with JLinkScript?

The certified radio modules we use come pre-locked, so we cannot unfortunately just enforce a single lock operation at the end of our production process.

Kind Regards,
Matt

rols · Sep 28th 2016, 2:46am

This is all documented pretty well on the Nordic devzone - they even have a command-line utility, cross platform, for this. I suggest going there to find all the threads about it.

The steps, for anyone finding this thread later are

SWDSelect
SWDWriteDP 1 0x50000000
SWDWriteDP 2 0x01000000
SWDWriteAP 1 0x00000001
sleep 500
SWDReadAP 3
SWDReadAP 3
exit

SEGGER - Erik · Sep 28th 2016, 10:28am

Hi Matt,

We will implement the unlock via AP / DP nRF52natively in the J-Link DLL as well as in stand-alone mode.

DLL: Will check if a secured device is detected. If yes, a message box will pop up and allow to perform the unsecure.
Stand-alone mode: Flasher will check if device is secured. If yes, the unsecure will be performed automatically.

We plan to have this feature ready by the end of this week / during next week, depending on the daily workload / interrupts.

Best regards
Erik

baker.matt.j · Sep 30th 2016, 9:41pm

Hi Erik,

Thank you for the update. We have three to four weeks before planned production deployment so this will be perfect for us.

The planned behavior looks good for standalone, as well as dev work using the DLL.

We would be happy to test a beta release in our flow if it helps.

Thanks,
Matt

SEGGER - Erik · Oct 12th 2016, 11:54am

Hi Matt,

We plan to have this ready within the next two weeks.
Thanks for the offer to serve as beta tester.

Keep you posted.

Best regards
Erik

Tomek · Oct 19th 2016, 11:06am

Hey i think there is another problem.
Using J-Flash i can recover NRF52832.
To do this i have used JlinkScript.
When i press F7 Auto mode everthing goes well. Recover Erase Program Go.

But, when i've downloaded config and data to flasher it returns Fail(Red Light) everytime when i try to programm.

C Source Code

void InitTarget(void) {
int returnCode;
Report("******************************************************");
Report("J-Link script: NRF52832 core J-Link script");
Report("******************************************************");
CPU = CORTEX_M4;
JLINK_CORESIGHT_WriteDP(1,0x50000000);
JLINK_CORESIGHT_WriteDP(2,0x01000000);
JLINK_CORESIGHT_WriteAP(1,0x00000001);
returnCode = JLINK_CORESIGHT_ReadAP(2);
SYS_Sleep(2000);
/*MessageBox1("ret : ",returnCode);*/
returnCode = JLINK_CORESIGHT_ReadAP(3);
SYS_Sleep(2000);
/*MessageBox1("ret : ",returnCode);*/
SYS_Sleep(500);
}

Display All

SEGGER - Erik · Oct 19th 2016, 1:03pm

Hi,

Thanks for the update. Good to hear that you have implemented the recovery function on your own.
Anyhow, native support is still on our todo and planned to be available by the end of this week / next week.

Please note, that the J-Link script file is not executed in stand-alone mode.
Once we have native support available, stand-alone mode will be supported as well.

Best regards
Erik

baker.matt.j · Oct 26th 2016, 4:17pm

Hi Erik,

Is it still expected to release this week or has it already dropped? Our production team pulled in their schedule slightly so I will be finding myself in the critical path shortly.

Kind Regards,
Matt

Tomek · Oct 28th 2016, 10:21am

Dear Segger,
I dont know who is responsible for this update, but please hurry up. It is more than month since i've ask you about NRF52 recover using flasher.
Your own deadline passes today.
Best Regards.
Tomek

SEGGER - Erik · Oct 31st 2016, 10:12am

Hi all,

Support for secured nRF52 devices has been added and validated internally.
An official version is planned to be available during this week (some other changes should be included in this version as well).

@Matt / Tom: I just sent you an e-mail, including a download link to a preliminary version. Can you please give it a try and provide feedback?

Best regards
Erik

Tomek · Oct 31st 2016, 11:43am

Hi Erik,
Thank You for update.
Regarding Flasher: It works fine when connected to PC, in standalone returns Fail every time even when there is no readback protection.

SEGGER - Erik · Oct 31st 2016, 12:22pm

Hi Tomek,

Thanks for the quick feedback. Just to make sure that we got you correct, can you please confirm the following?
J-Flash + device secured--> O.K.
J-Flash + device unsecured --> O.K.
J-Flash + device secured--> O.K.
J-Flash + device unsecured --> *NOT* O.K.

Just gave it a quick try but i am not able to reproduce any issues. Stand-alone mode as well as J-Flash is working just fine in both states (secured / unsecured).
Can you please send us two data files, which allow us reproducing the behavior here + step-by-step instructions? If it simplify things, you can reply to my e-mail with the link to the preliminary version.

Best regards
Erik

SEGGER - Erik · Nov 4th 2016, 9:04am

Quick update for the rest of the community:
All tests users confirmed that the preliminary version is working just fine in both, stand-alone mode as well as J-Flash mode.

An official release is planned to be available later today.

- Erik

SEGGER - Erik · Nov 4th 2016, 7:12pm

We have just released V6.10k of the J-Link software, in which the nRF52 changes are included:

Link: segger.com/jlink-software.html

wdu · Dec 14th 2016, 2:29pm

If I connect with JLinkExe v610m on linux to a locked nRF52 device, I'm surprised to find my device erased automatically, without warning, confirmation request, ... Knowing that a device is protected (i.e. someone already programmed it) is often an indication that I should leave it alone and query it in a different way.

Isn't this a bit aggressive?
Can I disable this behaviour?

Device "NRF52832_XXAA" selected.

Found SWD-DP with ID 0x2BA01477
CTRL-AP indicates that the device is secured.
For debugger connection the device needs to be unsecured.
Device will be unsecured now.
Note: Unsecuring will trigger a mass erase of the internal flash.
Found SWD-DP with ID 0x2BA01477

SEGGER - Niklas · Dec 14th 2016, 3:41pm

Hi,

J-Link Commander currently does not display any Message Boxes etc. under macOS / Linux as the GUI part is written in Win32API.
This will be changed to Qt in 2017, but we cannot give it priority right now.

I understand that this default seems aggressive, but it reflects the desired User experience:
The User wants to connect to the target device, which is not possible for most target devices if the device is locked.

I will ask at the next team meeting if we can have a temporary solution for this issue by the end of the year, e.g. a exec which allows the user to define the default behavior when a locked device is detected.

If your company happens to have a J-Link SDK (Part No 8.08.06 on the price list) license, you can set a hook function which is called when a locked device is detected. This hook function then returns if the device should be unlocked or not.

Best regards,
Niklas

C Source Code

Share