Option bytes not written as expected - block verification error

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

    • Option bytes not written as expected - block verification error

      Hi,

      I am using J-Flash V6.52 for programming an STM32L151VC device.
      The data file I am trying to flash also contains the option bytes that are supposed to be written from address 0x1FF80000.
      These are the bytes shown when I open the file in J-Flash:
      00 00 FF FF EC 00 13 FF 00 00 FF FF 00 00 FF FF 00 00 FF FF 00 00 FF FF
      So with these option bytes I want to set read protection, HW independent watchdog and BOR_LEVEL5.

      When I try to program the data file I see following logging:

      Auto programming target (257804 bytes, 3 ranges) ...
      - Connecting ...
      - Connected successfully
      - Checking if selected data fits into selected flash sectors.
      - Start of preparing flash programming
      - End of preparing flash programming
      - Start of determining dirty areas in flash cache
      - End of determining dirty areas
      - CPU speed could not be measured.
      - Chip erase not supported for flash bank @ 0x08000000. Switched to sector erase
      - Start of determining dirty areas in flash cache
      - End of determining dirty areas
      - Start of erasing sectors
      - Blank checking 0x08000000 - 0x0801FFFF
      - Erasing range 0x08000000 - 0x0801FFFF (512 Sectors, 128 KB)
      - Blank checking 0x08020000 - 0x0803FFFF
      - Erasing range 0x08020000 - 0x0803FFFF (512 Sectors, 128 KB)
      - Blank checking 0x08080000 - 0x08081FFF
      - Erasing range 0x08080000 - 0x08081FFF ( 1 Sector, 8 KB)
      - Blank checking 0x1FF80000 - 0x1FF8001F
      - Erasing range 0x1FF80000 - 0x1FF8001F ( 1 Sector, 32 Bytes)
      - End of erasing sectors
      - Start of flash programming
      - Programming range 0x08000000 - 0x080026FF ( 39 Sectors, 9 KB)
      - Programming range 0x08003800 - 0x0800B7FF (128 Sectors, 32 KB)
      - Programming range 0x0800B800 - 0x080137FF (128 Sectors, 32 KB)
      - Programming range 0x08013800 - 0x0801B7FF (128 Sectors, 32 KB)
      - Programming range 0x0801B800 - 0x080237FF (128 Sectors, 32 KB)
      - Programming range 0x08023800 - 0x0802B7FF (128 Sectors, 32 KB)
      - Programming range 0x0802B800 - 0x080337FF (128 Sectors, 32 KB)
      - Programming range 0x08033800 - 0x0803B7FF (128 Sectors, 32 KB)
      - Programming range 0x0803B800 - 0x0803FFFF ( 72 Sectors, 18 KB)
      - Programming range 0x1FF80000 - 0x1FF8001F ( 1 Sector, 32 Bytes)
      - End of flash programming
      - Flash programming performed for 3 ranges (257824 bytes)
      - 0x8000000 - 0x80026FF ( 39 Sectors, 9 KB)
      - 0x8003800 - 0x803FFFF (968 Sectors, 242 KB)
      - 0x1FF80000 - 0x1FF8001F ( 1 Sector, 32 Bytes)
      - Start of restoring
      - ERROR: Programming failed @ address 0x1FF80000 (block verification error)
      - ERROR: Failed to restore target. RAMCode never stops
      - End of restoring
      - ERROR: Failed to auto program target
      Error: Programming failed @ address 0x1FF80000 (block verification error)
      Failed to restore target. RAMCode never stops
      Failed to auto program target
      Disconnecting ...
      - Disconnected


      So the programming fails with a block verification error on the option bytes!
      If I then do a readback of the entire chip and then look at the 0x1FF80000 range, I see following option bytes displayed:
      00 00 FF FE EC 00 13 FF 00 00 FF FF 00 00 FF FF 00 00 FF FF 00 00 FF FF

      So the 4th byte is 0xFE while it should be 0xFF instead. 0xFF is the expected complement value of 0x00, the second option byte.
      I assume that this leads to the "block verification" error.

      If a write default option bytes:
      AA 00 55 FF EC 00 13 FF 00 00 FF FF 00 00 FF FF 00 00 FF 00 00 FF FF
      Then all goes fine:

      Auto programming target (257804 bytes, 3 ranges) ...
      - Connecting ...
      - Connected successfully
      - Checking if selected data fits into selected flash sectors.
      - Start of preparing flash programming
      - End of preparing flash programming
      - Start of determining dirty areas in flash cache
      - End of determining dirty areas
      - CPU speed could not be measured.
      - Chip erase not supported for flash bank @ 0x08000000. Switched to sector erase
      - Start of determining dirty areas in flash cache
      - End of determining dirty areas
      - Start of erasing sectors
      - Blank checking 0x08000000 - 0x0801FFFF
      - Blank checking 0x08020000 - 0x0803FFFF
      - Blank checking 0x08080000 - 0x08081FFF
      - Blank checking 0x1FF80000 - 0x1FF8001F
      - Erasing range 0x1FF80000 - 0x1FF8001F ( 1 Sector, 32 Bytes)
      - End of erasing sectors
      - Start of flash programming
      - Programming range 0x08000000 - 0x080026FF ( 39 Sectors, 9 KB)
      - Programming range 0x08003800 - 0x0800B7FF (128 Sectors, 32 KB)
      - Programming range 0x0800B800 - 0x080137FF (128 Sectors, 32 KB)
      - Programming range 0x08013800 - 0x0801B7FF (128 Sectors, 32 KB)
      - Programming range 0x0801B800 - 0x080237FF (128 Sectors, 32 KB)
      - Programming range 0x08023800 - 0x0802B7FF (128 Sectors, 32 KB)
      - Programming range 0x0802B800 - 0x080337FF (128 Sectors, 32 KB)
      - Programming range 0x08033800 - 0x0803B7FF (128 Sectors, 32 KB)
      - Programming range 0x0803B800 - 0x0803FFFF ( 72 Sectors, 18 KB)
      - Programming range 0x1FF80000 - 0x1FF8001F ( 1 Sector, 32 Bytes)
      - End of flash programming
      - Flash programming performed for 3 ranges (257824 bytes)
      - 0x8000000 - 0x80026FF ( 39 Sectors, 9 KB)
      - 0x8003800 - 0x803FFFF (968 Sectors, 242 KB)
      - 0x1FF80000 - 0x1FF8001F ( 1 Sector, 32 Bytes)
      - Start of restoring
      - End of restoring
      - Executing exit sequence ...
      - De-initialized successfully
      - Target erased, programmed and verified successfully - Completed after 8.551 sec
      Target erased, programmed and verified successfully - Completed after 8.551 sec
      Starting application ...
      - Disconnecting ...
      - Disconnected
      - Connecting via USB to J-Link device 0
      - J-Link firmware: J-Link V10 compiled Aug 27 2019 09:24:55
      - Device "STM32L151VC (ALLOW OPT. BYTES)" selected.
      - Found SW-DP with ID 0x2BA01477
      - Found SW-DP with ID 0x2BA01477
      - 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: 0x24770011)
      - Iterating through AP map to find AHB-AP to use
      - AP[0]: Core found
      - AP[0]: AHB-AP ROM base: 0xE00FF000
      - CPUID register: 0x412FC230. Implementer code: 0x41 (ARM)
      - Found Cortex-M3 r2p0, Little endian.
      - FPUnit: 6 code (BP) slots and 2 literal slots
      - CoreSight components:
      - ROMTbl[0] @ E00FF000
      - ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 002BB000 SCS
      - ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 002BB002 DWT
      - ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
      - ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 002BB001 ITM
      - ROMTbl[0][4]: E0040000, CID: B105900D, PID: 002BB923 TPIU-Lite
      - ROMTbl[0][5]: E0041000, CID: B105900D, PID: 002BB924 ETM-M3
      - Reset: Halt core after reset via DEMCR.VC_CORERESET.
      - Reset: Reset device via AIRCR.SYSRESETREQ.
      - Target application started

      A read back shows the option bytes as expected.

      So what went wrong here? Is setting the read protection in the option bytes causing a failure in the interaction of J-flash with the target?
      Any ideas?

      Thanks.
      Wim
    • Hi Wim,

      Update:
      Unfortunately we do not have a STM32L151VC to test right now, but it should be the same procedure on every STM32L151xx,
      so I tested to set the option bytes that you provided on a STM32L151VD and STM32L151CB device and it works flawlessly.

      The only issue with a block-verification error occurred when I tried to set the read protection (RDP) back to 0xAA (Level 0) through J-Flash.
      Setting the RDP back to 0xAA through a program-operation in J-Flash is not possible because writing 0xAA into that section triggers a mass-erase of the complete flash,
      so we just ignore it in that case.

      How did you managed to set this byte back to 0xAA through a program-operation in J-Flash?

      Furthermore do you use custom hardware
      or an evaluation board? In the latter case which one?
      If custom hardware, do you experience the same problem on an
      evaluation board?

      Best regards,
      Daniel
    • Hi Daniel,

      Thanks for you reply.

      We only could get the RDP back to 0xAA using STVP (ST Visual Programmer).
      We are using custom HW. We don't have an evalution board that is having an STM32L151VC. I need to check if we have something compareable...

      Best regards,
      Wim