4778：我的BUG噩梦
问题描述：
DAB播放中关ACC掉电后开ACC，手动切到FM/AM(有时第一次切换出现问题/有时第二次切换出现问题)，FM/AM不记忆关ACC前电台或者FM/AM关ACC掉电后开ACC，手动切到DAB再回到FM/AM，FM/AM不记忆切换前的电台
前提纪要：
1、车载系统上，有一个功能叫做DAB link功能，DAB link的功能是在DAB播放时，会提前让FM后台进行搜台当前DAB电台相关的FM电台（在DAB link中，如果搜到MCU上报的电台状态，我们不去处理原来的FM列表），目的是为了让当前DAB电台在信号不好时，可以去切到FM按照要求搜索到的电台；
2、收到MCU上报的电台搜索状态之后，我们会把FM的旧列表清除等待上报新的电台；
3、用户手动切到FM的时候，需要恢复FM最后播放的电台（而不是后台link搜索到的电台）
4、此功能只针对FM，不针对AM，当从AM切到DAB时，他是不需要进行link的；
问题详细过程：
1、从2024.1.17 被客户发现，提出问题；
2、2024.1.20，被我的同事认为该BUG是设计如此，因为DAB link了，后台进行搜台，切换到FM时，SOC会下发stop，导致MCU停止搜台，MCU停止搜台了以后，就是会出现不记忆以前的电台的情况；
3、2024.2.26，被客户指派回，客户回复，其他项目无此问题；
4、2024.3.8，同事处理，已解决； 于2024.3.15被客户激活，验证NG； 随后此问题一直留存，没有解决，客户也没有出货了；
5、2025.2.25，由我解决，我和同事沟通，同事说已经处理过了，可以给客户验证一下； 于2025.3.10被客户激活，验证NG；
6、2025.3.20，由我主管进行处理，我主管说已经整合了这个修改，让客户验证； 于2025.3.20被客户激活，验证NG；
7、2025.4.15 由我仔细分析，我回复给客户，我们认为不是问题，回复了详细描述
8、2025.4.18，客户不接受，和我们公司的另一位MCU主管沟通，认为是一个BUG；
9、2025.4.19 由我进行解决，我参考了其他项目组的做法，增加了一个dab sourcestop ，增加记忆标志位； 于2025.5.6被客户激活，验证NG；
10、2025.5.20，由我再次进行解决，我仔细分析log，发现在我们切去FM时，我们发送了记忆的电台值，但MCU停止了，我增加了一个补发记忆值； 于2025.6.5被客户激活，验证NG；
11、2025.6.16，由我再次进行解决，我仔细分析log，客户NG的原因是FM->DAB->AM->DAB->FM，导致FM记忆的台再进入DAB时会被清除，导致出现问题，增加了一个区分FM、AM的不同存台（实际这一步已经多余，因为AM 不需要link，没必要存台） 于2025.6.27被客户激活，验证NG；
12、2025.7.3，由我再次进行解决，我仔细分析log，发现客户又找到了新手法，ACC掉电后，会把我们这个临时变量的值进行清除，我需要把电台值放在flash进行保存 于2025.7.10被客户激活，验证NG；
13、2025.7.18，再次分析log，发现DAB切到FM的时候，触发了AM Link 导致出现了问题；即我之前提到的，AM根本不需要link；
未完待续，持续更新....
CarPlay相关BUG
1.无线CarPlay连接，手机拿远，wifi远距离断开，回到车机附近后，需要进行回连；
2.无线CarPlay连接上后，概率出现无ID3信息问题，无专辑图片问题；
3.无线CarPlay连接，概率出现虚连，AP层只收到了attached的事件，但是没有收到CarPlay Session建立成功；导致现象是CarPlay图标高亮了，但一直点击不进去CP画面，过30秒左右之后才会收到Detached事件；
