我使用的是 S32DS 3.6.3使用 S32 调试探针在 S32R47 硬件目标上调试 KQ8 DSP 内核。在对 KQ8 应用程序进行单步调试（C HLL 步进，而非汇编指令步进）时，调试器会进入汇编代码的意外部分，最终卡住，系统挂起，需要重新启动。
我附上了一些奇怪行为的截图，似乎调试器开始步进 Xtensa C-runtime 设置或库代码，这在 HLL 步进模式下是不应该发生的。
我还附上了一段屏幕录制视频，显示了具体发生的情况。
客户（Hella/Forvia）报告了这一问题，他们正在寻求恩智浦的指导，请解释这一行为并建议如何避免。
提前感谢！
Gary
你好@GaryRK、
这确实是一个 S32 调试器问题，是由调试器内部设计的源步进和调试模块中的 KQ8 架构特性造成的。更确切地说，S32 调试器在源步进时是指令步进和运行到内部 bp 的混合。从设计上讲，KQ8 上的 Asm 步骤正在触发一个由调试模块处理的异常，但是如果同时触发另一个异常，则该异常将保持未处理状态，这就是这里发生的情况。我们也可以在劳特巴赫调试器上重现该错误，但使用的是指令步进模式。我们将想办法解决这个问题。在此之前，解决办法是尽可能在函数中使用 SW 断点。
此致，
亚历山德拉
附上用于重现问题的 S32DS 项目
你好，丹妮拉、
在使用具有正确 SRAM 区域定义的修改/自定义 gdbio-stacklocal LSP 时，问题仍然存在。我从我的同事马克那里拿到了改良版，我想这是你们团队做的。无论如何我都附上了它以供参考。
我认为这个问题是 S32 调试探针而不是 KQ8 可执行文件特有的。它似乎无法只执行 C/HLL 步进，并在 Xtensa 操作系统派生的汇编代码中卡住/丢失，这些代码看起来像函数序幕/前导和堆栈管理。
我所附的截图显示了一个例子：我正在步进程序，当输入一个常规的 C 函数时，调试器在一个奇怪的、意想不到的地方停止了 KQ8 的运行。
顺祝商祺！
Gary
嗨，加里、
你遇到的问题很可能与 LSP 有关，S32DS 从 KQ8 核心配置中重复使用 LSP，其定义的 SRAM 大小为 64M 而不是 8M。为了防止这种行为，你可以手动编辑 LSP，也可以使用专用的代码包工具（例如 Xtensa Explorer）生成这样的 LSP。
顺祝商祺！
达妮埃拉
如果有人见过这种情况，能否请您承认这里确实存在问题，以便我向海拉/福维亚提供一些初步反馈？我们每天都要与客户开会，他们要求我们提供最新信息。
谢谢！
Gary
由于没有收到客户的反馈，因此关闭此问题。