[ABANDONED] STM32 and mass erase

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

  • [ABANDONED] STM32 and mass erase

    I'm using a JLink Segger to flash my STM32L4A6 MCU.
    Most of the time it works perfectly fine but sometimes I don't know why, a mass erase is triggered.

    Source Code

    1. Connecting to target via SWD
    2. Found SW-DP with ID 0x2BA01477
    3. STM32 (Protection Detection): Unexpected IDCODE DEV_ID 0x 461 found. Only checking the 1st flash bank for write protection.
    4. Active read protected STM32 device detected.
    5. This could cause problems during flash download.
    6. Note: Unsecuring will trigger a mass erase of the internal flash.
    7. Device will be unsecured now.
    8. Found SW-DP with ID 0x2BA01477
    9. Found SW-DP with ID 0x2BA01477
    10. Found SW-DP with ID 0x2BA01477
    11. Found SW-DP with ID 0x2BA01477
    12. Found SW-DP with ID 0x2BA01477
    13. Scanning AP map to find all available APs
    14. AP[1]: Stopped AP scan as end of AP map has been reached
    15. AP[0]: AHB-AP (IDR: 0x24770011)
    16. Iterating through AP map to find AHB-AP to use
    17. AP[0]: Core found
    18. AP[0]: AHB-AP ROM base: 0xE00FF000
    19. CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
    20. Found Cortex-M4 r0p1, Little endian.
    21. FPUnit: 6 code (BP) slots and 2 literal slots
    22. CoreSight components:
    23. ROMTbl[0] @ E00FF000
    24. ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
    25. ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
    26. ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
    27. ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
    28. ROMTbl[0][4]: E0040000, CID: B105900D, PID: 000BB9A1 TPIU
    29. ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM
    30. Cortex-M4 identified.
    31. Reset delay: 0 ms
    32. Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
    33. Reset: Halt core after reset via DEMCR.VC_CORERESET.
    34. Reset: Reset device via AIRCR.SYSRESETREQ.
    Display All
    This is annoying because well I'm storing important stuff in flash that I need to restore every time it happens. I know there is a hook to prevent the mass erase for the Windows version but it was promised also for Linux, is it available?
    More importantly, I'm wondering if this issue hides a problem I have with my code perhaps? What makes this thing trigger because I'm not touching the option bytes or anything of the sort just flashing application to be executed.

    Thanks for your help.

  • Hello,

    Thank you for your inquiry.
    From the log it seems that a read protected Flash is detected via opt bytes.
    Could you provide a J-Link log of the failing session?
    wiki.segger.com/Enable_J-Link_log_file

    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.

  • Hello,

    According to the log file the read protection is set.
    Is the device you are programming a "virgin" device or was there an application already running on it?
    If an application was running prior to that could you check if the application might be altering the option byte settings?

    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.

  • Hello.

    I double checked and couldn't really find any instance where we would randomly change these bytes.
    Is JLinkExe looking just at these option bytes or others also?

    Bits 7:0 RDP: Read protection level0xAA: Level 0, read protection not active0xCC: Level 2, chip read protection activeOthers: Level 1, memories read protection active

    I had a mass erase once and just before I had printed the RDP field and it was properly set at 0xAA.