Found a trouble with read back protect

RE: Found a trouble with read back protect

bjorn-spockeli — Mon, 06 Feb 2017 13:53:21 GMT

Great! It will be handled by one of my colleagues in the Mypage portal.

RE: Found a trouble with read back protect

jasonbu — Mon, 06 Feb 2017 08:47:49 GMT

@Bjørn Spockeli case id 34284 and attach uploaded

RE: Found a trouble with read back protect

bjorn-spockeli — Wed, 25 Jan 2017 10:31:51 GMT

@jasonbu: If your firmware is confidential, then I suggest that you create a support case in our closed support portal Mypage. If there is a potential issue with the memory protection, then this is definitely something we want to investigate.

RE: Found a trouble with read back protect

endnode — Sun, 22 Jan 2017 16:38:59 GMT

OK. The image isn't really convincing and if you say it's not general reproducible (but it depends on binary flashed and then on address you read out) then it might be misunderstanding of how non-NVM addresses work on nRF5x... Looking forward to more details (if you could share them).

RE: Found a trouble with read back protect

jasonbu — Sun, 22 Jan 2017 14:39:11 GMT

we tested some address on out hex production file.and found it seems got effected by our application hex file ... and it's not very suitable to publish it here ... only some hex file and some chip got this problem... and we are going to chinese spring festival... and maybe call the FAE two weeks later...

RE: Found a trouble with read back protect

endnode — Sun, 22 Jan 2017 09:04:33 GMT

Hi, this is really strange. Could you paste output from command line where you do readback protection? Note that it's effective from next chip reset not before, so even after this you can still dump the memory. Could you then reset the board (ideally power off/on), connect with J-Flash and dump some known area, e.g. beginning of address space from offset 0x00000000 where MBR and SoftDevice are? Can you then paste such screenshot? I haven't faced any issue with setting UICR.APPROTECT to PALL on nRF52, chips seems to be locked and debugger doesn't work (neither possibility to issue SWD commands and read memory).

RE: Found a trouble with read back protect

Roger Clark — Sun, 22 Jan 2017 09:03:09 GMT

Whats the image supposed to show?

RE: Found a trouble with read back protect

jasonbu — Sun, 22 Jan 2017 06:07:37 GMT

image uploaded

RE: Found a trouble with read back protect

jasonbu — Sun, 22 Jan 2017 06:05:33 GMT

I have try readout 0x10001208, it can be readout as 0x0000000, something strange it that only some chips got this trouble, most work allright.I'm not sure it will happen on your environment.

RE: Found a trouble with read back protect

Roger Clark — Sun, 22 Jan 2017 05:05:11 GMT

I recommend you look up the register map for the read protection and write directly to that address, JLink commander can definitely do that.

BTW. There is another current thread where someone accidently locked their nRF52 by writing data to it in the wrong format.

I have locked an nRF51 by writing zero's to the memory mapped hardware registers, so I imagine the nRF52 is the same and writing zero to one memory address will set the read protection.

If you see this thread,

devzone.nordicsemi.com/.../

it tells you have to lock by writing to memory.

I would do that to confirm its not an issue with nrfgo

RE: Found a trouble with read back protect

jasonbu — Sun, 22 Jan 2017 04:50:19 GMT

nRF52832 with Jflash got no secure the chip support, and if jflash read is ok nrfgostudio is also able to readback whole chip, only command line will tell that is unavaible

RE: Found a trouble with read back protect

Roger Clark — Sat, 21 Jan 2017 21:08:42 GMT

Very interesting

Have you tried securing the chip using JFlash (I'm not sure if it supports this)

Also, protection can normally be enabled by writing to the appropriate hardware register (though I'm not familiar with how to do this on the nRF52) Have you tried protecting it that way ?