Breakpoint in MQX ISR on Vybrid VF61x/M4 with Segger J-Link

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Breakpoint in MQX ISR on Vybrid VF61x/M4 with Segger J-Link

Jump to solution
5,261 Views
dry
Senior Contributor I

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 MQX 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.

And that's same/similar for any ISR I try.

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?

1 Solution
4,765 Views
CommunityBot
Community Manager
This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!

View solution in original post

0 Kudos
12 Replies
4,766 Views
CommunityBot
Community Manager
This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!
0 Kudos
4,767 Views
dry
Senior Contributor I

And that was a bug in GDB backtracing with ISR. It enters inifinite loops trying to find the caller. 

0 Kudos
4,767 Views
Carlos_Musich
NXP Employee
NXP Employee

Hi D.RY,

which MQX version and which IDE are you using?

Carlos

0 Kudos
4,767 Views
dry
Senior Contributor I

Hello Carlos,

MQX is 4.2, IDE is Eclipse. I do not think it's Eclipse related.

I'm using Segger J-Link Plus USB connection to connect over JTAG to the VF61x module.

I should try just loading & setting the same debug point without Eclipse, but I think it may have no effect.

0 Kudos
4,767 Views
Carlos_Musich
NXP Employee
NXP Employee

Hi D. RY.,

Please check the isr example in MQX installation folder (C:\Freescale\Freescale_MQX_4_2\mqx\examples\isr)

I am able to run this example without problem. Please let me know what changes I need to do in this project to get it to fail.

Regards,

Carlos

0 Kudos
4,767 Views
dry
Senior Contributor I

Hey  Carlos,

In my setup I have not used those examples you referring to. The ISR that I was trying to single step is the unexpected ISR handler.

To replicate my setup, you would need to _int_install_unexpected_isr() to install the MQX's special handler code (from int_unx.c), and

install a break point in it. And then trigger the unhandled interrupt, which should get you into the state i get.

One way to do this, as I have it, is to use the MQX's default I2C example code.  I'm using it with I2C0.

Install the unexpected ISR handler, and then trigger HW fault. Insert these two lines above first fopen call:

_int_install_unexpected_isr();

CCM_CCGR4 &= ~CCM_CCGR4_CG6(0x3);

fopen() will fail in its subcalls, on statement i2c_ptr->I2SR |= (QI2C_I2SR_IBIF | QI2C_I2SR_IBAL);

which then should put you into the ISR I tried to single step. But for me, once it in it, I cannot do anything with the debugger as described in original post. I also tried to install my own handler in it's place, with same result.

(Why would  I come up with such example is another story. ... But I'm curious about why the MQX's I2C init code doesn't check the required clocks are enabled).

0 Kudos
4,767 Views
Carlos_Musich
NXP Employee
NXP Employee

Hi D. RY,

Sorry for the dealy, I made the changes you told me:

From main task I called:

/* Install unexpected ISR*/

    _int_install_unexpected_isr();

    CCM_CCGR4 &= ~CCM_CCGR4_CG6(0x3);

    fopen("i2c0:", NULL);

Then I edited _int_unexpected_isr which is in int_unx.c:

void _int_unexpected_isr

  (

      void  *parameter

  )

{

        printf("Burger1");

        printf("Burger2");

        printf("Burger3");

        while (1);

}

I set a breakpoint and I was able to debug succesfully.

Please take in mind that after editing _int_unexpected_isr you must rebuild PSP library, if not so, you may be executing the infinite loop which was originally in this function.

If the problem persists please check in disassembly code what are you executing.


Regads,
Carlos

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
4,767 Views
dry
Senior Contributor I

Hi Carlos,

The _int_unexpected_isr for Vybrid in MQX 4.2 doesn't have infinite loop. The function is in file mqx/source/psp/cortex_m/int_unx.c.  The function, at least in my copy of the sources, starts with :

    KERNEL_DATA_STRUCT_PTR     kernel_data;

    TD_STRUCT_PTR              td_ptr;

    _GET_KERNEL_DATA(kernel_data);

    td_ptr = kernel_data->ACTIVE_PTR;

...... [etc ]

No loops.

I did verify I get into it if I set breakpoint anywhere inside it.

About your suggestion reading disassembly : well it shows that it's inside that function I've set breakpoint in.

The address that the GDB tracing (Reading) like mad, that address seems to point no where near that code however, and from disassembly at that address I couldn't easily see what is that address JLinkGDBServer constantly reading.

I have tried this with 2 different versions of GDB client, but same JLinkGDBServer. On one occasion, GDB crashed and reported bug/error.

I have tested debugging with Segger's own debugger software, Ozone. That doesn't seem to be using GDB and Segger's GDB Server.  And during the few times I tried to single-step that code with Ozone, I do no get the problem.

Which debugger are you using Carlos?  If its GDB + GDBServer , can you tell me the versions you have?


Thanks for help

0 Kudos
4,767 Views
Carlos_Musich
NXP Employee
NXP Employee

Hi D. RY,

The infinite loop is in the int-unx.c file for Cortex A5, not M4. I am sorry for the confusion. However I am still able to keep debugging when ISR is called, I am using IAR because I dont have a DS-5 license.

I wonder  if you are using DS-5 as you said you are using Eclipse. Please note that the only supported environments for Vybrid with MQX are IAR, DS-5 and GCC (command line). Pulling the GCC source to include it to your custom Eclipse is beyond our scope as we don´t have official documentation and haven't performed tests with such environment.

Regards,

Carlos

0 Kudos
4,767 Views
dry
Senior Contributor I

Hi Carlos,

Thank you for your reply.

Yes I'm not using DS5 (which is really Eclipse), but I'm using the GCC toolchain from Launchpad project project, as used by DS5.

However I understand this problem is outside of the scope of your support.

I think I best direct it to Launchpad or Segger.

4,767 Views
Carlos_Musich
NXP Employee
NXP Employee

Hi D. RY.,

Sorry for the delay.

I am trying to reproduce this behavior. Could you share a small code snippet to see how are you handling interrupts?

When you say you use Eclipse do you mean DS5?

Regards,

Carlos

0 Kudos
4,767 Views
karina_valencia
NXP Apps Support
NXP Apps Support

SergioSolis​ can you help here?

0 Kudos