Breakpoint Stopped But no Indication in MCUXpresso11.1.1

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

Breakpoint Stopped But no Indication in MCUXpresso11.1.1

2,094 Views
zhiqunhu
Contributor III

I have a K64 project with multi-task using FreeRTOS, I noticed that some of tasks I can make BPs and step into it for debugging and MCUXpresso works properly, but some of the tasks I can make BP and the SW execution will stop at the BP but there is no any indication at all, so I am not able to do anything. I am using Tera Term to monitor system working condition so I know how the system is working.

If I suspend the program running (clicking the yellow double-bar button), I will get a warning of "Interrupt failed". At this point, if I click on Task List for Kernel Awareness, there is nothing come out. There is no interrupt handling in these tasks and it happens repeatably 100% even with single BP in the project.

pastedImage_2.png

Figure 1. Normal BP setting

pastedImage_1.png

Figure 2. Task stopped with not indication

0 Kudos
9 Replies

1,776 Views
zhiqunhu
Contributor III

After finished preliminary testing and debugging of my project on a brand new custom board, I am able to investigate the BP No Indication issue further, and here is the update:

First thing I have done was to check all the static tasks in the project to see which ones were having the issue, the result indicated that there were only two tasks presented the issue. For the two tasks, one handles most of IOs in the system and another one handles all the control related activities, they were the most important tasks in the system and had higher priorities than rest of the tasks, and they were the tasks that I really needed to use Breakpoints and Step-Through functionalities for testing and debugging. With the assistance of a set of terminal VT100 screens and a log system I developed, I was able to finish the testing and debugging the project.

 

Compared the two tasks with the rest from implementation aspect, nothing standout, then I looked over the task properties, noticed these two tasks have priorities 11 or 14,  while other no issue tasks had their task priorities lower than or equal to 10.

 

In FreeRTOSConfig.h file, I had defined the MAX task priority(configMAX_PRIORITIES) as 16, so I can set task priorities between 1 to 15 in the project. As I had seen in the debugging and testing, all the tasks, including the two tasks with the given task priorities, worked just fine. Please refer to the screenshot attached:

pastedImage_4.png

Note: The runtime is recorded as a task has waken up and done something.

pastedImage_3.png

Note: task 7 is an event driven task, it is only idle in normal operation.

 

For testing purpose, I lowered the priorities of the two tasks to 9 or 10, and found out the BPs set in these tasks worked just fine.

 

Also, I imported a couple of SDK projects, and changed their MAX priority level to 16 and changed the task’s priority level to 15, and found they both worked fine without the BPs issue seen in my project.

 

These two tasks are the tasks that use periodic timer plus event driven to wake up, I thought the issue may be related to the timer’s interrupt level priority, so I changed the priority of a no issue task which is waked up by event only,  the testing shown the issue existed. So it is only related task's priority.

The magic number 10 seems to me are related to project setting in MCUXpresso, but cannot find anything related to that.

For now with the IDE and PE Multilink, I can set the tasks’ priority to 10 or less for debugging if I need to, then recover the tasks priorities later.

0 Kudos

1,776 Views
nxf63973
NXP Employee
NXP Employee

Hi  Zhingun Hu

 

Could you please let me know if you still have any issues with the breakpoints?

 

Thank you very much for your feedback, it is very useful for us, and we will take a look at this behavior and try to replicate it further.

0 Kudos

1,775 Views
zhiqunhu
Contributor III

The issue still exists and I do not know its root cause. I only figured out it is related to the task priority and know how to get it around in testing and debugging.

0 Kudos

1,776 Views
nxf63973
NXP Employee
NXP Employee

Hi Zhingun Hu,

 

Unfortunately, so far we haven't been able to replicate it exactly, but we will take a deeper look at this issue, and try it further.

 

I'm sorry for the inconvenience this may cause.

 

Best regards

0 Kudos

1,776 Views
zhiqunhu
Contributor III

Hi Jose,

Could you share with me on how did you try to replicate the issue and on what kind of project? As I mentioned in my previous email, I had tried on two sample projects from SDK, to raise the task priority to >10 but the issue did not surface.

Also, I never got an answer on why the message " Interrupt failed" showed up when I tried to suspend it? Can you try to explain it?

And do you have any idea on why the system runs fine but you just cannot use IDE to debug it, and only for the tasks that have higher priorities.

Regards.

0 Kudos

1,776 Views
nxf63973
NXP Employee
NXP Employee

Hi Zhiqun Hu

Could you please let me know which tasks are the breakpoints not stopping the program?

Is your code based on an existing MCUXpresso SDK example?

Regards

Jose

0 Kudos

1,776 Views
zhiqunhu
Contributor III

HI Jose,

The issue is MCUXpresso has no indication when it stopped by a BP, sometimes. All breakpoints stop the program but some of them are working correctly so I can do stepping into the code, and executing code, and checking RTOS working conditions, other breakpoints did stop the code execution but without any indication. If you try to suspend the program a message "Interrupt failed" popping out, so you cannot do anything, such as  stepping in or continuing execution, just like SW crash. Only way to get out of it is to reload the project and restart.

If I do not make BPs at the area which I know BPs are not working, all tasks run properly without any issue. And my observation is the conditions are very consistent, repeatable.

The project is not from existing MCUXpresso SDK example, but ported from KDS and updated with MCUXpresso.

Regards.

0 Kudos

1,776 Views
nxf63973
NXP Employee
NXP Employee

Hi Zhingun Hu

 

I have done tests in RTOS examples of the MCUXPresso SDK for an FRDM-K64F. I have placed breakpoints in many parts of the projects' code and so far I have not seen any issues.

 

To know the source of this problem, it would be very helpful if you could share your project. If you can't do it, which is perfectly understandable, could you please consider sharing another project that presents the same behavior?

 

Regards

Jose

0 Kudos

1,776 Views
zhiqunhu
Contributor III

Hi Jose,

 

I do not expect you can replicate the issue based on the simple RTOS example projects of FRDM-K64F from SDK.  


My project is very heavy on IOs, it will not work properly in FRDM-K64F board without significant modification even I can share the project with you.

 

I believe to trace down the root cause, you need to use the information described in my previous email to figure out:

1. at what condition "Interrupt failed" message will be generated, if it is not related to a HW interrupt (the task and function may not related to any HW interrupt), is it related to a SW interrupt and why?

2. why it is related to BP, why when the code execution hit the BP that causes IDE not working properly?

 

I was thinking it may related to IOs configured and used in my project, in one of my test, I disable all the IO interrupts but I still experienced the same issue. And apparently the issue is related to not only tasks but functions level as well. I tried with the functions that demonstrate the issue in a task that it cannot stop at the BP, then I tried to call the function from another task that have BP work properly, the function causes the same issue in the working task.

 

Based on the tests I have done, the code execution seems working fine if no BPs are set. Apparently it is only related to IDE in some weird combinations.

 

Why the issue is happening in some projects but not in other projects, my suspicion is it maybe related to project setup and configuration, maybe related to IOs in certain way but have no solid evidence.


Regards.

0 Kudos