Brick after sd_nvic_SystemReset() with enabled readback protection.

RE: Brick after sd_nvic_SystemReset() with enabled readback protection.

Valer_I — Fri, 15 Apr 2016 21:10:21 GMT

Hi, I see. But the problem is not in bootloader. The problem is in function that rewrites bootloader from the firmware, when it starting to run with PALL readback activated. Further investigation shown that if I ran the same function code from flash (i.e. region 1) the update succeed and bootloader overwritten correctly. A little bit late I will open support case for this issue and give exect code to test. Now, I can add that the updating code is as simple as erasing and rewritting a few pages sequentially with reset at finish.

RE: Brick after sd_nvic_SystemReset() with enabled readback protection.

Hung Bui — Fri, 15 Apr 2016 14:22:51 GMT

Hi Valer,

We need more info to really understand what could be wrong here. You can send us your bootloader code for testing here, if it's easy to reproduce on one of our dev kit.

RE: Brick after sd_nvic_SystemReset() with enabled readback protection.

Valer_I — Thu, 14 Apr 2016 11:15:02 GMT

In both cases the same (For programming I use nRFGo studio, in SoftDevice tab tried checkbox "Enable SoftDevice protection (UICR.CLENR0)").

RE: Brick after sd_nvic_SystemReset() with enabled readback protection.

Hung Bui — Thu, 14 Apr 2016 10:43:37 GMT

Do you set UICR.CLENR0 ? If CLENR0 is not set the whole flash will be region 1. Could you test with CLENR0 not set ? Further debugging needed to see where the code stuck.

RE: Brick after sd_nvic_SystemReset() with enabled readback protection.

Valer_I — Wed, 13 Apr 2016 15:01:49 GMT

In general, but I think I have to look into more details. In firmware start I perform flash page erase from RAM and feel it could be the reason. In RM in section MPU 9.1 Functional description stated "Readback protection of code region 0 is enabled by writing '0' to UICR.RBPCONF.PR0. When enabled, only code running from code region 0 will be able to access the code in code region 0. Accesses generated by code running from code region 1 or from RAM, as well as accesses generated by the debugger (SWD), will not be granted when code region 0 is protected." so may be if PALL set the RAM access to code region1 is also restricted?(RM doesn't state it clear enough for code region 1).

RE: Brick after sd_nvic_SystemReset() with enabled readback protection.

Hung Bui — Wed, 13 Apr 2016 13:35:38 GMT

No, I don't think so. Readback protection only protect the chip from the SWD debug interface. You should have no problem with accessing from code. Have you had a look at our bootloader in the SDK ?

RE: Brick after sd_nvic_SystemReset() with enabled readback protection.

Valer_I — Wed, 13 Apr 2016 13:10:55 GMT

Thanks, this code is almost the same to mine. One more question about Readback protection, if it enabled are the any restrictions for using processor registers? ram/flash areas if to access from code?

RE: Brick after sd_nvic_SystemReset() with enabled readback protection.

Hung Bui — Wed, 13 Apr 2016 11:01:51 GMT

I am not sure "writting 0x05fa0004 to 0xe000ed0c" is a correct way of triggering reset. Here is the code for NVIC_SystemReset:

__STATIC_INLINE void NVIC_SystemReset(void)
{
  __DSB();                                                          /* Ensure all outstanding memory accesses included
                                                                       buffered write are completed before reset */
  SCB->AIRCR  = ((0x5FAUL << SCB_AIRCR_VECTKEY_Pos) |
                 SCB_AIRCR_SYSRESETREQ_Msk);
  __DSB();                                                          /* Ensure completion of memory access */

  for(;;)                                                           /* wait until reset */
  {
    __NOP();
  }
}

It's in core_cm0.h

RE: Brick after sd_nvic_SystemReset() with enabled readback protection.

Valer_I — Wed, 13 Apr 2016 10:20:25 GMT

Hi, the "brick" is in sense of running application. Of cource I can erase it with SWD and reflash. I investigated a little bit more. And it does not seem to be caused by sd_nvic_SystemReset(); after disconnection in bootloader.But in firmware at start I perform flash write and whan perform system reset by writting 0x05fa0004 to 0xe000ed0c. I suspect that reset operation performed incorrectly. Could you say the code of NVIC_SystemReset()?

RE: Brick after sd_nvic_SystemReset() with enabled readback protection.

Hung Bui — Tue, 12 Apr 2016 09:15:47 GMT

Hi Valer, When you mentioned "brick" you meant you can't recover (erase, reprogram) it or it just doesn't jump to application ? If it's the latter, you can test to debug, maybe using UART to check if it stuck somewhere in the bootloader ? Read back protection should only affect the SWD debugging interface. I don't think it would have anything to do with the bootloader.