原来MCUXpresso IDE是这样的在Flash调试流程

大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家介绍的是MCUXpresso IDE下使用J-Link下载算法在Flash调试注意事项。

痞子衡前段时间写过一篇小文《为i.MXRT设计更新Segger J-Link Flash下载算法文件》，介绍了痞子衡在github上的开源i.MXRT下载算法项目，这个项目收集了几乎所有i.MXRT型号的J-Link flash下载算法源工程，基于这个源工程可以很轻松修改生成不同flash的算法文件用于各大IDE以及J-Flash。今天痞子衡就来介绍一下如何使用新生成的flash算法文件配合J-Link调试器在MCUXpresso IDE下XIP调试（基于i.MXRT500）。

1、准备测试环境

首先需要准备好测试环境，包含必要的软件和硬件，痞子衡的环境如下：

集成开发环境：MCUXpresso IDE v11.2.0_4120，点此下载

软件开发包：
SDK_2.8.0_EVK-MIMXRT595_PRC（Toolchain需包含MCUXpresso IDE），点此下载

软件驱动：J-Link driver v6.72b，点此下载

硬件工具：J-Link Plus调试器

硬件开发板：MIMXRT595-EVK (Rev.C1)

其中集成开发环境和软件开发包需要有如下版本对应关系，因为MCUXpresso IDE是恩智浦基于GCC和Eclipse而设计的免费IDE，而且主要是为恩智浦MCU设计的，所以跟恩智浦MCU SDK包有一定的捆绑关系。

2、新生成flash算法

我们测试的板卡是MIMXRT595-EVK (Rev.C1)，这个板卡默认是在FlexSPI0上连接的八线Flash（MX25UM51345），J-Link驱动里如果支持i.MXRT500的话默认flash算法也是这个八线flash，为了测试新生成的flash算法，我们将板卡rework一下，FlexSPI0连接到四线Flash（IS25WP064）。

我们现在需要为这个四线Flash（IS25WP064）做一个新flash算法，打开痞子衡的github开源项目如下源工程，确保工程添加的is25wp064相关的源文件，然后编译生成新的MIMXRT5XX_FLEXSPI.FLM（即flash算法文件）。

算法源工程：

https://github.com/JayHeng/imxrt-tool-flash-algo/tree/master/boards/nxp_evkmimxrt595_rev.a-c/flash_algo_b0_silicon/Keil_JLink

有了新flash算法文件，将其放到 \SEGGER\JLink_V672b\Devices\NXP\iMXRT5xx 路径下，为了跟默认flash算法区分开来，可以将其重新命名为
MIMXRT5XX_FLEXSPI_IS25WP064.FLM，顺便更新JLinkDevices.xml文件。

将板卡供电，连上Jlink调试器，使用JlinkCommander的loadbin命令试一下新flash算法是否有效，在确保新flash算法没问题时再进入IDE调试。

3、进入MCUXpresso IDE调试

3.1 导入SDK及打开示例工程

打开MCUXpresso IDE，默认Installed SDKs界面框里没有RT500，我们直接将下载好的
SDK_2.8.0_EVK-MIMXRT595_PRC.zip包拖到Installed SDKs界面框中即可。

这时候Installed SDKs界面框里可以看到RT500，选中它然后继续操作来导入example，我们就选demo_apps下的hello_world例程，编译这个工程确保没问题。

3.2 更新J-Link Server路径

在安装MCUXpresso IDE时会同时安装一个默认Jlink驱动（一般路径在C:\Program Files (x86)\SEGGER\JLink），这个驱动版本不一定新，MCUXpresso会默认调用这个驱动，但很多时候我们都是手动安装新Jlink驱动来使用的（痞子衡装在了C:\tools_mcu\SEGGER\JLink_V672b），前面我们新生成的flash算法也是放在手动安装的Jlink驱动目录下的，因此我们需要在MCUXpresso里重设J-Link Server路径，指向手动安装的Jlink驱动。

3.3 借助J-Link在线调试

看起来一切就绪了，让我们开始在flash调试吧，点击Debug按钮，会看到MCUXpresso弹出了调试器类型选择，并且识别到了我们连接的J-Link，点击OK确认。

如果出现下载失败，需要查看一下自动生成的jlink的.launch文件里的设置，尤其是下面的Device设置，要确保与前面更新的JLinkDevices.xml文件里改动的脚本代码里Name一栏相一致。

这时候可以看到MCUXpresso调用了J-Link驱动完成了代码烧写（这时候去读flash，里面的内容是烧录正确的），但是界面并没有停在main函数里，并且没法单步调试，这是为什么？

3.4 满足MCUXpresso调试流程

然后痞子衡去咨询了MCUXpresso IDE研发团队，得知它默认的调试流程跟一般的通用IDE（Keil，IAR）不太一样，一般的IDE可以直接引导App启动来调试，但MCUXpresso IDE不主动引导App，而是复位后让App自然启动，然后尝试Attach上去接管调试，所以根据这个流程，我们需要做两点必要的改动：

更新flash_config头（将hyper flash配置改为QSPI Flash配置），需要与板卡连接的flash相匹配设置ISP模式为从Flash启动，保证reset之后ROM能引导App从Flash正常启动

改动完之后，我们终于可以愉快地单步调试了。

至此，MCUXpresso IDE下使用J-Link下载算法在Flash调试注意事项痞子衡便介绍完毕了，掌声在哪里~~~

查看原文：
https://www.dianyuan.com/eestar/article-8253.html

不同复位类型设置对MCUXpresso IDE在线调试有何影响？

本篇实际上是《IAR在线调试时设不同复位类型可能会导致i.MXRT下调试现象不一致》的同系列篇，计划中痞子衡是要把几大经典IDE（IAR EWARM、Keil MDK、MCUXpresso IDE）下的复位策略都写一遍，但一直没抽出时间。今天痞子衡恰好帮助一位印度同事解决了在客户板子上使用MCUXpresso在线调试的问题，因此顺便认真研究了下MCUXpresso IDE下复位策略，特地分享给大家。

在读本文前，最好把痞子衡先前写过的一篇 《MCUXpresso IDE下使用J-Link下载算法在Flash调试注意事项》 浏览一下，本文要探讨的问题比先前那篇文章要更深入。

Note: 痞子衡测试的MCUXpresso IDE版本是v11.3.0_5222。

一、在客户板卡上遇到的调试问题

先来回顾下客户遇到的调试问题。据印度同事介绍，客户自己设计的i.MXRT1052板卡，使用的Flash是Cypress生产的S25FL128LAGMFI01，客户寄了一块样卡给我同事，我同事在客户板卡上随便找了个SDK里的hello world工程（MCUXpresso IDE）去在线调试，调试器是恩智浦的LPC-Link2。

i.MXRT1050 SDK工程里默认选择的下载算法是适用官方EVK上默认Hyper Flash的，并不适用客户这块板卡上的QSPI Flash，因此印度同事为客户制作了一个LinkServer Flash Driver（MCUX下载算法），使用这个新制作的下载算法可以去下载（至少从MCUX的下载日志里可以看到Flash Write Done），但是断点没能停在main函数，因此无法单步调试，而且在IDE里检查0x60000000处空间，看到的是如下无效数据，就像是程序根本没有下载进去，这到底是怎么回事？痞子衡接下来就先为大家分析MCUXpresso IDE下复位策略，最后再给大家解谜。

关于LinkServer Flash Driver的制作可参考痞子衡之前写过的 《串行NOR Flash下载算法(MCUXpresso IDE篇)》，但其实这个客户选择的S25FL128LAGMFI01就是块普通的符合JEDEC SFDP标准的QSPI NOR，在MCUXpresso IDE安装目录下的MIMXRT1050_SFDP_QSPI.cfx算法是可以直接使用的（路径是 \MCUXpressoIDE_11.3.0_5222\ide\binaries\Flash）。

二、MCUXpresso IDE调试机制与调试分类

关于MCUXpresso IDE下的调试机制原理在 \MCUXpressoIDE_11.3.0_5222\
MCUXpresso_IDE_User_Guide.pdf 手册里并没有找到设计性的介绍，虽然手册里一共有如下四个章节涉及到了下载调试，但更多是介绍如何在IDE里使用下载调试功能。

10. Debug Solutions Overview11. Debugging a Project14. The GUI Flash Tool15. LinkServer Flash Support

不过调试机制在各IDE上大同小异，设计理念都是一致的，这部分建议参考 《IAR在线调试时设不同复位类型可能会导致i.MXRT下调试现象不一致》 里的一、二章节。

三、复位类型全解析

好了，现在我们进入正题，开始介绍MCUXpresso IDE下复位类型。我们知道不同硬件仿真器下复位功能有差异，痞子衡主要介绍i.MXRT上两种最常用的仿真器：J-Link和DAPLink。此外不管是哪种仿真器，其都借助了Cortex-M7内核功能，内核在SCB模块的AIRCR寄存器中集成了复位的支持，详见 《IAR在线调试时设不同复位类型可能会导致i.MXRT下调试现象不一致》 的 3.1 Cortex-M7复位功能 小节。

3.1 J-Link复位类型

MCUXpresso IDE下设置J-Link复位类型一共有如下图所示三处，其本质上都是借助Jlink底层命令，具体可在 \SEGGER\JLink_V686f\Doc\Manuals\UM08001_JLink.pdf 文档中的 Supported remote (monitor) commands 小节里的reset命令以及 List of available commands 小节里的SetResetType命令里找到详细解释。

UM08001_JLink.pdf 文档中的 7.10.2 Strategies for Cortex-M devices 小节一共列出了如下三种复位类型：

Normal（复位编号0）：默认的复位策略，对于i.MXRT来说等同于Core and peripherals方式

Core（复位编号1）：借助Cortex-M内核模块SCB中的AIRCR寄存器的VECTRESET位功能来复位Core

Reset Pin（复位编号2）：通过拉低J-Link的RESET引脚（一般也会接到MCU reset脚）来复位MCU

上图复位类型设置框中的三处设置，虽然都能使能复位操作，但是阶段不同，其中红框2处设置是的下载前操作，红框3处设置是下载后的操作，红框1处设置是执行前的操作。如果你对这个顺序不了解，可以做个试验，比如我们在红框3处设置复位类型1，在红框1处设置复位类型2，进入调试后在日志窗口找到JLinkServer日志，在日志中查看具体顺序。

在实际使用中，痞子衡推荐不使能红框1中的"Reset before running"选项，并且仅在红框3中设置复位类型，经测试这种方式与其他IDE下的调试体验最一致。但还是有如下两点注意事项：

Note1: 复位命令后，必须增加一个monitor reg pc设置，否则无法正常调试。

Note2: 复位类型是0的情况下，如果此时BootROM没能正常启动App（即应该不能正常调试），但在IDE界面里有时候还是会停在main函数，这其实是假象（应该跟cache有关），并不能正常调试，点击suspend按钮就能看到跑飞。

3.2 LinkServer复位类型

LinkServer即对应DAPLink调试器，是MCUXpresso IDE默认的调试器类型，IDE里为这个默认调试器实现了友好的复位类型选项。

上图复位类型设置红框1中的“Reset handling”一共提供了五种复位选择。这五种复位除了SOFT外，其余都不会主动设PC指针，默认全靠breakpoint去触发调试。

Default：等同于于SYSRESETREQ方式

SYSRESETREQ：借助Cortex-M内核模块SCB中的AIRCR寄存器的SYSRESETREQ位来同时复位MCU外设模块

VECTRESET：借助Cortex-M内核模块SCB中的AIRCR寄存器的VECTRESET位功能来复位Core

SOFT：直接将CPU的PC指针重置到应用程序入口函数，相当于软复位

空：等同于SYSRESETREQ方式

同上节JLink复位类型一样，LinkServer下也提供了额外的Commands设置（红框2/3），具体命令写法需查看
MCUXpresso_IDE_User_Guide.pdf 手册，本文就不详细介绍了。

关于Reset handling选择SOFT方式的结果，有一点需要特别指出，我们在如下对应日志里可以看到，下载完成后调用了soft reset并且从0x60000000处拿了SP和PC，即MCUXpresso IDE认为下载首地址就是程序中断向量表起始地址，这个假定在i.MXRT的XIP工程上其实是不成立的，我们知道正确的中断向量表起始地址应该是0x60002000。如想让MCUXpresso IDE拿到正确的SP/PC，应该在XIP工程预编译选项里把XIP_BOOT_HEADER_ENABLE设成0（也可以研究下在红框3中增加LinkServer命令去设置PC），否则没法正常调试。

四、复位类型对在线调试的影响

复位类型对在线调试的影响分两种：一、是否影响应用程序正常调试；二、是否影响应用程序正常运行。对于第二点，因为应用程序的设计差异，无法确定复位类型的不同导致的未复位模块对其产生何种影响，因此我们暂不讨论这点，我们主要看第一点。

设置不同的复位类型是否影响应用程序正常调试（能否停在程序入口函数，能否进行单步）？痞子衡在MIMXRT1050-EVKB上实测了SDK里的led_blinky例程，选取了flexspi_nor_debug（在Flash）build做了很多组测试，结果如下：

从上表的测试结果，我们可以得到如下结论：

结论1：在Flash调试，要想正常调试，要么不复位片上外设（保留Flashloader对FlexSPI等模块的初始化），要么启动模式设成Flash Boot（让BootROM完成FlexSPI等模块的初始化），因为Clock/GPIO/FlexSPI的初始化必须保留，CPU才能正常获得Flash里指令。

结论2：JLink复位下，MCUXpresso IDE调试体验与其他IDE是一致的。

结论3：LinkServer复位下，MCUXpresso IDE下VECTRESET方式复位达不到其他IDE下同等方式的效果，因为初始PC无法得到。

五、客户板卡上调试问题的原因

最后回到客户板上的问题，痞子衡的印度同事其实是非常有经验的，板卡启动模式设置，Flash下载算法，工程里的FDCB头全部都是正确的，但是经查明板卡i.MXRT1052芯片的eFuse中BOOT_CFG2[3]位被烧写成了1，即芯片进入了inifnite loop模式，PC永远停在BootROM里，客户App不会被启动，因此无法硬复位后进调试。

BootROM中系统初始化函数里对BOOT_CFG2[3]位的处理代码：

volatile uint32_t infinite_loop;void SystemInit (void){#if ((__FPU_PRESENT == 1) && (__FPU_USED == 1))  SCB->CPACR |= ((3UL << 10*2) | (3UL << 11*2));    /* set CP10, CP11 Full Access */#endif /* ((__FPU_PRESENT == 1) && (__FPU_USED == 1)) */    TRACE("BootROM: SystemInit\n");    rtwdog_disable();    /* Below codes is used for issue troubleshooting on real chip */    if ((ROM_OCOTP_INFINITE_LOOP_VALUE() == 1) && (ROM_OCOTP_DIR_BT_DIS_VALUE() == 0))    {        infinite_loop = 1;        while(infinite_loop)        {        }    }    // 代码省略}

至此，MCUXpresso IDE下在线调试时使用不同复位策略的现象总结痞子衡便介绍完毕了，掌声在哪里~~~

查看原文：
https://www.dianyuan.com/eestar/article-8252.html

这么简单的环境搭建，网友：我却搭了很久，结果还是不行...

前言

大家好，我是麦叔，之前有小伙伴建议出一期如何快速搭建一个MQTT协议的测试环境，因为自己写的mqtt测试工具总是有这样那样的问题。

其实这里要合理地使用现有的工具，其实很简单，几步可以搞定，下面我们开始介绍。

目录

• 前言
• 目录
• 系统架构
• 准备工具
• 代理服务器
• 客户端
• 验证消息传递
• 订阅主题
• 发布主题

系统架构

通常我们需要这些东西；

• 一个MQTT代理服务器（Broker），作为MQTT消息的中转；
• MQTT客户端，可以进行订阅消息（接收），发布消息（发送）

注意：客户端只能接收到已经订阅主题的相关消息，这里如果不清楚，建议把MQTT协议基础再看一下；

我们需要搭建的整体架构如下所示；

准备工具

要快速搭建MQTT测试环境，可以使用以下步骤：

代理服务器

安装代理服务器，MQTT Broker：选择一个MQTT Broker来搭建测试环境。

常用的MQTT Broker有Mosquitto、HiveMQ、EMQ X等。

我们可以根据自己的需求选择其中一个来安装。

本文使用Mosquitto在Windows系统上进行安装作为示例：

对于Windows系统，从Mosquitto官方网站下载并安装Windows版本。

https://mosquitto.org/download/

根据自己的系统进行下载，通常64位的系统下载相应的软件进行安装即可；

注意：安装路径按照实际的情况即可；

在当前的路径下创建一个配置文件mosquitto.conf，配置文件输入的内容如下：

listener 1883protocol mqttlistener 9005protocol websocketsallow_anonymous truelog_type noticelog_type websocketslog_type warninglog_type errorlog_type information

在当前路径下打开dos或者powershell，输入指令

mosquitto -c mosquitto.conf

代理服务器开始运行；

客户端

客户端MQTT Client我们也可以用现成的工具，本文使用MQTT X，如下所示；

下载地址：

https://mqttx.app/downloads

选择适合自己系统的版本，进行安装即可；

通常，有几个参数需要进行配置；

• Client ID：客户端的ID，这里需要保证唯一性；
• 代理服务器地址：按照实际的地址进行填写，默认的监听端口号为1883；
• MQTT版本：默认一般为V3.1.1

注意：如果这里不是很清楚，建议再看一下MQTT协议基础；

客户端 TEST-1

客户端 TEST-1

配置完进行连接，可以看到代理服务器上已经有日志提示新的客户端连接，并且client id 是 TEST-1……

查看原文：
https://www.dianyuan.com/eestar/article-8291.html

元宵节花灯里的LED是并联的还是串联的？

提前祝大家元宵节快乐，今天我拆了个元宵节花灯，分享给各位同好。

供电：三颗纽扣电池，随电池电压下降灯会变暗。

元件：一颗芯片，一个按键，十颗LED；

功能三种发光模式：快闪，慢闪，常亮；无限流电阻。

不是牛屎芯片竟然，还是挺意外的。（不过我拆的另一个花灯是牛屎芯片，牛屎芯片是世界上最好的芯片）

LED灯的特写，LED灯被固化胶封住，上下两根应该是漆包线。

LED亮的时候电流很大，大概有120mA。

所有的LED为并联关系，阳极连到一起，连到纽扣电池的正极；阴极连到PWM芯片的管脚。下图为PWM芯片的管脚（LED的阴极）输出对地的波形。

查看原文：
https://www.dianyuan.com/eestar/article-8300.html

嵌入式开发必须学习Qt吗？

前言

嵌入式系统已经成为现代科技中不可或缺的一部分，涉及到从智能家居设备到汽车控制系统等广泛的应用领域。

在嵌入式系统的开发过程中，选择适当的开发工具和框架对于提高效率、简化开发流程至关重要。

嵌入式的技术栈比较冗杂，Qt只能是其中的一小部分，作为一个跨平台的C++图形用户界面库，Qt在嵌入式领域占据一席之地。

但是嵌入式开发是否必须学习Qt，仍然是一个备受争议的问题。本文将从不同角度分析嵌入式开发与Qt学习的必要性。

Qt的基本概述

Qt是一款由Qt公司（前身为Trolltech）开发的跨平台应用程序框架。它提供了丰富的功能，包括图形用户界面、数据库操作、网络通信等，使得开发者能够更加便捷地创建高质量、可移植性强的应用程序。Qt采用C++编写，同时也支持多种编程语言，如Python。由于其出色的跨平台性能，Qt在桌面应用程序和嵌入式系统中都有广泛的应用。

嵌入式开发的基本要求

在讨论Qt是否必须学习之前，我们首先要了解嵌入式开发的基本要求。嵌入式系统通常具有资源有限、功耗低、实时性强等特点，因此，嵌入式开发者需要具备以下基本技能：

熟悉硬件

嵌入式开发者通常需要与底层硬件打交道，理解处理器架构、外设接口等，并能进行底层硬件操作。这包括对GPIO、SPI、I2C等接口的熟练掌握。

实时操作系统（RTOS）

许多嵌入式系统要求具备实时性能，因此对实时操作系统的了解是必要的。RTLinux、FreeRTOS等是常见的实时操作系统。

低功耗设计

嵌入式设备通常要求低功耗，因此开发者需要了解如何进行有效的功耗管理，包括休眠模式、功耗优化等方面的知识。

编程语言

C语言是嵌入式开发的主流语言，因为它能够直接操作硬件并提供高效的执行性能。此外，汇编语言在一些特殊情况下也是必要的。

Qt在嵌入式开发中的优势

虽然嵌入式开发有一系列基本要求，但学习Qt在这个领域仍然有着诸多优势：

图形用户界面设计

Qt提供了强大的图形用户界面设计工具，可以帮助开发者快速创建直观、用户友好的界面。这对于一些需要具备交互性的嵌入式设备尤为重要，如触摸屏控制的设备。

跨平台性

嵌入式设备的硬件平台多种多样，而Qt的跨平台性使得开发者能够更好地适应不同的硬件环境，减少了开发的复杂性。

丰富的库和工具

Qt拥有丰富的库和工具，包括网络模块、数据库模块等，这些可以大幅度提高开发效率。Qt Creator是一款强大的集成开发环境，为嵌入式开发者提供了便利。

社区支持

Qt拥有庞大的社区，开发者可以通过社区获取支持、分享经验，这在解决问题和提高技能方面非常有帮助。

Qt学习是否必要？

在嵌入式开发中学习Qt是否必要取决于具体情况。以下是一些考虑因素：

项目需求

如果嵌入式项目需要图形用户界面、跨平台性和高级的工具支持，学习Qt将是非常有益的，不过要根据项目的硬件平台，下面会进一步介绍。

开发人员经验

对于已经具备丰富嵌入式经验的开发者，学习Qt可能只是一个额外的技能，而对于初学者，Qt的学习可以帮助建立更全面的技术栈。

硬件平台

如果目标嵌入式设备的硬件平台对Qt的支持良好，那么学习Qt可能是更为明智的选择。Qt被广泛用于嵌入式系统，可以运行在多种硬件平台上，包括：

• ARM架构：适用于大多数嵌入式系统，如Raspberry Pi、BeagleBone等。
• x86架构：适用于一些嵌入式系统和嵌入式PC。

通常可以在这些硬件平台上运行的操作系统一般是Linux，常见的发行版Ubuntu，Debian也都可以运行得比较好。

最后

在嵌入式开发中学习Qt是否必要并没有一概而论的答案。Qt作为一个功能强大的工具，在一些项目中提供了明显的优势。

然而，开发者仍然需要根据具体情况权衡利弊，考虑项目需求、个人经验和时间资源等因素，做出明智的决策。

无论是否选择学习Qt，掌握嵌入式开发的基本技能是确保成功的关键。

Qt只是嵌入式开发中的一小块

查看原文：
https://www.dianyuan.com/eestar/article-8288.html

更多精彩内容，尽在电子星球 APP（https://www.eestar.com/）

六篇技术文章，让你秒懂电容的脾气秉性

七篇DIY技术文章献给你，让你脑洞全开

五篇文章帮你开启DSP的学习思路

汇总篇：关于PID知识，重点在此