[ABANDONED] Connect to Target acting strange

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

  • [ABANDONED] Connect to Target acting strange

    After "Connect to Target", the firmware appears to be running OK but the information in Ozone is strange. The system uses STM32 HAL which uses 'uint32_t uwTick' for system ticks (milliseconds). If I watch it live, it should increment at about 1000/second. It starts to do that, but then occasionally jumps to a strange number. It then changes back to the correct value as if it was still incrementing correctly. Each time it jumps to the strange number it is the same odd value. Other static/global variables in the system behave the same way. I use uwTick as a sanity check.
    We use STM32H743. The system has a bootloader as well. Trace is enabled via pins (J-Link Pro Cortex M). Trace has been working for a while now.

    I have narrowed this down to requiring an Ozone debug connection to the device after a power-cycle and before the bootloader starts the application. Once that is done, I can use Ozone to reset the application to main() and run from there. At this point, I can even give the device a user command to reset, and the bootloader will start the application (leaving the debug session running). I can exit the debug session and connect to targe and it works fine. Trace counters don't work when doing that, but the live variables look good. Performing a reset (F4) and restart from main() works fine. But if I disconnect and power-cycle it acts up again when I connect to target.

    Debugging in general has been working well for a few months now. This came about when I was trying to debug a .out file built on another system. We map appropriate paths for the .out file using Project.AddPathSubstitute().
  • Hi Blunce,

    to me the intention of your post is still a bit unclear. Could you please elaborate on what you do, what behavior you expect to see, what behavior you do actually see and where you are looking?

    Best regards
    -- AlexD
    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.
  • I am trying to connect to the running application after it has fully booted up.
    When I do that, the live watch variables display erratically. I expect to see live variables in the watch window to display predictably.
    I am not saying that I can never get this to work.
    It will work as expected if I am able to connect before the bootloader starts the application. This is only necessary after a power-cycle. Once it starts to work, I can connect and disconnect all day until another power cycle.
  • Hi Blunce,

    let me summarize what I took from your description: Ozone is connected to the target, target is running, watched data window is open and populated with a few variables, refresh rate is set to a value other than "Off". Ozone reflects the changes in those variables but sometimes a strange value is displayed which does not fit to the expected values. You see this only under the condition that Ozone connects to the target after the boot loader has executed. If Ozone connects in your delay loop, everything works as expected.

    Is that correct?

    Could you please have a look at the following articles in our WIKI?
    wiki.segger.com/Debug_on_a_Target_with_Bootloader
    wiki.segger.com/Ozone_detects_wrong_application_entry_point

    If the boot loader is not executed correctly or Ozone uses a wrong entry point the system may be in an invalid state and virtually everything can happen then.

    Best regards
    -- AlexD
    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.
  • What you have described is correct.

    SEGGER - AlexD wrote:

    Ozone is connected to the target, target is running
    I would clarify to say the method to connect is "Attach to Running Program" <F5> after a power-cycle. The application has been started by the bootloader before connecting. This is where the odd behavior starts.
    At this point (while connected in this odd state) reset the target via <F4> and it will startup and break at main() per usual. The bootloader does not execute with this kind of reset (or restart). Bootloader is not required to run before the application either. This should give a fresh clean start of the application. But after letting it run, the odd behavior continues.
    I checked the links you mentioned, and they don't appear to apply to this particular problem.
  • Hi Blunce,

    since you state that it works after adding the delay loop in the boot loader I assume you are using a low power mode in your system. Could you please disable all low power modes and check again?

    Background information: Some devices have a built-in debugger awareness which disables features that may interfere with debugging. Low power mode is one of those features. If the debugger is attached before that awareness check takes place, the features will be disabled. If the debugger is attached only afterwards the features are enabled and remain that way, thus interfering the debug session.

    For more information on low power mode debugging, please refer to wiki.segger.com/UM08001_J-Link…Guide#Low_Power_Debugging

    Best regards
    -- AlexD
    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.