STM32 and mass erase

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

    • 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: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      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 contact us per e-mail.
      Alternatively our support system can be used as well: segger.com/ticket/
    • 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: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      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 contact us per e-mail.
      Alternatively our support system can be used as well: segger.com/ticket/
    • 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.