[SOLVED] BlueNRG2: Mass erase triggered without asking first

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] BlueNRG2: Mass erase triggered without asking first

    Hi Segger,

    I have a situation where the BlueNRG2 goes to sleep.
    JLinkExe then tries to connect to this board, but only succeeds half-ways.

    It then reports that no flash memory words could be read, and so it decides to mass-erase my device.
    This is scary. I have not asked to erase my device, just to connect to it.

    Command used:
    JLinkExe -device BLUENRG2 -if swd -speed 1000 -AutoConnect 1


    See the log:


    SEGGER J-Link Commander V6.32b (Compiled May 8 2018 18:28:28)
    DLL version V6.32b, compiled May 8 2018 18:28:22

    Connecting to J-Link via USB...O.K.
    Firmware: J-Link V10 compiled Apr 20 2018 16:47:09
    Hardware version: V10.10
    S/N: 50104725
    License(s): GDB
    VTref=1.909V
    Device "BLUENRG2" selected.


    Connecting to target via SWD
    Found SW-DP with ID 0x0BB11477
    Found SW-DP with ID 0x0BB11477
    Scanning AP map to find all available APs
    AP[1]: Stopped AP scan as end of AP map has been reached
    AP[0]: AHB-AP (IDR: 0x04770021)
    Iterating through AP map to find AHB-AP to use
    AP[0]: Core found
    AP[0]: AHB-AP ROM base: 0xF0000000
    CPUID register: 0x410CC200. Implementer code: 0x41 (ARM)
    Found Cortex-M0 r0p0, Little endian.
    FPUnit: 4 code (BP) slots and 0 literal slots

    CoreSight components:
    ROMTbl[0] @ F0000000
    ROMTbl[0][0]: D00FF000, CID: 00000000, PID: 00000000 ???
    The first word in flash memory could not be read. This indicates that the device is secured.
    For accessing memory the device needs to be unsecured.
    Note: Unsecuring will trigger a mass erase of the internal flash.
    Device will be unsecured now.

    Executing ResetTarget()

    ****** Error: DAP error while reading DP-Ctrl-Stat register.
  • Hello,

    Thank you for your inquiry.
    The target voltage is suspiciously low. Make sure that at that voltage the debug interface and other debug related modules are active.
    For all devices that J-Link detects as locked the user will get a prompt informing the user which needs to be confirmed first before a mass erase is triggered.
    However the user can click the message away permanently. How to recover it is described here: wiki.segger.com/Secured_ST_device_detected

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Nino,

    The target voltage is just fine. We are working @ 1v9. The MCU is spec'ed 1.7 - 3.6V.
    Also, no popups were to be seen, ever. I am using JLinkExe on Linux, and it has never given me a popup. (Probably no GUI support, since I also get no device selection GUI)
    So I suppose this means JLink just proceeds to mass erase the device without asking, because there is no GUI? Maybe a command-line YES/NO can be a good alternative?
    Certainly mass-erasing without asking is not a good solution.

    Also, there is no "registry" on Linux, so no way to reset "DontShowAgainUnlockSTM".

    Thanks,
    Maxime

    The post was edited 1 time, last by maximevince ().

  • Hello Maxime,

    On Linux and Mac there are no GUI popups so default behaviour is that a unlock will get triggered if a locked/secured device is detected.
    This behaviour is expected by over 99% of our customers as they would like to connect to the chip which is not possible when it is in locked state...
    Otherwise every debug session with a locked device under Linux and Mac would fail.
    We will put the request to make this optional on our wish list for future internal discussions.

    The target voltage is just fine. We are working @ 1v9. The MCU is spec'ed 1.7 - 3.6V.

    Only because the MCU is specified that it will work with a certain voltage range does not mean that debugging is possible in all power states.
    We tried to reproduce the issue with an eval board but everything was working as expected.
    Can you reproduce the behaviour on an eval board?
    If so how did you proceed and what eval board did you use for your setup?
    At the moment we have to assume that this issue is solely related to your custom board and not J-Link.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Nino,

    Thanks for the reply!

    Absolutely, the power state of the MCU makes a big different if it's debuggable or not.
    I was just referring to the 1.9V since your said: "The target voltage is suspiciously low". Whereas this is our normal operating voltage.


    The CPU is in deep sleep, which means it's not debuggable.
    However, I put it to wake on the SWD pins, to the CPU is waking up on SWD activity.


    I understand your point about unlocking the MCU when it's detected to be in a locked state.
    However, our MCU certainly was NOT in a locked state. Just waking from a deep sleep state, which caused it to have its first word in flash memory to be non-accessible, triggering the erase.
    This might be specific to our board and not to the devkit working at 3v3, also since wake-up routines can be a little faster/slower because we are at a different voltage level, different Xtal, etc...


    But the main point here is: It would be nice if the JLink software would not just mass-erase the device, but ask for confirmation, or provide a command-line option to enable/disable automatic mass erase.


    Thanks!


    Best regards,
    Maxime