Post Go back to editing

Debugging with breakpoints and expressions

Thread Summary

The user is experiencing issues with hardware breakpoints in effect modules on a SHARC core architecture, specifically with breakpoints on core1 breaking in core2 and breakpoints not working in core2. The solution involves ensuring the debugger is correctly targeting the core when placing breakpoints and using a step-by-step approach to validate function call paths. Additionally, the user inquired about using dynamic printf for real-time logging, but UART-based logging through PuTTY is recommended to avoid performance issues.
AI Generated Content
Category: Software
Product Number: SHARC Audio Module
Software Version: 3.0.2

Hello,

I am trying to debug some effect modules I have made using the built-in ADI modules as a reference. For now, I am attempting to set breakpoints and step through the built-in source files to see what I should be expecting. I have a few questions regarding the debug session. Note that all my modification to the ADI source files I mention below are working, the debugging is the only confusing part here.

1. When setting hardware breakpoints in for example effect_stereo_flanger.c core 1 inside of the read function, the program breaks at the same line, but in core2. This is confusing since the flanger is handled in core1.... Now for core2. I rearranged the core2 processing within audio_effects_selector.cpp so that it works exactly how core 1 works. I tried setting hardware breakpoints in the effect_stereo_reverb.c source file in both cores, but neither are breaking the program. Curious how I should be setting breakpoints so that I can debug for each core. I've tried clicking on core1 in the debug tree to direct debugging to core 1, but that did not make a difference. Some of the breakpoints I have made show up in the picture here:

 

2. All of the ADI effect modules have code that is helpful for debugging. An example of that is the result enumerations. What is the easiest way to use the expression tool in the debugger to view the enum return results of functions.

I am new to the SHARC core architecture and am having a tough time wrapping my head around all this. I appreciate your time and patience.

Thanks,

Teylor

Parents
  • Continuing the debug questions, can a dynamic printf be used? Would be nice to have real-time logging without interrupting the code. If so, how can this be used?

  • Another update. I read through the startup code to see how I could send data serially and view through PuTTY. Came up with this bit of code to throw in the header files of interest:


    and just use the one line of code in my implementation file to display whichever message I want. The only thing I'm worried about with this solution is that it will slow down the program and potentially drop audio frames if I use too many.

    Is this a viable solution?

    Teylor

  • UART-based logging (through PuTTY) is generally much faster and more suitable for real-time systems than using printf via the debugger because it can significantly stall the processor, especially when printing large or frequent messages. To further reduce overhead, it's best to log only critical events and buffer messages in memory, sending them during idle CPU cycles before it overflows. This ensures that logging does not interrupt the main processing flow or compromise system performance.

    Regards,

    Aradhita

Reply
  • UART-based logging (through PuTTY) is generally much faster and more suitable for real-time systems than using printf via the debugger because it can significantly stall the processor, especially when printing large or frequent messages. To further reduce overhead, it's best to log only critical events and buffer messages in memory, sending them during idle CPU cycles before it overflows. This ensures that logging does not interrupt the main processing flow or compromise system performance.

    Regards,

    Aradhita

Children
No Data