[SOLVED] setting breakpoint in ISR in M4 on Vybrid SoC

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

  • [SOLVED] setting breakpoint in ISR in M4 on Vybrid SoC

    I'm working with Vybrid VF61x SoC, and debugging code on the M4 core running MQX.

    I would like to single-step some code in an ISR, and while I can set the break point and break into the ISR, after that the debugger seems gets stuck,
    I cannot resume the CPU or single step, and thus can only abort the session.

    I see JLinkGDBServer output on console as-if stuck in some infinite loop, tracing at fast rate as for e.g.:
    Read 4 bytes @ address 0x3F802804 (Data = 0x3F00062D)
    Read 4 bytes @ address 0x3F802804 (Data = 0x3F00062D)
    ....
    <repeat .... >

    I still can Cntrl-C it, and kill the connection to JLink and so the IDE's connection to the debugger luckily exists gracefully.

    Any idea what is going on? What is special setting I'm missing or way to enable setting a break point in an ISR here?

    :(
  • Hi,


    sorry for the delay in response.
    Could you provide a reproduction project (+ reproduction instruction if necessary), so that we can take a look at this issue?


    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,

    What is a reproduction project?

    Do you want me to send you an elf binary, and where to set the break point?

    Since original post, I have also tested with Ozone, which does not use Segger's GDBServer. Ozone, does not behave same, and looks like single breaks and allows to single step ISR just fine.

    I tend to think its the bug between the Segger's GDBServer and GDB client that causes the behavior I reported.
  • Hi,
    Since original post, I have also tested with Ozone, which does not use Segger's GDBServer. Ozone, does not behave same, and looks like single breaks and allows to single step ISR just fine.
    Good to hear that it is working with Ozone.
    Do you want me to send you an elf binary, and where to set the break point?

    It sounds to me that the issue seems the be generic (and not e.g. device / core specific), but it always does speed things up if we can reproduce the issue with the (full or stripped down) project of a customer. We happen to have a Vybrid VF61 eval board here.

    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.
  • SEGGER - Niklas wrote:

    Hi,
    Since original post, I have also tested with Ozone, which does not use Segger's GDBServer. Ozone, does not behave same, and looks like single breaks and allows to single step ISR just fine.
    Good to hear that it is working with Ozone.
    Do you want me to send you an elf binary, and where to set the break point?

    It sounds to me that the issue seems the be generic (and not e.g. device / core specific), but it always does speed things up if we can reproduce the issue with the (full or stripped down) project of a customer. We happen to have a Vybrid VF61 eval board here.

    Best regards,
    Niklas
    Hi Niklas,

    I have also described problem & how to re-create it, including which sample project from MQX can be used, on the NXP (ex Freescale) forum. You can get required details here:
    community.nxp.com/thread/428955 (Thread "Breakpoint in MQX ISR on Vybrid VF61x/M4 with Segger J-Link").

    The missing bits would be:

    I'm using toolchain from ARM Launchpad project, ver 4_9-2015q3. (but I think it's likely that later versions also have it, it's GDB<->SeggerGDBServer interaction)
    My Segger J-Link software package : 5.10o
    SEGGER J-Link GDB Server V5.10o Command Line Version
    JLinkARM.dll V5.10o (DLL compiled Feb 25 2016 18:53:09)

    I think, the issue is, with GDB client and GDB Segger server, possibly configuration.. I can't say these work very well for me. Kinda slaggish, break-points sometime don't work, re-sets seems sometime don't work, and the ISR problem as I posted about.

    Let me know if you want me to help you with the MQX project setup. (See the NXP thread above).
  • SEGGER - Niklas wrote:

    Hi,
    ....
    It sounds to me that the issue seems the be generic (and not e.g. device / core specific), but it always does speed things up if we can reproduce the issue with the (full or stripped down) project of a customer. We happen to have a Vybrid VF61 eval board here.

    Best regards,
    Niklas
    Niklas,

    Any update?
  • Hi,

    I'm suspecting the GDB client causing this behavior. Most likely the GDB client is permanently requesting data from 0x3F802804.

    I know that some versions of the GDB client are not able to do a correct stack backtrace, when the (Cortex-M) CPU stops in an
    event handler. In most cases, there is only some garbage displayed in the call stack window. Maybe in your special case the GDB
    client gets confused in a way, that leads to an endless loop. Such problems are very hard to reproduce, since they may depend
    on your *complete* application and the hardware.

    Could you please send us the part of the GDB server from hitting the BP to the first "Read 4 bytes @ address 0x3F802804"?

    Best regards
    Arne
    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.
  • SEGGER - Arne wrote:

    your *complete* application and the hardware.

    Could you please send us the part of the GDB server from hitting the BP to the first "Read 4 bytes @ address 0x3F802804"?
    Complete application is easy, as this is just based on the MQX example.
    What do you mean by the "part of the GDB server from hitting the BP" ? All I could see is the trace read 4 bytes..
  • v01d wrote:

    SEGGER - Arne wrote:

    your *complete* application and the hardware.

    Could you please send us the part of the GDB server from hitting the BP to the first "Read 4 bytes @ address 0x3F802804"?
    Complete application is easy, as this is just based on the MQX example.
    What do you mean by the "part of the GDB server from hitting the BP" ? All I could see is the trace read 4 bytes..
    Hi,

    the GDB server's log should look like this:

    Source Code

    1. Starting target CPU...
    2. ...Breakpoint reached @ address 0x00001010
    3. Reading all registers
    4. Removing breakpoint @ address 0x0000081C, Size = 2
    5. Removing breakpoint @ address 0x00001010, Size = 2
    6. Read 4 bytes @ address 0x00001010 (Data = 0xFDF4F001)
    7. Reading 64 bytes @ address 0x20005FC0
    8. Read 2 bytes @ address 0x00001010 (Data = 0xF001)
    9. Read 2 bytes @ address 0x00001012 (Data = 0xFDF4)
    10. Read 1 bytes @ address 0x00001010 (Data = 0x01)
    11. Read 1 bytes @ address 0x00001011 (Data = 0xF0)
    12. ...
    Display All

    I'm interested in the part between "Breakpoint reached @ address ???" up to the first read of the 4 bytes.

    Best regards
    Arne
    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.
  • Arne,
    I'm using latest JLink drivers now (GDB server), still same issue.
    This is the full trace from moment it's stuck and traces infinitely until I kill the debugger client.

    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 2 bytes @ address 0x3F00060A (Data = 0xB408)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 2 bytes @ address 0x3F000610 (Data = 0xB672)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 2 bytes @ address 0x3F000610 (Data = 0xB672)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 2 bytes @ address 0x3F00060A (Data = 0xB408)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 2 bytes @ address 0x3F000610 (Data = 0xB672)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 2 bytes @ address 0x3F000610 (Data = 0xB672)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 2 bytes @ address 0x3F00060A (Data = 0xB408)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 2 bytes @ address 0x3F000610 (Data = 0xB672)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 2 bytes @ address 0x3F000610 (Data = 0xB672)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 2 bytes @ address 0x3F00060A (Data = 0xB408)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 2 bytes @ address 0x3F000610 (Data = 0xB672)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 2 bytes @ address 0x3F000610 (Data = 0xB672)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 2 bytes @ address 0x3F00060A (Data = 0xB408)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 2 bytes @ address 0x3F000610 (Data = 0xB672)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 2 bytes @ address 0x3F000610 (Data = 0xB672)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 2 bytes @ address 0x3F00060A (Data = 0xB408)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 2 bytes @ address 0x3F000610 (Data = 0xB672)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 2 bytes @ address 0x3F000610 (Data = 0xB672)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 2 bytes @ address 0x3F00060A (Data = 0xB408)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 2 bytes @ address 0x3F000610 (Data = 0xB672)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 2 bytes @ address 0x3F000610 (Data = 0xB672)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 2 bytes @ address 0x3F00060A (Data = 0xB408)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 4 bytes @ address 0x3F000610 (Data = 0xBC08B672)
    Read 4 bytes @ address 0x3F00060C (Data = 0x4790B662)
    Read 2 bytes @ address 0x3F000610 (Data = 0xB672)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)
    Read 2 bytes @ address 0x3F000610 (Data = 0xB672)
    Read 2 bytes @ address 0x3F00060E (Data = 0x4790)
    Read 2 bytes @ address 0x3F00060C (Data = 0xB662)

    ..... < repeat, can't paste all, board doesnt allow > ....

    GDB closed TCP/IP connection

    :cursing: ?(
  • Hi,

    short note from my site:
    It is possible to upload the log file as a file attachment, which allows for larger log files than posting it as text.

    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,

    could you please post the log from before the moment it's stuck? The memory read commands are useless
    as they are being served correctly by the GDB server. There might be an error/misbehavior before, that leads
    to the endless loop in the GDB client. But chances are high that the server behaves correctly but the client
    misinterprets the data ending in the loop.

    Maybe you could try a newer version of your toolchain?

    Best regards,
    Arne
    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.
  • SEGGER - Arne wrote:

    Hi,

    could you please post the log from before the moment it's stuck? The memory read commands are useless
    as they are being served correctly by the GDB server. There might be an error/misbehavior before, that leads
    to the endless loop in the GDB client. But chances are high that the server behaves correctly but the client
    misinterprets the data ending in the loop.

    Maybe you could try a newer version of your toolchain?

    Best regards,
    Arne
    Hi Arne,
    I actually upgraded the toolchain just 2 days ago, movied to gcc 5.4.1 , gdb 7.10 (I believe ...).

    I need to try give you output you want, but I don't see any errors reporting before that, at least inside the Eclipse console window. Possibly it gets dumped elsewhere, may be I need to try
    command line
  • I also see now when it's stuck in this state (or loop) after hitting the breakpoint that Gdb traces the packet error.
    See below.

    Breakpoint 4, _int_unexpected_isr (parameter=0x3) at /devel/FSLMQXOS_4_2_0_2_GA_MQX_1_2/mqx/source/psp/cortex_m/int_unx.c:66
    66 _GET_KERNEL_DATA(kernel_data);
    Ignoring packet error, continuing...
    Ignoring packet error, continuing...
    Ignoring packet error, continuing...
    Ignoring packet error, continuing...
    Ignoring packet error, continuing...
    Ignoring packet error, continuing...
    Ignoring packet error, continuing...
    Ignoring packet error, continuing...
  • Hi,

    I just gave it a try using KDS, the original ISR example and a FRDM-K64F board.

    As I already assumed, this is caused by an erroneous behavior of the call stack backtracking. Although the GDB client when used by KDS does not enter an infinite loop,
    it shows _isr_execute() being called recursively by itself. Probably KDS sets some kind of a backtrace limit to avoid the infinite loop.

    I suggest you to report the problem to the GDB developers. Meanwhile you can try to set a backtrace limit for your GDB session as a workaround, this should avoid the infinite loop.

    Best regards,
    Arne
    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.
  • SEGGER - Arne wrote:

    ... infinite loop,
    it shows _isr_execute() being called recursively by itself. Probably KDS sets some kind of a backtrace limit to avoid the infinite loop.
    I suggest you to report the problem to the GDB developers. Meanwhile you can try to set a backtrace limit for your GDB session as a workaround, this should avoid the infinite loop.
    Hi Arne,
    I just gave this a go with just GDB, without IDE/Eclipse, and you right, I did backtrace call in GDB, and it is stuck on the infinite loop in _isr_execute().
    Thanks for your help, I will try set limit on the backtrace.

    I wonder why is this happening, probably ask GDB forum or file a bug.
  • Hi,

    maybe it has something to do with this bug report:
    bugs.launchpad.net/gcc-arm-embedded/+bug/1566054

    Best regards,
    Arne
    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.