1541_AURIX_TriCore内核架构_内核调试控制器CDC

全部学习汇总： GitHub - GreyZhang/g_tricore_architecture: some learning note about tricore architecture.

这一份笔记可能会是我近段时间来最后的一份内核学习笔记了。我看了下内核手册分为上下两部分，而下卷主要的内容其实是讲解指令集，而我之前也看了一个开篇。后续，下卷作为查询的工具书或许会更合适。而上卷的内容，除了这次的信息之外剩下的全都是寄存器的描述。因此，可能看完这部分之后基本上就暂时结束内核架构的了解了。

1. 内核调试控制器主要还是MCDS的模块功能，这个在不同的单片机上实现可能是不同的。

2. 使能CDC的实现方法也是有可能不同的，但是看上去似乎全都是通过寄存器的使能位来实现。

1. 单步调试这么看还是一个硬件上实现的一个功能。

2. 内核寄存器的修改可能会导致调试行为的触发。

3. 这个笔记中我记录的这一条疑问，其实到了后面有了答案了。其实，断点的处理既可以触发trap也能够支持中断，而且中断中有传统也有高级玩法。

1. 外部的调试事件的产生不需要任何指令，但是可能会消耗几个时钟周期来识别。

2. 软件调试指令需要CDC支持，这让我想到了gdb等调试工具，类似工具的实现是否是通过这种方式实现？

3. 相比于调试事件，内核寄存器的读写优先级其实更高。

1. 这里犯了一个错误，原本以为这个调试可以专门调试MCU的上下文相关的功能。读到后面，其实debug有自己专门的上下文管理。

1. 调试时间可以通过地址加事件两个属性来决定。

2. 几种调试事件在MCDS部分中大概也是介绍过的，类似。

3. 12.3.2看上去是一个高级功能，可以指定特定任务访问一个地址的情况的处理。但是这里有点好奇，这个是否是需要修改软件呢？

所有的累加信息，其实是一个阶段性的累加信息。第一次读取的是启动后到读取时候的累加信息，而后续则是两次读取之间的累加信息。

这里这个寄存器应该是类似上次上下文寄存器的作用，记录了上一次的信息。后面，我看到了相关的解释。

1. 在halt模式下，外部的调试系统可以检查单片机内部的信息。

2. 断点trap不使用任何用户资源，其实这个涉及到了前面疑惑过得上下文，因为debug上下文有专门的寄存器以及存储来实现。

1. trap不使用用户资源的原因这里做了解释，其实还是有相应的寄存器以及存储资源支持。

1. 默认情况下，调试trap不会发生。

2. 调试中断允许在调试的时候，依然保持关键代码的运行。

3. 早期的MCU调试系统设计很多时候是直接实现了一个最高优先级的中断来实施的。

让架构同时支持优先级高于debug的中断以及低于debug的中断，这算是一种更高级的用法，可以支持的应用场景更多。

这个call tracing其实是值得调用的过程的追踪而不是MCU支持的高级调试功能trace，这个开始的时候看着疑惑了一阵子，主要还是因为理解偏了。

这样，整个内核架构的部分基本就算是过完了。后面，还是回到MCU了解本身上。