[SOLVED] Flash verification fails on STM32G071RB

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

  • [SOLVED] Flash verification fails on STM32G071RB

    I'm using SEGGER j-link BASE Compact connected through CN11 on my NUCLEO-G071RB development kit.
    I've successfully flashed and debugged my board many times but today flash verification failed and after that I can't connect to it anymore.
    A similar problem happened once before on another unit and there I concluded that the flash was write protected through the option bytes and it wasn't possible to unlock it.
    I'm afraid the same thing has happened again with this board.

    Attached are the logs from JLinkExe in the case when this problem occurred as well as the working case.
    After power cycling the board I can't even connect to it:

    #########################

    $ JLinkExe -device STM32G071RB -if swd -speed 4000 -autoconnect 1

    SEGGER J-Link Commander V6.62a (Compiled Jan 31 2020 12:58:00)
    DLL version V6.62a, compiled Jan 31 2020 12:57:49

    Connecting to J-Link via USB...O.K.
    Firmware: J-Link V10 compiled Jan 7 2020 16:51:47
    Hardware version: V10.10
    S/N: 820101846
    License(s): GDB
    VTref=3.335V
    Device "STM32G071RB" selected.

    Connecting to target via SWD
    STM32 (connect): Can not attach to CPU. Trying connect under reset.
    STM32 (connect): Can not attach to CPU. Trying connect under reset.

    ****** Error: STM32: Connecting to CPU via connect under reset failed.

    STM32 (connect): Can not attach to CPU. Trying connect under reset.
    STM32 (connect): Can not attach to CPU. Trying connect under reset.

    ****** Error: STM32: Connecting to CPU via connect under reset failed.

    Cannot connect to target.
    #########################


    My operating system is Ubuntu 18.04

    Thanks in advance!
    Files

  • Hi,
    Thank you for your inquiry.

    Could you please make sure, that the Reset pin is connected to the J-Link?
    It is necessary to perform a connect under reset which might help in your situation.

    Best regards,
    Fabian
    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 Johan,
    I just took a look at your logs.

    The log files indicate, that your assumption with the protection level is probably correct.
    I noticed that in one case, you flashed to the regular flash area (0x80000000) and in the other you flashed to the option bytes area (0x1FFF7800).
    Is this intended?
    If not, could you please provide us with the command file you use to flash the data?
    Was it the exact same command file in both cases?
    Was it the exact same data file in both cases?

    Best regards,
    Fabian
    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 Fabian,

    The command I use is always

    JLinkExe -CommandFile flash_stm3232g071.jlink

    and the file flash_stm3232g071.jlink was included in the zip-file together with the logs.


    Unfortunately the bin file that was used in the erroneous case is not available anymore.

    Do you think a corrupt bin-file could be the problem here?


    Perhaps I should add the location where to flash the bin file just to be sure?


    loadfile out/example_low_power.bin, 0x80000000

    I see now that we use loadfile instead of loadbin, what's the difference between the two?


    Best Regards,

    Johan

  • Hi Johan,
    Sorry I somehow skipped the command file.

    .bin files do not contain information about the location the data is to be written to (in contrary to .hex files).
    It seems that the .bin file was therefore flashed to the option byte area, which locked the chip and made it unreachable via debug excess.

    "loadbin" is very much recommended to use here, because providing a flash download address is mandatory.
    "loadfile" assumes an address when a .bin file is provided and no address is specified.
    So under special circumstances the bin file was downloaded to the option byte area, which locked up your device.

    Both commands will work, and the issue should not reappear as long as you specify a download address for your bin file.
    That is why loadbin would be the recommended command to use in your case.

    Does this answer your question?

    Best regards,
    Fabian
    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 Fabian,

    Thank you for this information.
    I think I know how to avoid bricking any more development kits :)

    One last thing. Could the reason why the bin-file was flashed to another location than 0x80000000 be this line in the log for the erroneous case:

    Device will be unsecured now.

    What would trigger this?

  • Hi Johan,
    what happens when loading a .bin file without pointing out an address is not specified.

    The message "Device will be unsecured now." shows up when the J-Link detects activated protection for a device and started the unsecure procedure.
    Since locking the device is done by setting option bytes, this message would show up after the option bytes changed, so in your case when data was flashed to the option bytes area.
    The .bin file is flashed into the option byte area, when the data is small enough to fit into it.
    Since the option byte area is very small, this is only happening very rarely in your scenario.

    But again, the behavior in such a chase is not specified, and therefore not defined.

    I will discuss internally, if we want to change the current behavior, so that .bin files wont be accepted without an address when using loadfile, just like loadbin.

    Do you have any further questions?

    Best regards,

    Fabian
    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.