展讯7731C平台LED显示异常的解题历程

2023-11-02 10:10

本文主要是介绍展讯7731C平台LED显示异常的解题历程,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

1、异常现象
内部测试报:插入充电器灭屏充电,待休眠后会出现红绿灯交替变化的情况。
简单调试后发现,其实有两个问题:
1》写led驱动节点控制异常问题
。 无法通过 adb shell echo 255 > /sys/class/leds/red/brightness 方式控制红绿灯变化
2》充电休眠红绿灯交替闪烁问题
。无法抓到出异常时候的uart log,好像交替变化的时候led驱动根本没执行!

2、led驱动背景知识
1、原理图 & uboot pinmap配置


PIN 配置参考:
xxx_SCH_V0.1_DDR2_2016.08.31.pdf
SC7731C_GPIO_Spec_V1.4.xlsx
pinmap.pptx
pinmap-sp7731.c

比如 LED_G_EN是管green灯的PWM控制脚(使用PWM才可以调节LED亮度),查看原理图对应的脚是GPIO234,那么查GPIO Spec:


所以看到 GPIO234对应pinmap中的是 TRACEDAT2,也就是这个:

解析: GPIO234,AP端配置 ,驱动能力1级(6mA),选择功能1(PWMC),wakeup弱下拉,sleep模式弱下拉(70k欧),输出方向。

参考pinmap的官方配置文档
Pinmap 是系统在启动之后,uboot对芯片pin脚进行初始化的配置信息表。
Pinmap 里面包括IO的:
1.Function 功能选择(Function0~3)
2.上下拉设置(WPD,WPU,X)
3.驱动能力设置(DS0~3)
4.sleep时的上下拉设置(WPD,WPU,X)
5.sleep时的输入输出设置(Input,Output,Hiz)
6.强上拉的设置(WPUS,X)
7.AP或CP的sleep控制—AP+CP架构(AP,CP0~CP2)
8.其他(PIN_ctrl0~3)

WPU-IO的上拉电阻,一般在70K,会随着电压的降低增大。
WPD-IO的下拉电阻,一般在70K,会随着电压的降低增大。
WPU和WPD用于普通IO的有上下拉需求的配置。
WPUDS-IO的强上拉电阻,一般在4.7K,会随着电压降低增大,用于SIM_IO,I2C,RF_SDA,SDIO,EMMC等协议需要的的方。
一般被配置成强上拉的,也会被配置成弱上拉,这个一般没什么影响。




2、dts配置
sprd_pwm_led {
compatible = "sprd,sprd_pwm_led";
reg = <0x40260000 0xf>; /* PWM寄存器基地址(PA) */
brightness_max = <255>; /* 最大亮度级别 */
brightness_min = <0>;
led_hw = <0x3>; /* 选择需要的RGB */
pwm_index = <1 2 0>; /* 绿灯:PWMC, 红灯: PWMB */
gpio_ctrl_pin = <0>;
gpio_active_level = <0>;
};
reg <0x40260000>是PWM的物理地址,可以从datasheet中找到

这里PWMB ==> 0x40260020, PWMC ==> 0x40260040 ,下面是代码中的运算:
通过iormap方式映射到一段VA空间:
pdata->sprd_pwm_base_addr=(unsigned long)ioremap_nocache(res.start,resource_size(&res));
计算偏移:
brgb->sprd_pwm_base_addr = pdata->sprd_pwm_base_addr+brgb->pwm_index * 0x20;

led_hw需要解析下,到底是什么意思,为什么要这么配置,先看解析出的代码干了什么?
首先将dts解析到pdata->led_hw中:
ret = of_property_read_u32(np, "led_hw", &pdata->led_hw);
下面是关键的过滤机制:
for (i = 0; i < SPRD_LED_TYPE_TOTAL; i++) {
if(!( pdata->led_hw & BIT (i/2)))
continue;
...
pdata->led_hw = 0x3 ==》 0011(b)
SPRD_LED_TYPE_TOTAL 是一个led的枚举的MAX:
enum sprd_led_type
{
SPRD_LED_TYPE_R = 0,
SPRD_LED_TYPE_R_BL,
SPRD_LED_TYPE_G,
SPRD_LED_TYPE_G_BL,
SPRD_LED_TYPE_B,
SPRD_LED_TYPE_B_BL,
SPRD_LED_TYPE_TOTAL
};
所以:BIT(i/2) ==> BIT(0/2),BIT(1/2),BIT(2/2),BIT(3/2),BIT(4/2),BIT(5/2),
==>BIT(0),BIT(1),BIT(2)
& 0011(b)
所以到这里就很明显了,其实就是选择前面两个bit:R & G,过滤掉 B

3、基本驱动流程
上面简单介绍一些调试的背景知识,现在简介驱动实现流程,总的来说led驱动算是很简单的,代码: android@ubuntu:~/work/prj/7.0-2514/kernel$ xfind leds-sprd-pwm.c
./drivers/leds/leds-sprd-pwm.c
linux 驱动当然是从类似module_init中入口的了,这里之前wen@有详细讲解流程,就不多详细介绍了,从probe开始简单介绍:
1》probe流程
。解析dts配置 : sprd_pwm_led_parse_dt
。遍历配置好的led,为每个led结构(struct sprd_leds_pwm_rgb *brgb)申请一块内存:
brgb = kzalloc(sizeof(struct sprd_leds_pwm_rgb), GFP_KERNEL);
。填充PWM的index: brgb->pwm_index = pdata->pwm_index[i/2];这里对应的是PWMB,PWMC
。指定clk源: brgb->clk = clk_get(&pdev->dev, pwm_clk_name);
。计算当前led硬件的地址偏移 &填充操作回调:
brgb->sprd_pwm_base_addr = pdata->sprd_pwm_base_addr+brgb->pwm_index * 0x20;
brgb->brightness_max= pdata->brightness_max;
brgb->brightness_min= pdata->brightness_min;
brgb->cdev. brightness_set = sprd_leds_pwm_rgb_set ; /* 操作led行为的函数入口 */
brgb->cdev.name = sprd_leds_rgb_name [i]; // 填充 led name description
。注册到内核led链表 leds_list中:
ret = led_classdev_register(dev, &brgb->cdev);
{
...
down_write(&leds_list_lock);
list_add_tail(&led_cdev->node, & leds_list );
up_write(&leds_list_lock);
...
}
所以如果在其他驱动设备里面要控制led就需要这样做:
down_read(&leds_list_lock);
list_for_each_entry(led_cdev, &leds_list, node) {
if (strcmp(led_cdev->name, "green") == 0 ||strcmp(led_cdev->name, "red") == 0) {
led_set_brightness(led_cdev, 255);
}
}
up_read(&leds_list_lock);

2》重点看看led操作驱动接口 led-class.c
android@ubuntu:~/work/prj/7.0-2514/kernel$ xfind led-class.c
./drivers/leds/led-class.c
该驱动启动后会注册生成设备属性文件:
static struct device_attribute led_class_attrs[] = {
__ATTR(brightness, 0644, led_brightness_show, led_brightness_store),
所以我们在用户空间或者shell下操作:
adb shell echo 255 > /sys/class/leds/red/brightness 的时候,内核对应执行的函数就是: led_brightness_store(...,255)
==>
static inline void __led_set_brightness(struct led_classdev *led_cdev,
enum led_brightness value) {
...
if (!(led_cdev->flags & LED_SUSPENDED))
led_cdev-> brightness_set (led_cdev, value);
==>
static void sprd_leds_pwm_rgb_set(struct led_classdev *pwm_rgb_cdev,enum led_brightness value) {
struct sprd_leds_pwm_rgb *brgb;
brgb = to_sprd_pwmled(pwm_rgb_cdev);
...
sprd_leds_rgb_work (brgb);
}
==>
static void sprd_leds_pwm_rgb_enable(struct sprd_leds_pwm_rgb *brgb) {
...
pwm_write (brgb-> sprd_pwm_base_addr , PWM2_SCALE|PWM_ENABLE, PWM_PRESCALE);
}
这样在用户空间就可以通过操作 /sys/class/leds/red/brightness设备文件属性接口来实现对led设备的控制.

4、分析调试方向
1》驱动分析
1》休眠闪烁问题:开启uart log,飞线,抓异常时候的kernel log
==》出异常时候没有抓到led相关操作的kernel log,怀疑是休眠时候没有uart log输出原因, 开启允许休眠输出uart log后依然如此 ==》怀疑驱动代码根本没执行==》转向硬件问题?
2》控制失效问题:查系统状态寄存器(SPRD_AONAPB_BASE),查看pwm控制bit状态
==》

#define SPRD_AONAPB_BASE 0X402E0000
unsigned int addr_tmp = (__raw_readl(SPRD_AONAPB_BASE));
查看datasheet,找到PWMB,C的使能bit 是bit6,bit7:

adb shell 下使用lookat命令查看APB_EB0寄存器值:
BQru_4072:/ # lookat -l 2 0x402E0000
[I] nword = 0x2
ADDRESS | VALUE
-----------+-----------
0x402e0000 | 0x74f1de08
0x402e0004 | 0x0013c633

0x74f1de08 ==》08 ==》0000 1000,bit6,bit7 都为0 ==》PWMB,C是disable状态!
所以需要在驱动probe的时候设置默认开启PWMB,C为enable状态,设置的地址为:APB_EB0 SET
==> APB_EB0 + 0x1000 ,代码如下:
unsigned int addr_tmp = __raw_readl(SPRD_AONAPB_BASE) ;
addr_tmp |= 0x60; /* 0110 0000, set bit6,7 */
__raw_writel(addr_tmp, SPRD_AONAPB_BASE + 0x1000);
重新编译,烧机,验证 == 》 led控制失效问题得以纠正.

2》硬件分析
1》万用表测量pwm输出pin控制电压,旁路Q控制电压
==》

用万用表测量Q802,Q803的基级(R823,R824)电压,
分别执行:
echo 255 /sys/class/leds/red/brightness
echo 0 /sys/class/leds/red/brightness
echo 255 /sys/class/leds/green/brightness
echo 0 /sys/class/leds/green/brightness
观看基级电压变化(高1.8v,低0v)==》符合软件控制逻辑!
== 》软件控制逻辑正常!

2》分析硬件电路实现原理图,分析可能导致问题的支路电路
从电路图可以看到,唯一会影响到红led的原因只能来自支路 Q800

解析:
RED LED 亮 ==》Q800 导通 ==》Q800基级(R807)为高 ==》Q801 截止 ==》Q801基级为低 ==》 PERCHARCE_LED(GPIO237)为低
查GPIO237的pinmap:
==》

GPIO237,AP端配置,输出功率1级(6mA),选择功能3(普通gpio),唤醒弱上拉,休眠弱上拉,输出方向
从pinmap的配置来说,gpio237应该一直是上拉状态(高电平),现在出问题的时候是休眠时候,但是配置上休眠也是上拉,那为什么休眠的时候就是低了呢?
如下分析:

== 》
要想提高Vi的电压有 两种方式 :一种是减小R1(等效输入电阻),另外一种是增大R2,对应到此题就是减小GPIO237的输入电阻(内阻)或者增大R308 (47k),GPIO的输入电阻是跟平台相关,而且是动态变化的,不能人为调整,那么只能增大R308来实现提高Vi的电压。
至于为什么唤醒状态下Vi可以达到高电平,而休眠状态就不行了呢?有一种解释那就是因为休眠状态下芯片的内阻增大,也就是上面的R1增大,那么Vi就降低,达不到高电平的阈值就当成低电平状态了。所以在高通或者MTK平台相同的硬件搭配可以正常工作,到了展讯平台就不一定可以了,需要根据不同平台的芯片内阻具体调整。

5、原因&方案
根本原因
如上分析,此问题的根本原因是硬件设计缺陷,不同平台芯片的GPIO输入电阻不同,硬件设计需要针对调试,不同平台之间不可直接套用.

解决方案
1》硬件
。硬件修改,增大R308的阻值
2》软件
。驱动probe的时设置GPIO237输出高电平
gpio_direction_input(237);
gpio_direction_output(237,1);

这篇关于展讯7731C平台LED显示异常的解题历程的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/329874

相关文章

java.sql.SQLTransientConnectionException连接超时异常原因及解决方案

《java.sql.SQLTransientConnectionException连接超时异常原因及解决方案》:本文主要介绍java.sql.SQLTransientConnectionExcep... 目录一、引言二、异常信息分析三、可能的原因3.1 连接池配置不合理3.2 数据库负载过高3.3 连接泄漏

Python中 try / except / else / finally 异常处理方法详解

《Python中try/except/else/finally异常处理方法详解》:本文主要介绍Python中try/except/else/finally异常处理方法的相关资料,涵... 目录1. 基本结构2. 各部分的作用tryexceptelsefinally3. 执行流程总结4. 常见用法(1)多个e

Debian 13升级后网络转发等功能异常怎么办? 并非错误而是管理机制变更

《Debian13升级后网络转发等功能异常怎么办?并非错误而是管理机制变更》很多朋友反馈,更新到Debian13后网络转发等功能异常,这并非BUG而是Debian13Trixie调整... 日前 Debian 13 Trixie 发布后已经有众多网友升级到新版本,只不过升级后发现某些功能存在异常,例如网络转

C#文件复制异常:"未能找到文件"的解决方案与预防措施

《C#文件复制异常:未能找到文件的解决方案与预防措施》在C#开发中,文件操作是基础中的基础,但有时最基础的File.Copy()方法也会抛出令人困惑的异常,当targetFilePath设置为D:2... 目录一个看似简单的文件操作问题问题重现与错误分析错误代码示例错误信息根本原因分析全面解决方案1. 确保

Java利用@SneakyThrows注解提升异常处理效率详解

《Java利用@SneakyThrows注解提升异常处理效率详解》这篇文章将深度剖析@SneakyThrows的原理,用法,适用场景以及隐藏的陷阱,看看它如何让Java异常处理效率飙升50%,感兴趣的... 目录前言一、检查型异常的“诅咒”:为什么Java开发者讨厌它1.1 检查型异常的痛点1.2 为什么说

Java异常捕获及处理方式详解

《Java异常捕获及处理方式详解》异常处理是Java编程中非常重要的一部分,它允许我们在程序运行时捕获并处理错误或不预期的行为,而不是让程序直接崩溃,本文将介绍Java中如何捕获异常,以及常用的异常处... 目录前言什么是异常?Java异常的基本语法解释:1. 捕获异常并处理示例1:捕获并处理单个异常解释:

Python自定义异常的全面指南(入门到实践)

《Python自定义异常的全面指南(入门到实践)》想象你正在开发一个银行系统,用户转账时余额不足,如果直接抛出ValueError,调用方很难区分是金额格式错误还是余额不足,这正是Python自定义异... 目录引言:为什么需要自定义异常一、异常基础:先搞懂python的异常体系1.1 异常是什么?1.2

Java.lang.InterruptedException被中止异常的原因及解决方案

《Java.lang.InterruptedException被中止异常的原因及解决方案》Java.lang.InterruptedException是线程被中断时抛出的异常,用于协作停止执行,常见于... 目录报错问题报错原因解决方法Java.lang.InterruptedException 是 Jav

Spring Boot 中的默认异常处理机制及执行流程

《SpringBoot中的默认异常处理机制及执行流程》SpringBoot内置BasicErrorController,自动处理异常并生成HTML/JSON响应,支持自定义错误路径、配置及扩展,如... 目录Spring Boot 异常处理机制详解默认错误页面功能自动异常转换机制错误属性配置选项默认错误处理

SpringBoot 异常处理/自定义格式校验的问题实例详解

《SpringBoot异常处理/自定义格式校验的问题实例详解》文章探讨SpringBoot中自定义注解校验问题,区分参数级与类级约束触发的异常类型,建议通过@RestControllerAdvice... 目录1. 问题简要描述2. 异常触发1) 参数级别约束2) 类级别约束3. 异常处理1) 字段级别约束