RISC-V鸿蒙系统开发板SPI通信模块调试2（项目连载5）

上篇文章中，我们提到了使用读取SPI Flash ID这个程序段，来测试SPI的通信是不是成功。

目前程序运行的结果，是无法正确读取Flash 芯片的ID的。那问题出现在哪里呢？如何去分析这个问题，或者说去尝试解决这个问题呢？

在进行波形分析之前，我们首先要做的就是查看一下芯片有没有虚焊，还有选用的SPI Flash芯片是不是我们需要的。

经过仔细比对，确认我们购买的W25Q128芯片，就是睿思芯科公司提供的例程所使用的芯片。那么在芯片的选型上应该没有问题。

那芯片有没有虚焊呢？这里总共涉及到3块芯片，一个是我们的单片机，一个1.8V转3.3V的电平转换芯片，另外一个就是SPI Flash芯片。因为单片机引脚之间距离只有0.2mm，芯片重新焊接的难度太大。所以，我这边就重新把电平转换芯片和SPI Flash芯片吹下来，重新焊接了一次。确保电路的焊接是没有问题的。

芯片焊接的重新焊接的过程中，发生了一件非常可怕的事情，电平转化芯片TXB0104的焊盘被整体损坏掉了。如果不是有同事帮忙调试焊接，这块板子有可能就废掉了。

如果是个别焊盘损坏掉，还可以飞线进行操作，现在整排焊盘都掉了，该怎么办呢？

实际调试的过程中，对焊盘的修复，我们使用的办法是把损坏掉的焊盘附近的铜线上过油刮掉，使用裸露的铜线作为新“焊盘”进行焊接。然后，再使用非常细小的铜丝把芯片的引脚和板子上的铜线连接起来。如下所示，这个操作过程比较麻烦，需要有娴熟的焊接功底才行。

但是现在有一个重要的事情需要总结，为什么焊接的过程中，自己会把这个电平转换芯片的焊盘一整排全部搞掉？自己确实没有在给焊盘加锡的过程中，使用烙铁头去剐蹭焊接。最后的总结是，在给焊盘加锡的过程中，烙铁头的温度过高，同时由于烙铁头使用的时间太长了之后，氧化严重。上面两个因素导致了烙铁头上的锡非常粘稠，同时温度非常高。那么在加锡的过程中，很容易就会把焊盘带掉。而且因为是加锡的过程，会同时对很多焊盘进行操作，所以一掉就是一整排！！！

这块开发板，在实际焊接芯片引脚的过程中，我们设定的烙铁温度，高达450度，如下图所示。

我们为什么会使用到这么高温度的呢？主要是我们这个板子是四层板，TOP层和BOTTOM层之间的两层，进行了大量的敷铜。导致散热非常快。把烙铁头的温度调高，可以增加焊锡的流动性。如果按照平时300-350度左右的温度来焊板子，我们所熟悉的拖锡动作是没有办法实现的，锡一下子就凉掉了。

但是如果有芯片压在焊盘上，使用这么高的温度进行拖锡，并不会造成焊盘的脱落！

在这块，我们调试的经验就是，给电路板的焊盘进行加锡的过程中，一定不能把温度调节得太高，否则会造成一排焊盘脱落的人间悲剧！这种情况下，大概率，这块板子就废掉了。

上面也提到了，电平转换芯片TXB0104和SPI Flash重新焊接之后，SPI通信依然没有成功。那说明大概率并不是芯片虚焊的问题。那个单片机的引脚，我们目前只能假设它的焊接是完全成功的（太难焊了，拆下重焊成本太高）。那么接下来，只能是先对波形详细分析了。

首先，我们需要做的就是去查看CLK这个引脚的波形，看看CLK的波形输出是不是合理的。SPI，需要在一定的频率范围内才能正常工作。如果频率太高的话，MOSI和MISO这两个接口的波形，可能还没有达到芯片规定的“高”或者“低”，时钟沿就进行了下一次的跳变，这种情况下，很显然单片机和SPI Flash之间是无法进行通信的。

先给大家看一下，我这边第一次抓到的CLK引脚的波形。

大家看到这个波形的时候，是不是觉得有点奇怪。在这个波形中，猛一看CLK的频率信号只有60Hz左右。而实际上，我们的CLK的频率至少要是几Mhz呀。那这个频率是怎么回事呢？

后来分析得到结论，上面图中的高脉冲应该是程序的延时之间的间隔，也就是两个测试程序之间的时间间隔，或者是两次发送数据之间的间隔。真正的CLK波形，需要使用单片机的触发功能，去捕获相应的波形。所谓的触发功能，就是可以设定一个比较值，如果输出信号的波形大于了这个值，示波器就会显示出来这个信号的波形。这里有一个信号比较的过程存在。

通过示波器，捕获出来真正的CLK信号之后，它的波形是如下形状的。

大家看一下，这个波形的频率高达12Mhz。这个12Mhz是怎么来的呢，我们前面提到了这个单片机的时钟晶振是24Mhz，那么这个SPI的通信速率12Mhz应该是时钟信号24Mhz二分频之后得到的。现在，我们就有一个怀疑，SPI通信的失败是不是由于这么高频的通信速率导致的呢？

还有一个问题，大家有没有发现这个CLK的波形，它的最小值并没有到参考地。同时它的最大幅值，我们使用示波器测量之后，只有2.2V。可是SPI这边的工作电压是3.3V呀，而且我们的电平转换芯片输出的电压也是3.3V。那是不是这个CLK信号，本身就是有问题呀？或者说在这个电压幅值区间，Flash芯片能不能识别CLK信号呢？

我们这片文章，就先分析到这里。下一篇，我们继续SPI通信的调试。

RISC-V开发板SPI通信模块调试1(项目连载4)

我们这块开发板使用的是W25Q128FVSG这个Flash进行外部存储的，这个Flash和单片机之间的通信方式是SPI通信。Flash模块焊接完成之后，一直通信不成功，我们在这个地方的调试花费了非常长的时间。有不少经验值得总结分享。

还是先上实物图和原理图，给大家一个感性的认识。

图1  W25Q128FVSG连接电路

上图是SPI Flash实物接口电路，红框中的就是W25Q128FVSG芯片。黄框里面的是1.8V转3.3V双向电平转换芯片。为什么需要这个电平转换芯片呢，主要是因为我们单片机的IO接口输入输出是1.8V的电平，然而这个存储Flash的工作电压是3.3V。这个1.8V的芯片IO输出电压，在实际使用的单片机中是比较少见的，我们这款单片机某种程度上应该算是一种原型机，1.8V的电压是芯片内部的电压。

图2 SPI接口电路原理图

关于SPI接口电路图的原理部分，我们在这里就先不做详细介绍了，整体也比较简单，具体的接线方式，我们可以查看一下datasheet引脚的对接口的描述方式。然后按照datasheet的接线要求来接就可以了。

比如datasheet中，对WP引脚的描述，是这样的。

它说这个WP（Write Protect）是低有效的，也就是说这个引脚被拉低的时候，Flash存储芯片是没有办法写入数据的。我们自己的程序是需要往存储芯片写数据，那么这个引脚肯定是要被拉高的。

再比如这个Hold引脚，datasheet中的描述如下，显然这个也是低有效，也就是说Hold引脚被拉低的时候，DO这个引脚是高阻抗状态，也就是说无法进行数据传输了。我们自己的程序肯定是需要数据传输的，所以这个引脚是要被拉高的。

上面两个部分的举例，主要是为了说明我们画原理图的时候，如何根据datasheet引脚进行端口确认。不少时候，我们可以直接拿到别人的原理图，进行参考。不过我个人的看法还是自己详细读一下datasheet，再进行一下确认，一是防止被别人带进坑里去，另外一个也能够让自己在调试的时候更有信心。

我们的Flash读取程序是基于一个Linux内核SPI NOR框架，比如在linux5.2.0内核中，关于这个框架的说明在 “Documentation/mtd/spi-nor.txt”这个文档中。大家先对这个框架有所理解就行，等系列文章分享完成后，我这边会把所有的代码给大家共享。

在对FLASH存储模块存入、读取、擦除数据的操作实施之前，我们第一步是不是要先验证这个芯片是不是我们需要的芯片呀。那怎么验证呢？在程序中使用的办法，就是读取这个Flash的ID，看看芯片反馈回来的ID和datasheet说明的是不是一致。

在程序中，就是通过这一段代码来实现的。但是实际收取到的信息却是如下的，那说明读取不成功。

正确读取的时候，JEDEC id的结果应该是这样的。

那该怎么解决这个问题呢，SPI调试系列的第二篇文章，我会给大家详细的剖析一下调试过程。

RISC-V 开发板 Buck电源调试记录（项目连载3）

基于RISCV单片机的鸿蒙开发板

Buck电源部分调试记录

1. 起因

这个开发板前期demo板的焊接，我这边焊接了两块电路板，主要是方便对比调试。前期的焊接都还比较顺利。各个模块（包括电源，LED灯，温湿度检测以及单片机最小系统等）测试都可以正常工作。

等到两个开发板都焊接到红外模块的时候，两个板子同时出现了问题，程序再也烧录不进去了。没有开发板可以进行程序调试，问题就严重了。

图1: 红色部分为红外探头

出现这个事情的原因，很有可能是因为红外这个模块是射频模块，功率比较大或者有射频干扰，导致电路板上其他模块的工作出现异常。

只所以能够得到这个结论，是基于以下两个判断：①两个板子同时出现焊接问题的可能性很小，②红外模块本身原理图出现问题很小，我司其他类型的开发板已经验证过这个电路模块的可行性。

关于对红外模块的干扰处理，我们后面会有专文进行剖析，本文只做简要介绍。

出现这个问题之后，我们首先想到的就应该是把红外模块的外围电路去除，看看程序的烧录工作还能不能正常进行。

图2 红框中的电路即为红外模块的外围电路

可是拆除这些模块之后，烧录工作并不能正常进行了，两块手动焊接的开发都是这么一个情况。开发板中肯定有其他模块因为红外模块的焊接出现了损坏，那么到底是哪个模块出现了问题呢？整个开发板，那么多元器件，怎么才能够快速的锁定问题，是一件棘手的事情。

1. 解决问题的思路及注意事项

现在的情况是不知道哪个模块出现问题了，只能是进行地毯式的搜查。排查问题的顺序，最好是先从电源部分入手，依次往后看。先看看各个芯片工作的电压是不是正常。如果电压正常，那么就有可能是芯片本身已经被损坏了，就需要把芯片更换掉，再进行测试。如果电压不正常，那么就是电源坏掉了。

不断重复这个过程（以芯片的工作电压为抓手），最终锁定出问题的地方。

在这个过程中，芯片会被拆掉，重新焊接，对调试人员焊接元器件的能力是有比较高的要求的。这个要求主要有以下几点：①焊接过程本身对焊盘是用损伤的，多次的焊接很容易把焊盘搞掉。一旦焊盘被搞掉了，可能整个板子就会被废掉，前期所有的工作都白费了。所以烙铁头一定不能剐蹭焊盘。另外同时烙铁头的温度也不能太高，否则粘稠的锡也可能把焊盘带掉。②拆除和焊接芯片的工程中，很容易把芯片的外围器件移动掉，导致外围器件也需要重新焊接，使开发板调试是速度变慢。

2. 解决问题的过程

我们首先测量Buck电源能不能够正常工作，结果发现3V3的buck输出电压是3.5V。输出电压和实际的设计值之间差别巨大。

我们使用的Buck芯片是SY8077，这一款工作频率高达1.5Mhz的Buck芯片，电路工作时典型的拓扑结构如下图：

图3 SY8077芯片工作原理图

电路正常工作是FB引脚的反馈电压是0.6V，如下图所示。

图4 SY8077 FB接口引脚电压

但是实际测量时候，FB引脚的电压是0.65V。这就很奇怪了，是Buck芯片出问题了，还是Buck电路的外围芯片出问题了？

我们可以做出如下假设：

①芯片本身被损坏了，导致输出电压不正常，并且FB引脚电压也不正常。

②反馈电阻坏掉了，导致FB引脚的电压输出不正常。

但是更换一个新的SY8077 Buck芯片之后，输出依然是3.5V。同时替换下了新的反馈电阻，FB引脚的电压依然是0.65V，Buck电路依然没有能够正常工作。难道SY8077更换上去后，只要上电立即就坏掉了？至少到目前是有这个可能的。

那这是哪里出问题了呢？问题一下子又复杂化了。

这个Buck电路的输出电压不正常，那输出电流是什么样子呢？我们可以查看一下输出电流的波形，进一步确定buck电路的工作状态。

图3  Buck电路电流测试电路

图4 电流探头

我们把这个电感竖起来，用一根白色的线延长电感的线路。这样把电流探头套到这根线上，就可以查看流过电感的电流波形，从而确定这个电感是工作在什么状态，是断续模式、临界连续模式还是连续模式状态？

可是把电流探头套到这根线上之后，实测电流波形如下：

图5 输出电流及电压波形

图中蓝色部分的波形是输出电流的波形，可以看到电流在上电之后，出现了一个波动，然后电流就归于0了。也就是说，5V转3.3V的这个buck电路并没有电流输出。

Buck电流的输出电压不正常，而且输出电流为0；同时SY8077这个芯片以及外围电路已经更换过，应该也是没有问题。那么影响这个buck电路不能正常工作的因素只能是负载了，3V3这个输出电压的负载如果有短路的话，是不是会导致SY8077出现这样的情况呢？如果是负载的原因，那是哪个负载呢？

确实一下很难猜出是哪个负载导致的，这个时候有两个办法一个是一个个拆解，看看拆掉哪个负载后，buck电路可以正常工作了；另外一个办法是，先把所有的负载拆掉，然后一个一个往电路上添加，如果添加到某一个负载时，buck电路不能工作了，那说明就是这个负载出了问题。

我们上面还留有了一个疑问，是不是新换的buck芯片SY8077上电之后就坏掉了？我们需要首先验证一下buck电路是不是可以正常工作。要验证这个buck电路是不是可以正常工作，只有先把所有的负载先拆除掉，只留一个阻性负载或者选择电子负载用作测试。

结合上面的因素，我们选择先把所有3V3的负载先全部拆掉。拆掉之后，重新查看电感的电流波形，发现电流是有输出的。而且随着电子负载的加重，电感的工作模式实现了从断续模式到连续模式的转变。这个测试结果说明SY8077这个芯片并没有损坏，同时SY8077这个芯片在自我保护的时候，其输出电流是0，FB脚的电压是0.65V。具体为什么会是这么一个机制，SY8077的datasheet并没有说清楚。

后面就是不断把3.3V的负载（各个芯片，比如温湿度传感器SH20、电平转换芯片、电平逻辑芯片等等，只要供电电压是3.3V的，都算是3V3电源电压的负载）往电路板上添加。添加的过程一定要注意，最好是使用风枪吹，这样对周边焊接元器件的影响是最小的，可以加快调试板子的速度。

等到添加FT4222HQ这个SPI转Flash的时候，发现Buck电路电流又变成0了，也就是说Buck电路不能正常工作了。经过漫长的分析与调试，终于找到被损坏的芯片了！！！

更换上新的FT4222HQ之后，Buck电源的输出就正常了，自然程序的烧录也就正常了。

基于 RISCV 单片机的鸿蒙开发板-usb转spi硬件电路调试（项目连载2）

基于 RISCV 单片机的鸿蒙开发板

本项目从这个地方开始连载，连载结束后，会把原理图（pdf 版）开源给大家。刚开始大家可能会觉得顺序有些凌乱，主要是因为这个连载不是从最初阶段开始的，后面我会把缺少的部分，比如原理图板块等等一一补上。这样大家看起来，内容就不会显得突兀。

(一) 硬件电路调试

1. usb 转 spi 部分

电路上电后，通过 linux 中的烧录程序烧录往单片机中烧录程序不成功。但是以下两个条件基本可以确定 FT4222 这个外设是没有问题的。

①在 Linux 系统中能够识别 FT4222 这个外设（驱动自动安装的）

②在 Linux 系统中连续通过 FT4222 向单片机发送数据，在单片机的 MOSI 引脚处可以通过示波器实测到信号。如图所示：

那么问题现在最有可能出现的就是单片机这个地方了，先从以下几个地方入手，看看单片机有没有正常工作。

1. 供电

2. 时钟，包含 refclk 和rtcclk 3.test io clk

4. 检查 boot 设置

5. 复位电路

上面几个指标也就是单片机的最小系统必备的部分。供电部分电压示波器测量如下：

1. 1.8V

2. 0.8V

3. 0.9V

4. 3.3V

时钟信号：

1. refclk 24Mhz，pass

1. rtcclk error

查到问题了，焊接电路板的过程中把晶振输出引脚和单片机引脚之间的电阻给“震掉” 了。（此处建议焊接的时候，震动去锡法还是尽量少用，可能会带来未知的风险。。。）

就下面这个电阻（在这耽误了不少时间）

焊接上电阻之后的晶振输出波形：

不过把这个电阻焊接上去之后，烧录依然不成功。那肯定还有其他地方问题没有解决。

1. test io clk

这个频率是 92K，是符合设计需求的，pass。

boot 电路

error，原来 boot 电路部分还没有焊接（为了分步调试，有些电路没有焊接）。赶快把 boot

引脚焊接好。

经查手册，单片机程序烧录的时候，4 号脚应该高，5 号脚为低，也就是 2-3 通，1-4 不通。

在电路板上就是这么一个表现形式，也就是 2 通道 ON，1 通道 OFF。

把上述问题解决后，程序就能够烧进去了，如图：

基于RISC-V单片机的鸿蒙开发板项目简介（项目连载1）

大家好，我是张飞实战电子的张角老师。我目前正在做的一个项目是开发一块基于RISC-V架构单片机的鸿蒙系统开发板。

鸿蒙系统是华为公司开发的新一代物联网操作系统系统，RISC-V单片机是不同于ARM架构的单片机，目前形势一片大好。在美国对我国芯片以及操作系统等高新科技的疯狂打压的背景下，鸿蒙系统以及RISC-V架构单片机这两种产品的发展以及突破显得尤其重要。它们两个很大概率上会是电子信息领域我们突破美国技术封锁的两个突破口。

张飞实战电子，愿意在力所能及的情况下，为这两块产品的推广添砖加瓦，贡献自己的力量。为此，我们愿意把这块基于RISC-V架构单片机的鸿蒙系统开发板的实现过程，尽可能清楚的展现给大家，争取越详细越好，为大家以后进行相关的产品开发提供一些经验参考。

这块开发板使用的单片机是深圳睿思芯科的Pygmy-E系列的单片机，这是一款32位的面向IOT领域的单片机，具备超低功耗的特性以及丰富的外设接口。

开发板的硬件电路模块包括电源电路，电平转换电路，单片机最小电路，USB转SPI电路，USB转UART电路，温湿度检测电路，片外SPI Flash电路，红外模块检测电路，开关检测电路，蜂鸣器电路，流水灯电路。

电源电路包括12V电源接口电路，12V转5V Buck电路，5V转3V3 Buck电路，3V3 转1V8 LDO电路，3V3转0V9 buck电路，3V3转0V 8 buck电路。BUCK电源和LDO电源是我们做开发板的过程中非常常用的电源，在这个模块，我将和大家分享下BUCK以及LDO电路的设计方法。

电平转换电路主要是利用双向电平转换芯片TXS0104以及TXB0104等实现电平的双向转换。为什么我们需要电平转换芯片呢，主要是因为我们使用的这块单片机是还处于验证阶段，单片机IO的电平是1V8，而我们常用器件的电平以3V3的居多，比如我们用的FT4222 USB转SPI芯片，SHT20温湿度检测传感器等。

单片机最最小外围电路包括供电模块，晶振模块，复位电路模块，BOOT启动模块等。

其他模块电路我们就不一一介绍了，等以后我们再展开分析。

软件这块，我们打算依据硬件电路开发一些demo。这些demo主要分为三个板块，一个是睿思芯科RISCV单片机的外围驱动开发模块，主要包括GPIO、UART、I2C、SPI等接口的驱动开发；一个是鸿蒙系统Liteos-M模块的内核实验；再一个就是，利用外围电路我们我们要演示的一些demo，比如流水灯，蜂鸣器唱歌，红外信号检测，温湿度检测，外置SPI Flash读取等。

软件的开发和编译是在Ubuntu 中进行的，会使用到一些简单的Linux命令。这里我们会尽可能详细的介绍清楚编译环境的搭建，以及调试过程。

整个项目涉及到的硬件、软件等相关的东西比较庞杂，我们争取尽可能清晰完整地展现所有的细节。因此估计更新的时间会比较长，期待大家能够和我一起坚持到最后。久久为功，方能修成正果。一起加油！