Sept. 14

一早醒来，阳光的颜色很好，照在对面的阳台上，一种因温暖而舒服的感觉——虽然天有点热。

看到米兰上周五的信，他们发现内存分配有矛盾的地方。确认是七月底写信告诉他们需要做的修改，里面误拷了份过时的内存分配。下午米兰修改发过来，往返修正了一下，DSP启动成功。加班测’rmd_handle’修改后的诊断，发现有问题。半夜米兰发来对应重构的DSP平台的image。

Sept. 15

一早确认是硬件问题导致诊断失败，写信问Harri能否就此freeze。

开始把重构代码的’RBV’上传、集成。由于昨天的image没有提供线索查NO_BUF_END_MARK，推动Echo那边在重构代码上做集成测试，看NO_BUF_END_MARK是否重现，是的话，在此基础上调。催申请新的image名称。

Sept. 16

上午重新检查、测试了’rmd_handle’的代码，催Harri同意freeze。问增加VCI范围的问题——这是A12中sRIO改进部分的连接切换，标哥希望在’RBV’中顺手做掉。’RBV’的TR作者Ari从MXU APP容量角度反对。

修改重构的单元测试，让加入’RBV’修改后能过，下一步还需要加入’RBV’相关的测试用例。与DSP平台联调，发现无法启动：RMD waiting for enquiry。怀疑他们用的内存分配不对。

Sept. 17

一早发信给米兰指出内存分配不对。下午Cartoon那边问重构后的RMDEXT命令，我也没用过，看代码猜着告诉他们。断断续续地改重构RMD上的’RBV’。晚上又收到米兰那边改过的image。

Harri今天关注于’rmd_handle’，临下班时又发来测试版本，加入了查找packet forwarder ack中没有’rmd_handle’的问题。于是开始调，还是没有，加入的调试信息也看不到。中间Harri又发过来两个版本，还老样子。搞到九点，决定明天手动敲命令来看。Harri怀疑是我的测试环境有问题。

Sept. 18

一早来测了一下昨晚发来的DSP平台image，看来启动了，但RMDEXT却挂了。上午全组检查本sprint进度，问到’rmd_handle’，否定了我就这么放进去的想法，一定要把packet forwarder的解决掉。午饭后手动测’rmd_handle’，于是发现了错误原因——测错了。我错误地开了一个开关，于是DSP平台收不到消息，而我监控到的只是RMDEXT回的假消息。感觉很丢脸，写信向Harri道歉。他仍然关心诊断，又抓了一下clog和p2d消息，他确认真正诊断成功。

RBV仍然不行，确信是DSP platform那边仍旧为IFC打开Rx连接，临下班开始反复写信向他们说明这一点。

‘clp’很滑稽地再次开始，半个月转了一圈信件，最后发现9月1日我给编的image正在使用中。