[SOLVED] Can't connect to STM32G0 after setting read protection

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

  • [SOLVED] Can't connect to STM32G0 after setting read protection

    Hi all,

    I hope someone can help me with this issue. For a long time now, I have experienced an issue where after flashing a read protected program, J-link commander errors out trying to reset protection. To get around this, I have been using an ST-link debugger to reset the option bytes through another utility and then I can reconnect using the J-link debugger; however, this is pretty inconvenient as the ST-link debugger does not provide power so I have to use an alternate method for power the device.

    I've attached the response from the command window in J-link commander. If anyone knows why the STM32G0 is having an issue resetting the options bytes, please let me know. It has no problem connecting when the read protection is disabled.

    Also should note, I connect to the device over SWD using the recommended connections in the manual.

    Thanks!
    Images
    • Segger - stm32g031 connect error.jpg

      335.27 kB, 979×1,040, viewed 756 times
  • Hi,
    Thank you for your inquiry.
    Such an issue is not known to us.

    Could you tell us how you set the protection exactly and on which level?
    Are you using the latest version of the Software and Documentation Pack?
    The latest version is available here.
    Could you please send us a J-Link log file? How to enable:
    wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File

    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.
  • Thanks for the reply.

    To answer your questions:

    1) I set the RDP bits at level 1 protection (ie. read protection, mass erase will reset)

    pOBInit.OptionType = OPTIONBYTE_RDP;
    pOBInit.RDPLevel = OB_RDP_LEVEL_1;

    2) Yes, latest version V6.80c

    3) Log file attached
    Files
  • Hi,
    We will be looking into this as soon as possible.

    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,
    sorry for the delay in response.

    We were not able to reproduce the issue on a ST NUCLEO-STM32G031K8 evaluation board.
    Is it possible for you to provide us with a .hex file of the application you are flashing to the device?

    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.
  • No problem, thanks for getting back to me.

    I'm attaching a stripped down version of the code that retains the read lock instructions. I verified that it still has the same issue.

    Obviously, once it's flashed, you'll need to power cycle it once to execute the read lock and then on the 2nd boot-up, it should be locked.

    Please let me know if you discover an issue, I'm anxious to figure why this happens on this part series. We use another STM32F series part and it does not have this issue.

    Thanks
    Files
    • G0_RDP_test.hex

      (78.88 kB, downloaded 185 times, last: )
  • Hi,
    we are still not able to reproduce this issue:


    As a side note: For some reason we have to power cycle the device twice before OPTR shows RDP to be secured.
    It is recommended to set the OBL_LAUNCH bit after changing them to load the option bytes.

    To adjust for this case, we will improve our unlock sequence so it also unlocks the chip when the optionbytes RDP is set to locked, too, not only when OPTR RDP reads locked.

    Unfortunately, this does not seem to be the issue on your end, though.

    Could you provide us with a sample that makes this reproducible on an evaluation board?

    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.
  • Interesting, let me check on my end with a development board. We have an ST Nucleo board with the G0 I cant test to verify the same issue exists.

    I will also follow your suggestion on setting the OBL_LAUNCH bit to help reduce any other complications.

    I'll report back when I have more info, thanks.