软件工程师眼中的M02180（续）

前言
2018年，我光知道，当客户对M02193的A2上半页的A2[38h…5Bh]区域（就是通过地址复用模式保存着M02193的BiasCurrent告警阈值和DDM内部校系数的存储区），在重写A2上半页的DDM阈值和8472内校系数时，会把M02193的BiasCurrent告警阈值和DDM内部校系数写坏掉，原因请参考本文第1.3章节。但我一直没有想明白，为什么海外客户自己把A2上半页的A2[38h…5Bh]区域写坏了，我们作为光模块原厂却不能让客户在本地自行修复，而是必须要客户从海外寄回来然后我们回炉重新生产一次？因为很明确的，A2[38h…5Bh]区域被写坏，并不会影响硬件和通讯业务，无非是从软件上会看到光模块上报的BiasCurrent告警阈值和DDM采样值比较怪异而已。那我们研发是不是可以写一个手动软件，让客户可以进行手动DDM校准，将写坏了的A2[38h…5Bh]区域满血恢复回来，这样就不用活生生地给客退回来返工费时费力了呢？但我的这个想法在第一时间就被当时的研发给否了。
我斗胆回溯，根本原因就是商业公司的内卷盛行，即第一个实现M02193的DDM校准的上位机代码的工程师，大概率没有向第三方主动分享过，如何对M02193进行DDM校准从而得到正确的内校系数。当然客观原因也不容忽视，即M02193的DDM校准，确实被芯片原厂搞得过于复杂了，天坑不是一般的深，连参考资料都难以直接获取，以至于原厂不惜在datasheet上写上这样一段话：“Calibration of the monitors is described in detail in a separate document available from you MACOM sales representative.”
是年，我光知道我们家基于M02180（其寄存器构架与M02193几乎如出一辙）的XGSPON ONU光模块在海外某客户处测试NG，这就是我当年起草《软件工程师眼中的M02180 20180503.doc》的初衷，我同时很想知道是不是我们对M02180的哪个寄存器没有配置正确？
但显然以我当时处在一个销售的身份上，并没有完成对M02180的全部认识。而且同年稍晚点我家的XGSPON ONU光模块在国内某客户处也测挂了，也始终是没有得到研发的全力支持，总之躺平摆烂就这样了。直到五年后今天，经过近期与初出茅庐的Ellen一番共同学习和实践，看似已经初步具备了这个能力，顺带针对M02193的一个夙愿也终于可以了结，遂有本文《软件工程师眼中的M02180（续） 20230528.docx》。
不卷，主动给身边同事指一条活路，这应该是一个老研发的基本修养罢？