大家好，我是痞子衡，是正經搞技術的痞子，今天痞子衡給大家分享的是i.MXRT1060上LCD橫向漸變色顯示出亮點問題的分析解決經驗，
接上篇《一個關于LCD屏顯示出例外亮點的故事(上)》咱們繼續聊，上一篇發出之后，大家在我的微信公號文章下面留言很熱烈，大部分朋友都把懷疑點放在了HyperRAM時序配置上，覺得很大概率是HyperRAM的資料訪問出了問題導致了LCD顯示例外，這個懷疑是非常合情合理的，那么從高效定位問題的角度，我們接下來應該怎么做？
一、問題分析
讓我們回到上一篇的最后，痞子衡列出了所有可能出問題的地方，我們現在需要將這些疑點逐一排除：
- 客戶LCD顯示測驗代碼邏輯是否有問題？
- 客戶LCD屏與i.MXRT1060連接（線序）是否有問題？
- 客戶LCD屏的ST7701S驅動移植（從STM32到i.MXRT1060）是否有問題？
- 客戶選用的HyperRAM本身質量是否有問題？
- i.MXRT1060配置的客戶HyperRAM時序引數是否有問題？
- i.MXRT1060的LCD顯示模塊eLCDIF驅動是否有問題？
- i.MXRT1060系統的總線處理（如Cache、總線競爭）是否有問題？
這些懷疑點總結下來就是兩類，一類是硬體問題（如2、4），另一類是軟體問題（如1、3、5、6、7），痞子衡覺得應該從軟體疑點先下手，因為從現象上看，硬體上基本沒啥大問題，LCD是能夠按代碼設計那樣去顯示的，而且硬體問題檢查起來（可能涉及改板子或者焊接，萬一整壞了板子...）不如驗證軟體問題來得快，等軟體疑點初步排除了，再找硬體問題也不遲，
確定了從軟體疑點下手，那么從哪一個開始呢？當然是大家都認為最可疑的點 - HyperRAM時序配置問題這點先入手，不過直接去檢查HyperRAM時序配置較為繁瑣，我們有更好的選擇，uint32_t s_frameBuffer[480][480]總大小為900KB，這小于i.MXRT1060內部RAM總空間（1MB），所以我們完全可以將這個frameBuffer鏈接到內部RAM里來規避HyperRAM時序配置問題（疑點5）以及系統總線處理問題（疑點7），另外我們還可以直接用J-Link修改內部RAM里的frameBuffer資料來規避客戶測驗代碼邏輯問題（疑點1），為了方便地生成frameBuffer資料，我們還需要寫個簡單的Python腳本，那么我們先嘗試用這一套方法在LCD上顯示一個真實風景照吧，
Note: 這套驗證方法的最大好處是高效且省時，不需要在App代碼工程里改frameBuffer相關代碼以及一次次地重新編譯下載，
二、開始測驗
2.1 將frameBuffer鏈接到內部RAM里
2.1.1 重配FlexRAM
首先是需要在App工程的startup_MIMXRT1062.s檔案里修改Reset_Handler代碼，增加FlexRAM重配代碼，因為默認RAM配置是128KB ITCM, 128KB DTCM, 768KB OCRAM，我們要將其調整為1MB OCRAM，
__iomux_gpr16_adr EQU 0x400AC040
__iomux_gpr17_adr EQU 0x400AC044
__flexram_bank_cfg EQU 0x55555555
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Default interrupt handlers.
;;
THUMB
PUBWEAK Reset_Handler
SECTION .text:CODE:REORDER:NOROOT(2)
Reset_Handler
CPSID I ; Mask interrupts
;新增代碼（開始）
LDR R0,=__iomux_gpr17_adr
MOV32 R1,__flexram_bank_cfg
STR R1,[R0]
LDR R0,=__iomux_gpr16_adr
LDR R1,[R0]
ORR R1,R1,#4
STR R1,[R0]
;新增代碼（結束）
LDR R0, =0xE000ED08
LDR R1, =__vector_table
; ...
2.1.2 調整MPU設定
然后我們要在App工程的board.c檔案里修改BOARD_ConfigMPU()函式，增加如下代碼，確保全部1MB OCRAM地址空間(0x20200000開始)都是non-cacheable屬性，
/* Region 6 setting: Memory with Normal type, not shareable, non-cacheable */
MPU->RBAR = ARM_MPU_RBAR(6, 0x20200000U);
MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 1, 0, 0, 0, 0, ARM_MPU_REGION_SIZE_1MB);
2.1.3 修改鏈接檔案
最后我們要在App工程的main函式源檔案里將s_frameBuffer放在一個自定義的.frameBuffer段里，以便在App鏈接檔案里將其放到OCRAM地址空間里（0x20200000 - 0x202FFFFF），
main函式源檔案中的修改：
__no_init uint32_t s_frameBuffer[APP_IMG_HEIGHT][APP_IMG_WIDTH] @ ".frameBuffer";
App工程鏈接檔案中的修改：
define symbol m_data2_start = 0x20200000;
define symbol m_data2_end = 0x202FFFFF;
define region DATA2_region = mem:[from m_data2_start to m_data2_end];
place in DATA2_region { section .frameBuffer };
2.2 撰寫Python腳本生成frameBuffer資料
2.2.1 風景圖片資料
我們可以從網上找一張.jpg格式圖片，將其尺寸裁剪到480x480，然后借助Pillow里的Image庫將其轉成XRGB8888格式的binary檔案，對應Python腳本（腳本名為convert_jpeg_to_xrgb8888.py）用法和源代碼如下：
import sys, os
import argparse
from PIL import Image
class ConvertJpegToXrgb8888(object):
def __init__(self):
pass
def _read_options(self):
parser = argparse.ArgumentParser(formatter_class=argparse.RawDescriptionHelpFormatter)
parser.add_argument("-o", "--output", required=True, metavar="PATH", type=argparse.FileType('wb'), help="Specify the output file.")
parser.add_argument("input", help="JPEG Image file."),
return parser.parse_args()
def run(self):
args = self._read_options()
imgObj = Image.open(args.input)
pixelBuf = imgObj.getdata()
for i in range(len(pixelBuf)):
for j in range(len(pixelBuf[i])):
args.output.write(chr(pixelBuf[i][len(pixelBuf[i]) - j - 1]))
args.output.write(chr(0))
args.output.close()
if __name__ == "__main__":
exit(ConvertJpegToXrgb8888().run())
2.2.2 RGB測驗資料
此外我們還需要一個腳本，能夠很容易地修改生成指定的RGB測驗資料，用于定位亮點問題，對應Python腳本（腳本名為generate_xrgb8888.py）用法和源代碼如下：
import sys, os
import argparse
class GenerateXrgb8888(object):
def __init__(self):
pass
def _read_options(self):
parser = argparse.ArgumentParser(formatter_class=argparse.RawDescriptionHelpFormatter)
parser.add_argument("-o", "--output", required=True, metavar="PATH", type=argparse.FileType('wb'), help="Specify the output file.")
return parser.parse_args()
def _make_xrgb8888(self, r, g, b):
return chr(b) + chr(g) + chr(r) + chr(0)
def run(self):
args = self._read_options()
for i in range(160):
for j in range(480):
args.output.write(self._make_xrgb8888(j%256, 0, 0))
for i in range(160):
for j in range(480):
args.output.write(self._make_xrgb8888(0, j%256, 0))
for i in range(160):
for j in range(480):
args.output.write(self._make_xrgb8888(0, 0, j%256))
args.output.close()
if __name__ == "__main__":
exit(GenerateXrgb8888().run())
2.3 使用J-Link將frameBuffer資料更新進OCRAM
2.3.1 顯示風景圖片
我們從網上隨便找一張風景圖片scenery.jpg，使用convert_jpeg_to_xrgb8888.py腳本將其轉換為scenery.bin，然后將J-Link仿真器掛上芯片，成功連接之后，使用loadbin scenery.bin 0x20200000命令將圖片資料下載進內部RAM，
這時候你可以看到LCD的顯示變成了圖片：
2.3.2 顯示RGB測驗資料
從上一節測驗的真實圖片顯示效果上看，似乎看不出明顯的亮點問題，這說明亮點在特定RGB資料內容顯示的時候才會顯現出來，那么我們現在的任務就是要找到這個顯現條件，這時候需要修改generate_xrgb8888.py腳本來反復做實驗，
所以痞子衡就不斷地修改腳本、生成資料、下載資料，功夫不負有心人，痞子衡找到了亮點復現規律，
三、原因分析
痞子衡發現的亮點規律是當橫向某兩個連續漸變像素點RGB任一分量出現多bit由1向0跳變時（比如前一個像素點B分量是8'b01111111，后一個像素點B分量是8'b10000000），則后一個像素點必是亮點，這個亮點像素點最終顯示的B分量極可能變成了8'b11111111，
所以分析下來應該是DCLK信號的極性設定在屏的驅動IC和i.MXRT1060的eLCDIF模塊里不匹配，RGB資料線采樣時機錯了，導致實際顯示的RGB資料發生了錯誤，
在SDK的elcdif_rgb example里關于eLCDIF模塊信號輸出的極性設定如下，這里需要注意的是kELCDIF_DriveDataOnRisingClkEdge是置1（即上沿資料輸出，下沿資料保持的意思），
#define APP_POL_FLAGS (kELCDIF_DataEnableActiveHigh | kELCDIF_VsyncActiveLow | kELCDIF_HsyncActiveLow | kELCDIF_DriveDataOnRisingClkEdge)
這是i.MXRT1060 eLCDIF極性配置相關：
這是OTA5180A芯片的默認極性配置時序圖：
SDK里的極性設定與i.MXRT1060-EVK標配的LCD屏（RK043FN02H-CT）里的驅動芯片OTA5180A默認配置是相吻合的，
我們現在再來看看SDK里的極性設定與客戶LCD屏的驅動芯片ST7701S的極性配置是否匹配，客戶設定了ST7701S的IM[3:0]狀態為4'b1010，即RGB模式輸出，且PCLK是下沿資料輸入，上沿資料保持（Latch），因此跟SDK里的極性設定是反相的，
所以最終的解決方法就是要么將ST7701S的IM[3:0]狀態設為4'b0010，要么在App代碼里將APP_POL_FLAGS定義改用kELCDIF_DriveDataOnFallingClkEdge，
歡迎訂閱
文章會同時發布到我的 博客園主頁、CSDN主頁、微信公眾號 平臺上，
微信搜索"痞子衡嵌入式"或者掃描下面二維碼，就可以在手機上第一時間看了哦，
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/9879.html
標籤：嵌入式