Cant connect to NUCLEO-H743ZI using JLink firmware on the OB ST-Link

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

  • Cant connect to NUCLEO-H743ZI using JLink firmware on the OB ST-Link

    Hello,

    I used STLinkReflash_170807 to reflush the OB ST-Link with JLink firmware. The process looks successful , but when i try to connect to the board using AC6 IDE, i get a message saying the board is not connected.

    Has anyone tried this procedure with NUCLEO-H743ZI, i read that reflushing works great for people, but this is a new product by ST, so not a lot of stuff on the web yet....

    Thanks,
    Evgeny
  • Hi Evgeny,


    a NUCLEO-H743ZI board is on its way to us, but will not arrive before the end of next week.
    Once we get our hands on it, we will give it a try.


    In the mean time, could you give J-Link Commander a try and post a screenshot of its output?

    Best regards,
    Niklas
    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 Evgeny,

    Niklas asked me to take over.
    I just tried to connect to a STM32H743I-EVAL board with a regular J-Link Plus probe and had no issues whatsoever.
    The Nucleo Board is still on its way so i will test it once it arrives.
    In the meantime do you have an external J-Link debug probe that you could try out?

    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.
  • Hi Nino,

    I do have an Ultra+ probe, i have succeeded loading the firmware to the board using it, but it seems as it disconnects from the board a short time after. Same code runs without disconnecting with OB ST-Link.
    The thing is that the Nucleo board does not have a dedicated JTAG/SWO socket for external probes. So after reading ST's document and searching the ST forum, i had to remove two solder bridges - SB110, SB111, and connect the probe to the board using several single wire straps.

    Jlink NUCLEO-H743ZI
    pin1 CN8 - 3v3
    pin4 CN6 - pin3 == GND
    pin7 CN4 - pin4 == SWDIO
    pin9 CN4 - pin2 == SWCLK
    pin15 CN8 - NRST

    This is why i was hoping to get use JLink over ST-Link, to eliminate user error in modifying/connecting the board.

    Thanks,
    Evgeny
  • Hello Evgeny,

    We just received a brand new Nucleo-H743ZI.
    I reflashed the ST-Link with the same utility you have used and was able to connect to the target device without any issues (screenshot attached).
    Did you change any default jumper settings when using the OB?
    I do have an Ultra+ probe, i have succeeded loading the firmware to the board using it, but it seems as it disconnects from the board a short time after.

    The disconnecting is rather odd. Can you try and erase the target device memory and try to connect to the target with the OB?
    Could you try reflash the ST-Link FW and then again the J-Link OB FW?
    Do you have another eval board to try? Yours might be in some way defective.

    Best regards,
    Nino
    Images
    • Capture.PNG

      36.86 kB, 671×684, viewed 634 times
    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 Nino,

    It looks like this issue has something to do with the IDE or application code. I reflashed the board by reverting back to STLink firmware, and using the STM32 ST-Link utility erased the flash, updated it back to JLink and connected using J-Link Commander without any issues.

    Tried running my code again using the AC6 IDE, and got the board into the same problematic mode. Completely reproducible every time i try. Tried the same code with TrueStudio, and it worked well. This was all done using the OB STLink/JLink.
    So i will do some more investigation on what is causing the OB to malfunction.


    Thanks,
    Evgeny
  • Hello,

    My findings so far are, if i use the STM32CubeMX tool to generate a simple project with FreeRTOS enabled, the system works as expected using both ST-Link and JLink firmwares on the OB debugger.
    But if i enable the tickless idle mode for FreeRTOS, the ST-Link firmware works as expected, while using JLink firmware starts giving me "Connecting to target...WARNING: Identified core does not match configuration. (Found: Cortex-M0, Configured: Cortex-M7)" after the first time i load my code on to the board. And i start getting unexpected interrupts.
    I tested it with "empty" projects, that only do initialization and create two empty tasks.

    What got me confused at the first place is, if i use AC6, than it would refuse to load the code after this error. But if i use TrueSTUDIO, it will give me the error but will still load the code, but then i start getting unexpected interrupts......

    If i dont enable tickless idle feature, the JLink firmware for OB debugger works great! Including systemview and jscope.

    Thanks,
    Evgeny

    The post was edited 2 times, last by evgeny_erlihman ().

  • Hi Evgeny,

    Thank you for the detailed analysis.
    But if i enable the tickless idle mode for FreeRTOS, the ST-Link firmware works as expected, while using JLink firmware starts giving me "Connecting to target...WARNING: Identified core does not match configuration.

    The problem with most tickless mode implementations is that it enables low power modes on the target device.
    This leads to disabling the debug interface. That is why J-Link throws an error as it is no longer guaranteed that the debug interface is still available and that the target device state is known.
    ST-Link might work through pure luck or some special handling that ST has implemented. But usually a debug probe can't debug a target reliably anymore after a low power mode has been triggered.

    What got me confused at the first place is, if i use AC6, than it would refuse to load the code after this error. But if i use TrueSTUDIO, it will give me the error but will still load the code, but then i start getting unexpected interrupts......

    This depends highly on how the J-Link has been implemented into the IDEs. It sounds linke TruStudio suppresses the actual target debug state from the J-Link so J-Link still tries to download the application even though it does not know the state the target device is in.

    So to be able to debug your tickless mode application make sure all low power modes or other modes that alter the debug interface are not part of your application and add them later (if needed) when your application is functioning as expected.

    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.
  • Hi Nino,

    The default tickless idle does not go into deep sleep states, so usually JLink is able to work with it just fine. From what i observe, once a tickless idle app is loaded on the target using OB with Jlink firmware, the target/OB gets into a state that even if i try to load an app without tickless idle i would still observe the same error. The only way to fix it, for me, was to revert back to ST-Link firmware, erase flash and upgrade to JLink firmware again.

    Thanks,
    Evgeny
  • Hi Evgeny,

    Could you provide the example project so i can try to reproduce the issue?

    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.
  • Hi Nino,

    Attached two projects, they are based of the same cube project with one difference - enabled/disabled tickless idle mode.
    The only manual change in the code was to increase the delay time for both tasks for the MCU to actually go into tickless idle.
    The projects are generated with STM32CubeMX 4.23.0 for SW4STM32 IDE.

    The not working project will create the issue on the first time it runs. So you will observe the issue starting from the second load attempt.

    Thanks,
    Evgeny
    Files
  • Hello Evgeny,

    Sorry for the delay in response.
    The default tickless idle does not go into deep sleep states

    This statement is not true for the projects you provided.
    The function prvIdleTask() calls portSUPPRESS_TICKS_AND_SLEEP which enables sleep mode when tickless mode is enabled.

    Currently we do not do any special connect handling for the H7 like we do for other ST devices like the L4 series (that is why it works here).
    We will see how and if it can be implemented for the H7 series as well.

    Would you like to be added to the J-Link software update notification list,
    so you get informed automatically when the new version becomes available?
    Subscribe here: segger.com/notification/subscribe.php?prodid=7,94

    Then you will be notified about the latest release notes and can directly see if the H7 tickless handler has been implemented.

    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.
  • Hi Evgeny,

    We are currently pretty much packed with paid projects until the end of the year.
    So a very rough estimate would be earliest end of Q1 2018.
    Should that not be fast enough you have the option to implement the reset handler per J-Link Scriptfile yourself.
    As basic debug support for the H7 is already given you only need to overwrite the default Reset behaviour for that device.
    You can do that with the ResetTarget() function described in the J-Link User manual in the Scriptfile chapter.
    More information about how to include the Scriptfile can be found here: wiki.segger.com/Adding_Support_for_New_Devices

    Examples for other devices can be found in the J-Link installation folder under Devices/.

    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.