1. 程式人生 > >slvi驅動除錯總結

slvi驅動除錯總結

Slvi驅動除錯總結
本篇是繼音訊基本知識介紹後,4G專案中除錯過程中遇到的一些問題總結


好奇是進步的原動力 
目錄
Slvi驅動除錯總結        1
1 模擬spi通訊問題        3
2 msleep和mdelay        3
2-1 系統資源        3
2-2 時間控制精度        3
3 I2C通訊問題        4
3.1 I2C位傳輸        4
3.2 開始和結束訊號        4
3.3 I2C應答訊號        4
3.4 I2C寫暫存器        4
3.5 I2C讀暫存器        5
4 定時器使用        8
5 中斷上下兩部問題        9
6 nau8810晶片pcm資料,si_3217x晶片中注意事項        10



1 模擬spi通訊問題
Spi 是 Serial Peripheral interface的縮寫,即序列外圍裝置介面。
通訊介面包括,
MISO:主裝置資料輸入,從裝置資料輸出。Master input,Slave Output
MOSI:主裝置資料輸出,從裝置資料輸入。Master Output,Slave Input
SCLK:時鐘訊號,由主裝置產生
CS:從裝置片選訊號,由主裝置控制。當從裝置的片選被拉低的時候,才能從SPI總線上獲取資料資訊
根據SPI被配置成主或者從模式,MIMO和MOSI引腳的功能會自動改變,實現傳送和接收的切換
遇到問題:
使用模擬spi讀寫暫存器,資料異常。寫的資料不對。
問題排查:
模擬spi 讀寫reg後需要一個delay的時間,否則讀寫資料會異常。

2 msleep和mdelay
它們都有延時的作用,但是有很大的區別:
2-1 系統資源
mdelay 佔用cpu資源,其他功能此時無法使用cpu
msleep 不佔用cpu資源,其他功能模組可以使用cpu

2-2 時間控制精度
Mdelay時間控制是精確的,可以到ms級別,例如mdelay(2),則實際等待也是2ms
Msleep時間控制刻度已10ms為單位,例如msleep(2),實際要休眠10ms以上。因為呼叫的執行緒會休眠,休眠10ms後,依據執行緒優先順序,可能依然不能立刻執行,所以,一般會大於10ms。

遇到問題:
Spi延時中分別使用mdelay和msleep,效果完全不同,使用msleep載入驅動的patch,速度非常慢。更換mdelay後,速度快了,但是會消耗更多的cpu資源。

3 I2C通訊問題
I2C協議,2條雙向序列線,一條資料線SDA,一條時鐘線SCL。
3.1 I2C位傳輸

資料傳輸:SCL為高電平,SDA線若保持穩定,那麼SDA上為傳輸資料bit;若SDA跳變,則 表示回話結束或開始。



3.2 開始和結束訊號
開始訊號:SCL為高,SDA由高相低跳變,開始傳輸資料

結束訊號:SCL為高,SDA由低相高跳變,結束傳輸資料



3.3 I2C應答訊號

Master每傳送完8bit資料後等待Slave的ACK。即在第9個clock,若從I2C發ACK,SDA會被拉低。若無ACK,SDA會被置高,這會引起Master發生RESTART或STOP流程,如下圖:



3.4 I2C寫暫存器
1.    Master發起START
2.    Master傳送I2C addr(7bit)和w操作0(1bit),等待ACK
3.    Slave傳送ACK
4.    Master傳送reg addr(8bit),等待ACK
5.    Slave傳送ACK
6.    Master傳送data(8bit),即要寫入暫存器中的資料,等待ACK
7.    Slave傳送ACK
8.    第6步和第7步可以重複多次,即順序寫多個暫存器

9.    Master發起STOP



3.5 I2C讀暫存器
1.    Master傳送I2C addr(7bit)和w操作1(1bit),等待ACK
2.    Slave傳送ACK
3.    Master傳送reg addr(8bit),等待ACK
4.    Slave傳送ACK
5.    Master發起START
6.    Master傳送I2C addr(7bit)和r操作1(1bit),等待ACK
7.    Slave傳送ACK
8.    Slave傳送data(8bit),即暫存器裡的值
9.    Master傳送ACK
10.    第8步和第9步可以重複多次,即順序讀多個暫存器


遇到問題:
主控裝置通過I2C寫NAU8810 codec的時候,發現寫進去的值和讀出來的值不同。向暫存器寫如 0x15D,示波器抓圖如下, 見圖 3-5-1:


讀出來的值暫存器如下:

Read 總圖 見圖3-5-2


Read 分解圖3-5-3

讀出來的值是0x101,後來排查才發現I2C寫資料沒有按照晶片的協議處理,上面介紹的是通用協議,但是不同的晶片廠商可能不同。例如nau8810晶片:
Nau8810 I2C寫reg協議如下:

注意:此處資料是9位的而暫存器只有7位,資料為的最高位放在了control Register Address傳輸。發現這一點問題就解決了。

4 定時器使用
除錯過程中遇到一個問題:上層設定生成ACK的握手音,波形要求如下:

首先生成1400Hz的tone音 100ms,然後停止100ms,再生成2300Hz的tone音100ms。問題的難點在於在1400Hz的tone音和2300Hz的tone音時間間隔要求為100ms,偏差在上下3%。如果上層做這個任務,控制的精度達不到要求。所以在底層使用定時器處理,使用方法:
1、        註冊定時A
init_timer();
2、註冊任務佇列B
        INIT_WORK();
3、        新增定時器
Add_timer();
當定時器時間到後,會執行軟中斷中向定時器註冊的function,在此function中排程任務佇列中的函式,任務佇列完成不同的需要功能。

5 中斷上下兩部問題
又想讓中斷服務程式儘量快地執行,同時又想讓程式完成儘可能多的工作,這兩個目標顯然是有矛盾的,基於這樣的矛盾,我們把中斷服務程式劃分為兩個部分:上半部(top half)和下半部(bottom half)。
1,        上半部:接收到一箇中斷就馬上開始執行,具有嚴格的時限要求,比如 對硬體裝置的響應和對硬體進行復位,這些工作都是在所有中斷被禁止 的情況下完成的。中斷服務程式是上半部。
2,下半部:沒有特別嚴格的時限要求,允許稍後完成的工作被劃分到下半部來做。一般來說中斷服務程式返回的時候會立刻執行下半部。
中斷活動的全過程大致為:copy from:http://cache.baiducontent.com/c? ... 2b000179ca&p1=1
1、中斷請求:中斷事件一旦發生或者中斷條件一旦構成,中斷源提交“申請報告”,與請求CPU暫時放下目前的工作而轉為中斷源作為專項服務
2、中斷遮蔽:雖然中斷源提交了“申請報告”,但是,是否得到CPU的響應,還要取決於“申請報告”是否能夠通過2道或者3道“關卡”(中斷遮蔽)送達CPU(相應的中斷遮蔽位等於1,為關卡放行;反之相應的中斷遮蔽位等於0,為關卡禁止通行);
3、中斷響應:如果一路放行,則CPU響應中斷後,將被打斷的工作斷點記錄下來(把斷點地址保護到堆疊),掛起“不再受理其他申請報告牌”(清除全域性中斷標誌位GIE=0),跳轉到中斷服務子程式
4、保護現場:在處理新任務時可能破壞原有的工作現場,所以需要對工作現場和工作環境進行適當保護;
5、調查中斷源:檢查“申請報告”是由哪個中斷源提交的,以便作出有針對性的服務;
6、中斷處理:開始對查明的中斷源進行有針對性的中斷服務;
7、清除標誌:在處理完畢相應的任務之後,需要進行撤消登記(清除中斷標誌),以避免造成重複響應;
8、恢復現場:恢復前面曾經被保護起來的工作現場,以便繼續執行被中斷的工作;
9、中斷返回:將被打斷的工作斷點找回來(從堆疊中恢復斷點地址),並摘下“不再受理其他申請報告牌”(GIE=1),繼續執行原先被打斷的工作

中斷服務子程式中:
A、中斷程式不能向用戶空間傳送或者接收資料
B、不能做任何可能發生休眠的操作,wait_event,或者 鎖住訊號量
C、不能呼叫schdule函式.
中斷中不能讀寫spi裝置,可以放在中斷下半部做spi讀寫的操作。
1、        上半部要求儘量快,增加系統的吞吐量。
2、        下半部一般有軟中斷、tasklet、工作佇列等處理方法。

6 nau8810晶片pcm資料,si_3217x晶片中注意事項
問題 nau8810有噪音:
問題分析:噪音的原因是4線的pcm有兩條是資料線,一根dataIn,一根dataOut, 由於沒有載入中控的音訊模組,hisi主控沒有配置內部codec,有髒資料直接輸出到codec,導致噪音問題.
解決方法:直接關閉nau8810的pcm 資料輸入/輸出模組的電源。

問題 si3217x中問題:
1、        生成2300Hz tone音問題。
按照晶片廠商提供的軟體生成2300Hz的tone音是不對的,軟體計算中有問題。後續按照手冊中提供的公式,手動計算出應該配置到暫存器的值。具體演算法程式碼中有描述,不再贅述。

2、        配置ram暫存器
嚴格按照晶片手冊提供的方法配置該ram暫存器,程式碼中有詳細的描述,不再贅述。另外就是74號reg暫存器的配置,技術支援給的值不太對,需要修改成程式碼中的值。
3、        疑惑的問題
關於中斷暫存器17、18、20 reg暫存器的用法,現有程式碼是直接從mtk平臺繼承過來的,諮詢過技術支援,沒有解釋清楚,後續可以瞭解清楚。