jTag

学习嵌入式开发时，会阅读相关的专业文献。对于文献中经常出现的缩写形式的专业名词，做了一些积累。现于此博文中做个简单的分享，希望能对后来人有所帮助，平稳地入门嵌入式。 注：博文内容仅可用于参考，遇到分歧时，还需请教专业人士！ A 序号 英文缩写 英文 1 API Application Programming Interface 2 ARM Advanced RISC Machines 3 ADSL Asymmetric Digital Subscriber Line 4 ACP Accelerator Coherency Port 5 ATPCS ARM-Thumb procedure call standard 6 AMBA Advanced Microcontroller Bus Architecture 7 ASB Advanced System Bus 8 APB Advanced Peripheral Bus 9 AHB Advanced High-performance Bus 10 AXI Advanced eXtensible Interface 11 ACE Advanced Trace Bus 12 ADEOS Adaptive Domain Environment for Operating System   B 序号 英文缩写 英文 1 BSP Board

TL5509- EVM是 广州创龙基于SOM-TL5509核心板研发的 一款 TI C 55 x 架构的定点TMS320VC5509A低功耗 DSP 开发板 ，采用沉金无铅工艺的 2 层板设计， 专业的PCB Layout保证信号完整性的同时 ， 经过严格的质量控制 ，满足多种环境应用 。采用核心板+底板 方式， 尺寸为 200 mm*1 06.6.5m m， 核心板采用 SO-DIMM、 200pin 金手指连接器 ， 稳定、可靠、便捷，可以帮助客户 快速评估 核心板 性能。 SOM-TL5509 核心板采用高密度沉金无铅工艺 4 层板设计，尺寸为 67.6 mm* 31 mm，采用原装进口美国德州仪器最新 TI TMS320 VC5509A ，C55x定点DSP，主频200MHz 处理器， 高性能 音 频处理能力。 核心板引出了的全部接口资源，帮助开发者快速进行二次开发 。 电源接口和拨码开关 采用 5 V@2A 直流电源供电， J1 为 电源接口， SW1 为 电源 SWITCH 开关，原理图如下图所示： JTAG 仿真器接口 可以通过JTAG接口 （ CON 4） 烧写 程序和进行软件调试 CON 4 接口 包含 了完整 TI 14Pin Rev B JTAG标准信号，各引脚定义如下图 ： 来源： https://my.oschina.net/u/4169033/blog

TL2837x- Easy EVM 是一款基于广州创龙SOM-TL2837 x 核心板所设计的高端单/双核浮点开发板，它为用户提供了SOM-TL2837 x 核心板的测试平台，用于快速评估SOM-TL2837 x 核心板的整体性能。 JTAG 仿真器接口 可以通过JTAG接口（CON4）烧写程序和进行软件调试。CON13接口包含了完整14Pin JTAG标准信号，各引脚定义如下图 ： ADC 接口 板载 1 个 24 路 12bit 的 ADC 接口 ， 对应 J 5 接口， 采用 排针 （ 30 pin ）连接方式 ，接口定义如下图所示： 来源： oschina 链接： https://my.oschina.net/u/4169033/blog/3136525

芯片为TMS320F28035，新投的PCB，送焊回来后连接JTAG仿真器发现连接不上，报错如下： (Error -516 @ 0x0) The user selected specific frequency failed the scan-path reliability test. The utility or debugger requested the JTAG controller and cable, that generate the JTAG clock, to provide a user selected fixed frequency. The built-in scan-path reliability test has failed. This indicates that the JTAG controller and its cable cannot reliably communicate with the target system at that frequency. (Emulation package 5.1.450.0) 截图如下： 仿真器是 XDS100 V3。这个错误说仿真器在与DSP通讯过程中，发生了不稳定因素，导致时钟线信号错误，从而校验失败。 这个表明了两点：一是JTAG识别到了DSP；二是通讯中出现了导致不稳定因素

I have a Keil ULINK2 USB emulator box attached to the JTAG connector on my board, which is working fine with the Cortex-M3 CPU onboard (TI/Stellaris/LuminaryMicro LM3S series). It seems that both a JTAG and a SWJ-DP port share the same pins (and thus connector on your board) on these CPUs. One appears not to have ITM (printf) capability, the other does. The previous firmware people have always used stdio to UART (serial port), but I need the serial port freed up so that debug messages do not interfere with other data being sent/received to/from the serial port, thus I need for trace messages

参考： https://blog.csdn.net/wwt18811707971/article/details/78678059 所谓启动，一般来说就是指我们下好程序后，重启芯片时，SYSCLK的第4个上升沿，BOOT引脚的值将被锁存。用户可以通过设置BOOT1和BOOT0引脚的状态，来选择在复位后的启动模式。 STM32上电或者复位后，代码区始终从0x00000000开始，三种启动模式其实就是将各自存储空间的地址映射到0x00000000中。 （1）从Flash启动 ，将主Flash地址0x08000000映射到0x00000000，这样代码启动之后就相当于从0x08000000开始。 （2）从RAM启动 ，将RAM地址0x20000000映射到0x00000000,这样代码启动之后就相当于从0x20000000开始。 （3）从系统存储器启动 。首先控制BOOT0 BOOT1管脚，复位后，STM32与上述两种方式类似，从系统存储器地址0x1FFF F000开始执行代码。系统存储器存储的其实就是STM32自带的bootloader代码，在bootloader中提供了UART1的接口，通过此接口可以将用户所需的程序代码下载到主Flash中，下载完毕后，此时程序代码已经存储在主Flash当中，这时切换启动模式（从主Flash启动），复位后所执行的就是刚刚下载到Flash中的代码了。

参考： https://blog.csdn.net/wwt18811707971/article/details/78678059 所谓启动，一般来说就是指我们下好程序后，重启芯片时，SYSCLK的第4个上升沿，BOOT引脚的值将被锁存。用户可以通过设置BOOT1和BOOT0引脚的状态，来选择在复位后的启动模式。 STM32上电或者复位后，代码区始终从0x00000000开始，三种启动模式其实就是将各自存储空间的地址映射到0x00000000中。 （1）从Flash启动 ，将主Flash地址0x08000000映射到0x00000000，这样代码启动之后就相当于从0x08000000开始。 （2）从RAM启动 ，将RAM地址0x20000000映射到0x00000000,这样代码启动之后就相当于从0x20000000开始。 （3）从系统存储器启动 。首先控制BOOT0 BOOT1管脚，复位后，STM32与上述两种方式类似，从系统存储器地址0x1FFF F000开始执行代码。系统存储器存储的其实就是STM32自带的bootloader代码，在bootloader中提供了UART1的接口，通过此接口可以将用户所需的程序代码下载到主Flash中，下载完毕后，此时程序代码已经存储在主Flash当中，这时切换启动模式（从主Flash启动），复位后所执行的就是刚刚下载到Flash中的代码了。

这里分析一个ARM板子JTAG调试器经常连接失败，只能偶尔连上目标板问题。 背景 这是原先另一个部门的板子，在部门合并之后，最近要对这个板子的代码体系进行转移，在过问开发进度时，工程师反映这个板子调试很难连接，所以错误不好定位。这个问题前段时间反映过，但是当时比较忙，没有过问。现在看起来这个问题影响问题定位了，所以看起来这个问题需要彻底看一下了。听原先负责这个板子的工程师，这些年也都是这样，这个芯片很难连接，以前如果不行就换板子。这个芯片是LPC2136，我们部门原先并不使用，但是LPC2132和LPC2134则是使用过的，并不存在问题。简单测试了一下这个板子，确实是连接非常困难。 接线查看 首先找了对比板子LPC2132，连接非常顺利。对比两个板子的图，分析JTAG接口连接，从原理图上看，JTAG接口连接并没有什么不妥，和对比板子一致，量硬件连接，也没有问题。连接总是提示“Failed to connect”。看来只能对JTAG进行分析了。 JTAG信号分析 把所有的JTAG信号线飞出来，接上逻辑分析仪，采集JTAG信号。首先采集正常的板卡的信号，如下： 从上到下，顺序为TRST，TDI，TMS，TCK，RTCK，TDO，从图中看，有来有回，一切正常。只是中间有一个异常，我最初设定为用TRST下降沿触发，却没有抓到，从波形看，TRST确实一直为高，这个当时也没有在意，不影响抓信号

经常有项目要求固件远程更新，通过串口、GPRS、4G等等方式。下面介绍下STM32远程固件更新的方法。 IAP是In Application Programming的首字母缩写，IAP是用户自己的程序在运行过程中对User Flash的部分区域进行烧写，目的是为了在产品发布后可以方便地通过预留的通信口对产品中的固件程序进行更新升级。 通常在用户需要实现IAP功能时，即用户程序运行中作自身的更新操作，需要在设计固件程序时编写两个项目代码，第一个项目程序不执行正常的功能操作，而只是通过某种通信管道(如USB、USART)接收程序或数据，执行对第二部分代码的更新；第二个项目代码才是真正的功能代码。这两部分项目代码都同时烧录在User Flash中，当芯片上电后，首先是第一个项目代码开始运行，它作如下操作： 1）检查是否需要对第二部分代码进行更新 2）如果不需要更新则转到4） 3）执行更新操作 4）跳转到第二部分代码执行 第一部分代码必须通过其它手段，如JTAG或ISP烧入；第二部分代码可以使用第一部分代码IAP功能烧入，也可以和第一部分代码一道烧入，以后需要程序更新是再通过第一部分IAP代码更新。 对于STM32来说，因为它的中断向量表位于程序存储器的最低地址区，为了使第一部分代码能够正确地响应中断，通常会安排第一部分代码处于Flash的开始区域，而第二部分代码紧随其后。

手动编译 编译器问题，肯定是GNU的大名鼎鼎的GCC了，与此相关的什么连接器，汇编器也都包含在内了。 针对arm的GCC，当然就是 arm-linux-gcc 了，我所用的版本就是友善之臂光盘自带arm-linux-gcc 4.4.3。也有资料说也可以用arm-elf-gcc，这个与arm-linux-gcc带的c库不同，是uclibc，更精简更适合嵌入式。 手动编译需要我们自己写 Makefile 文件 ，涉及到编译过程的依赖等细节问题。在我们实际开发中，可以不通过这种方式，但是需要了解这个过程。 自动编译 1 、 ADS1.2 ADS 是 ARM 公司的集成开发环境软件， ADS 包括了四个模块分别是： SIMULATOR ； C 编译器；实时调试器；应用函数库 。 特点： √ C 编译器效率极高；支持 C 以及 C++ ，使工程师可以很方便的使用 C 语言进行开发； √ 提供软件模拟仿真功能 ，使没有 Emulators 的学习者也能够熟悉 ARM 的指令系统； （直接就可以在IDE环境下，通过运行自己编写的汇编或C语言，查看ARM系统中寄存器的情况） √ 配合 FFT-ICE 使用， ADS1.2 提供强大的实时调试跟踪功能 , 片内运行情况尽在掌握； √ ADS1.2 需要硬件支持才能发挥强大功能，目前支持的硬件调试器有 Multi-ICE 以及兼容 Multi-ICE