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事件；

4.CarPlay Facets問題：在收音頁面播放收音，手機無線CarPlay連接，手機打開CarPlay Test APP，反復播放（Audio/Clicks）聲音，出現重啟問題；

凌陽處理，問題原因：在record流程控制邏輯有死鎖問題，如最后debug中看到卡住在writeDone的mutex，修改死鎖問題；