[ABANDONED] JLinkGDBServer cannot reset and halt the CPU, while Ozone can

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

  • [ABANDONED] JLinkGDBServer cannot reset and halt the CPU, while Ozone can

    When using the JLinkGDBSever on a bluenrg1 device, i cannot reset and halt the device. I can still break, but it's in the middle of my application.
    This does not always happen, but often enough to make this a major issue.

    I tried all possible reset strategies, from GDB, e.g.:
    > mon reset
    > mon reset 1
    > mon reset 2
    ...

    Most of them reset the device, but they don't halt the CPU.

    The weird thing is, Ozone seems to be able to recover from this situation (at least in many more cases).
    Also, is support for BlueNRG2 coming?

    Cheers!
  • Hi,


    we are currently not aware of any issues regarding J-Link + BlueNRG1.
    Would it be possible for you to provide us with a reproducer?


    The weird thing is, Ozone seems to be able to recover from this situation (at least in many more cases).

    What do you mean by "recover"?
    When using only Ozone, does it work without issues? (There is a reset & halt option in Ozone).

    Also, is support for BlueNRG2 coming?

    Well, lets wait until the evaluation board is available before I ask engineering about that :)

    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 Niklas,

    Thanks for the answer.
    1. What do you mean by a reproducer? An elf file that causes this kind of issue? It seems to be very irregular, and (it seems) usually happens when using some of the low power modes of the device (sleep/standby).
    2. By "recover" i mean, ability to halt, step, flash, ... the target. Any useful debugging steps :)
    3. I know it's a bit early, but BlueNRG-2 eval board should be available from ST: st.com/content/st_com/en/produ…ards/steval-idb008v1.html
    Also, thanks a lot for always being *very* up to date with the latest MCU's. It's one of the many reasons I really like the J-Link products!

    BR,
    Maxime

    The post was edited 1 time, last by maximevince ().

  • Hi Maxime,

    What do you mean by a reproducer? An elf file that causes this kind of issue?


    Yes, this is what I meant.

    It seems to be very irregular, and (it seems) usually happens when using some of the low power modes of the device (sleep/standby).

    This could be expected behavior. It depends on the device and low power mode used, but it is possible that the debug connection is lost when the device enters low-power mode, and the debugger can not do much about it.

    You can make the J-Link software more relaxed about temporarily connection losses by executing the following J-Link command string:
    LowPowerHandlingMode = 1

    I know it's a bit early, but BlueNRG-2 eval board should be available from ST

    On the bottom of the site, you can see the the board currently can neither be ordered from ST nor from a distributor.


    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.
  • I understand that I cannot debug when the device is sleeping in standby/sleep mode.
    However, it should be possible to correctly reset and halt the device, which should allow me to re-flash the device, or step from main() again, ...
    Or is this a wrong assumption? This works with all other Cortex-M devices I work on...
  • Hi,

    However, it should be possible to correctly reset and halt the device, which should allow me to re-flash the device, or step from main() again, ...
    Or is this a wrong assumption? This works with all other Cortex-M devices I work on...

    This depends on the target device
    -> Reset & halt via SFR access might be not available when target device is in low power mode
    -> Reset & halt via Reset pin + SFR can work but only if the application does not enter a low power mode before the halt request via SFR is issued

    You can make the 2nd option work reliable by adding a delay at the start of the target application.

    Does connect / reset work in commander if you are holding the reset button?

    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,

    Thanks for the explanation.
    It works in JLinkExe (e.g. for flashing a new image) when holding the reset button, indeed.

    So, I should make sure my application does not go to sleep too soon, such that I can halt and debug in time, after resetting or powering on the device?
  • Hi,

    It works in JLinkExe (e.g. for flashing a new image) when holding the reset button, indeed.

    This means it should be possible for us the implement a connect under reset for BlueNRG1. I will bring this up for discussion at the next team meeting.


    So, I should make sure my application does not go to sleep too soon, such that I can halt and debug in time, after resetting or powering on the device?

    Yes, this
    a)
    is a good ("best") practice in general, since it makes sure you have time to connect to the device during development of the application. Therefore, you can always be sure that a simple mistake or typ0 in the pin configuration does not brick you hardware permanently.
    b)
    should work automatically with J-Link. Since Reset & Halt via SFR access does not work, J-Link will reset via reset pin as a fall back and then issue a Halt request as soon as it can connect to the device.
    A delay before the start of the target application will make sure J-Link can connect & halt before the device enters a low-power mode.

    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,


    does it work for you when using the most recent J-Link version?


    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.