admin管理员组

文章数量:1593159

曾几何时…
我天真的以为JLINK这么普遍的东西原本就应该是几十块钱的东西…
只到有一天突然发现淘宝上的JLINK不见了，取而代之的是ARMLINK和DAPLINK，然后搜索了一下才搞清楚事情的原委：

  1. 盗版问题初现（早期）
    随着 J-Link 在嵌入式开发中的普及，市场上开始出现大量的盗版产品。这些盗版 J-Link 设备价格低廉，但存在功能不全和稳定性差的问题。
    盗版 J-Link 主要通过淘宝等电商平台进行销售，对 SEGGER 的品牌和市场份额造成了负面影响。
  2. 初步反制措施（2010 年代中期）
    SEGGER 开始意识到盗版产品的泛滥，并逐步采取初步的反制措施。
    技术封锁：在 J-Link 固件和软件更新中引入了检测机制，防止盗版设备使用新功能。
    加密和授权管理：SEGGER 通过增加加密和授权管理来增强设备的防伪能力。
  3. 加强打击力度（2018 年左右）
    SEGGER 加大了对盗版 J-Link 的打击力度，发布公告明确表示将采取法律手段打击盗版行为。
    定期固件更新：SEGGER 持续通过软件更新加强对盗版的封锁，频繁发布固件更新来限制盗版设备的使用。
  4. 法律和平台投诉（2019 年起）
    SEGGER 开始正式对销售盗版 J-Link 的商家采取法律行动，包括起诉部分严重侵权的公司。
    合作举报：SEGGER 加强与淘宝平台的合作，通过举报和投诉的方式打击盗版销售。淘宝开始对涉嫌售卖盗版的店铺进行审核和清理。
  5. 淘宝平台整治行动（2020 年）
    全面下架：淘宝在接到多次投诉和法律压力后，加大对平台上盗版 J-Link 的整治力度。
    淘宝实施了严格的审查机制，对 J-Link 产品的销售进行了全面的清查，最终实现了盗版 J-Link 的大规模下架。
  6. 后续行动和现状（2021 年至今）
    SEGGER 继续与淘宝等电商平台合作，保持对盗版产品的高压打击态势。
    淘宝目前已基本清除了盗版 J-Link 的销售，并持续监控相关商品的上架情况。

随着盗版JLINK的下架，我第一次打开了SEGGER的网站，看到正版Jlink的价格，我悟了!


原来Jlink这么值钱！
正版的价格已经不是我等凡人能承受的起了。
魔高一尺，道高一丈，我泱泱大国岂会这么容易屈服于SEGGER的封锁，把 JLINK 的名字变成ARM仿真器继续开卖！


但是，其实拆开市面上常见的盗版jlink，质量真的是一言难尽，这样的东西在我手里至少坏的也有七八个了！

并且，SEGGER 通过技术封锁，在 J-Link 固件和软件更新中引入了检测机制，防止盗版设备使用新功能。目前盗版JLINK仿真器固件最高支持4.40的版本，如果安装了超过4.40版本的驱动，并且一旦升级就会造成Jlink无法使用。这些JLINK的报错，广大网友一定也被盗版JLINK深受其害过！

  1. 盗版检测：the connected probe appears to be a j-link clone

当使用非正常版本的JLink连接高版本的MDK时，再加上JLink驱动程序版本过高，就会被检测出这个问题。

  1. 连接故障：The connected J-Link is defective

问题出现的原因是keil5的J_Link驱动是最新版本的，而我们手里的J_Link固件不是最新版本的。

作为苦逼的嵌入式码农，解决日常的bug已经身心俱疲了，还要为动不动就宕机的工具耗费精力，婶可忍叔不可忍！

如果想自己做一款专属的烧录器，那ARMmbed开源已久的DAPLink一定是最佳的选择，俗话说站在站在巨人的肩膀上，才能与太阳肩并肩。

CMSIS-DAP介绍
在早期的STM32调试中，我们一般采用的是ST官方的STLink进行程序的烧写和调试，后来ARM开发了一个新兴的项目CMSIS-DAP，CMSIS-DAP是一个ARM开源的一个调试器项目，其支持所有Cortex-A/R/M的元器件，采用了HID连接，可实现无驱动连接电脑并进行调试。CMSIS-DAP的理解可以分为两部分，CMSIS和DAP。CMSIS全称为ARMCortex-M SoftWare Interface Standard，是一种ARM的软件接口标准；而DAP全程为Debug Access Port，即软件调试访问口，CMSIS-DAP可以理解为ARM开发的一种软件调试接口，可以使用JATG或SWD的连接方式连接到ARM下的Cortex-A/R/M系列元器件。CMSIS-DAP支持包含一个或多个Cortex处理器的目标设备。也就是说CMSIS-DAP支持多设备同时烧写。

移植DAPLINK可以分为两步，第一步移植在线下载调试部分CMSIS-DAP，ARM最新的代码位置就在MDK的安装路径...\AppData\Local\Arm\Packs\ARM\CMSIS\5.9.0\CMSIS\DAP\Firmware\Source，当前最新的版本为V2.1.1，移植DAP的过程，其实也就是将CMSIS-DAP协议对接到USB协议栈的过程，文件如下：

DAPLink作为ARM开源的调试和编程工具，提供了广泛的支持和易用性，然而由于CMSIS-DAP协议传输效率不高，USB HID协议的低效传输、较小的数据块大小、较低的SWD/JTAG时钟频率，以及硬件和固件没有进行专门的速度优化。尽管DAPLink具有较好的通用性和兼容性，但在性能上与专业的JLINK调试工具相比有所不足。

既然要做，就肯定要做到性能最好的，为了弥补DAPLINK性能上的不足，在USB协议上替换成了传输速度更快的CherryUSB协议栈，硬件上采用了先辑半导体的高性能芯片HPM5301，该芯片主频高达480MHz，内置PHY的高速USB接口，并且深度优化了DAPLink固件中的数据处理和通信代码，减少固件内部的延迟和等待时间，提高SWD时钟速度到10M。
优化后的时钟速率如下：

与目前市面上最新的J-LINK-V12速度对比，目标芯片使用STM32H743，开发环境MDK V5.39，分别使用自己做的DAPLINK和Jlink V12将2558KB的HEX文件下载到内部FLASH中。使用逻辑分析仪测试时钟引脚，计算出擦除，编程，校验全过程的时间，自己做的下载器使用时间为24.205秒，Jlink V12使用时间为33.439秒，测试数据如下图：

Jlink V12测试结果：

自己做的DAPLINK测试结果：

测试结果对比：

调试器总耗时（擦除，编程，校验）
MicroLink24.205秒
J-LINK V1233.439秒

经过对比可以发现，下载速度已经超过了最新的JLINKV12。

DAPLINK还支持一路虚拟串口，但是虚拟串口的功能其实与DAPLINK关系不大，虚拟串口是利用USB协议栈的CDC类设备，CDC是USB定义的设备类之一，允许通信设备通过USB接口进行数据传输。

下载速度提升上来了，USB转串口的速度自然也不能落下，一般的USB转串口波特率速度支持到2M就已经很猛了，但是谁让我上了国产最强MCU先辑的主控，直接把串口性能拉满，使串口最大支持10M波特率，无丢包。

使用逻辑分析仪抓取波形如图所示，可以看到每个bit传输的时间为1/10M=100ns。

以上就是移植DAPLINK最基本的在线下载调试功能，第二步是移植DAPLINK的离线下载功能，离线烧写器的实现主要通过CMSIS-DAP里的DAP连接协议来进行实现，这一部分ARM官方已经帮我们写好了，DAP离线下载主要分为几个过程：初始化DAP–>DAP连接芯片–>确认连接方式–>清除目标板读保护（可忽略）–>清除目标板Flash–>烧写程序–>复位运行。
连接方式分为SWD接口，和JTAG接口，我们需要移植的是官方代码的.../DAPLink/source/daplink/interface /swd_host.c

SWD（Serial Wire Debug）接口是ARM为Cortex-M系列处理器设计的一种两线制调试协议，旨在为嵌入式系统提供低引脚占用、高效率的调试功能。它是JTAG（Joint Test Action Group）接口的替代方案，以简化硬件设计、减少管脚使用，同时保留高效调试功能。

要想实现离线下载，连接上芯片以后，还要提供目标芯片的FLASH烧写算法，才能对目标芯片进行下载，理论上我们要为每颗想要支持的芯片提供相应的烧写算法，可喜的是MDK的安装路径上为我们提供了这样的算法文件，比如STM32F4系列的下载算法目录就在...\Local\Arm\Packs\Keil\STM32F4xx_DFP\2.17.1\CMSIS\Flash,STM32F4xx文件夹是下载算法的源码，FLM文件就是下载算法。

FLM文件本质是一个ELF格式的文件，Keil规定了FLM文件的构成，它是一成不变的，包含强制性flash编程函数Init、UnInit、EraseSector和ProgramPage。可选地，根据设备特性，可以实现函数EraseChip、BlankCheck和Verify 。

我们解析一下现有的FLM文件，以STM32F4xx_1024.FLM为例。

打开命令行工具，输入arm-none-eabi-readelf -a STM32F4xx_1024.FLM：

$ arm-none-eabi-readelf -a STM32F4xx_1024.FLM
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          12172 (bytes into file)
  Start of section headers:          12236 (bytes into file)
  Flags:                             0x5000000, Version5 EABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         2
  Size of section headers:           40 (bytes)
  Number of section headers:         16
  Section header string table index: 15

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] PrgCode           PROGBITS        00000000 000034 000144 00  AX  0   0  4
  [ 2] PrgData           PROGBITS        00000144 000178 000004 00  WA  0   0  4
  [ 3] DevDscr           PROGBITS        00000148 00017c 0010a0 00   A  0   0  4
  [ 4] .debug_abbrev     PROGBITS        00000000 00121c 0005a4 00      0   0  1
  [ 5] .debug_frame      PROGBITS        00000000 0017c0 000104 00      0   0  1
  [ 6] .debug_info       PROGBITS        00000000 0018c4 00064c 00      0   0  1
  [ 7] .debug_line       PROGBITS        00000000 001f10 000218 00      0   0  1
  [ 8] .debug_loc        PROGBITS        00000000 002128 0001b8 00      0   0  1
  [ 9] .debug_macinfo    PROGBITS        00000000 0022e0 000614 00      0   0  1
  [10] .debug_pubnames   PROGBITS        00000000 0028f4 000096 00      0   0  1
  [11] .symtab           SYMTAB          00000000 00298c 000110 10     12   9  4
  [12] .strtab           STRTAB          00000000 002a9c 000100 00      0   0  1
  [13] .note             NOTE            00000000 002b9c 00001c 00      0   0  4
  [14] .comment          PROGBITS        00000000 002bb8 000334 00      0   0  1
  [15] .shstrtab         STRTAB          00000000 002eec 0000a0 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  y (purecode), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000034 0x00000000 0x00000000 0x00148 0x00148 RWE 0x4
  LOAD           0x00017c 0x00000148 0x00000148 0x010a0 0x010a0 R   0x4

 Section to Segment mapping:
  Segment Sections...
   00     PrgCode PrgData
   01     DevDscr

There is no dynamic section in this file.

There are no relocations in this file.

There are no unwind sections in this file.

Symbol table '.symtab' contains 17 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 NOTYPE  LOCAL  DEFAULT    1 $t
     2: 00000122     0 NOTYPE  LOCAL  DEFAULT    1 $d
     3: 00000144     0 NOTYPE  LOCAL  DEFAULT    2 $d.realdata
     4: 00000148     0 NOTYPE  LOCAL  DEFAULT    3 $d.realdata
     5: 00000000     0 FILE    LOCAL  DEFAULT  ABS FlashPrg.c
     6: 00000000     0 SECTION LOCAL  DEFAULT    1 .text
     7: 00000000     0 FILE    LOCAL  DEFAULT  ABS FlashDev.c
     8: 00000148  4256 SECTION LOCAL  DEFAULT    3 .constdata
     9: 00000000     0 NOTYPE  GLOBAL HIDDEN   ABS BuildAttributes$$THM_ISAv
    10: 00000001    28 FUNC    GLOBAL HIDDEN     1 GetSecNum
    11: 0000001d    46 FUNC    GLOBAL HIDDEN     1 Init
    12: 0000004b    14 FUNC    GLOBAL HIDDEN     1 UnInit
    13: 00000059    44 FUNC    GLOBAL HIDDEN     1 EraseChip
    14: 00000085    76 FUNC    GLOBAL HIDDEN     1 EraseSector
    15: 000000d1    82 FUNC    GLOBAL HIDDEN     1 ProgramPage
    16: 00000148  4256 OBJECT  GLOBAL HIDDEN     3 FlashDevice

No version information found in this file.

Displaying notes found at file offset 0x00002b9c with length 0x0000001c:
  Owner                 Data size       Description
  ARM                  0x0000000c       Unknown note type: (0x40000000)

通过Symbol table信息我们可以找到Init、UnInit、EraseSector和ProgramPage函数所在的位置。

我们还需要根据Section Headers所描述的位置提取出Prgcode(代码)，PrgData(数据)，DevDscr(设备描述)的信息。

在命令行中输入arm-none-eabi-objdump -s -d STM32F4xx_1024.FLM：-s参数可以将所有段的内容一十六进制方式打印出来，-d参数可以将所有包含指令的段反汇编。

$ arm-none-eabi-objdump -s -d STM32F4xx_1024.FLM

STM32F4xx_1024.FLM:     file format elf32-littlearm

Contents of section PrgCode:
 0000 0003000e 202802d3 4009001d 70471028  .... (..@...pG.(
 0010 02d30009 c01c7047 80087047 42484149  ......pG..pGBHAI
 0020 41604249 41600021 0160c168 f0221143  A`BIA`.!.`.h.".C
 0030 c1604069 800606d4 3e483d49 01600621  .`@i....>H=I.`.!
 0040 41603d49 81600020 70473748 01694205  A`=I.`. pG7H.iB.
 0050 11430161 00207047 10b53348 01690424  .C.a. pG..3H.i.$
 0060 21430161 0169a203 11430161 3349314a  !C.a.i...C.a3I1J
 0070 00e01160 c368db03 fbd40169 a1430161  ...`.h.....i.C.a
 0080 002010bd 30b5fff7 bbff2749 ca68f023  . ..0.....'I.h.#
 0090 1a43ca60 02240c61 0a690007 400e0243  .C.`.$.a.i..@..C
 00a0 0a610869 e2031043 08612448 214a00e0  .a.i...C.a$H!J..
 00b0 1060cd68 ed03fbd4 0869a043 0861c868  .`.h.....i.C.a.h
 00c0 0006000f 03d0c868 1843c860 012030bd  .......h.C.`. 0.
 00d0 70b5154d c91c8908 eb688900 f0263343  p..M.....h...&3C
 00e0 eb600023 2b61164b 17e02c69 1c432c61  .`.#+a.K..,i.C,a
 00f0 14680460 ec68e403 fcd42c69 64086400  .h.`.h....,id.d.
 0100 2c61ec68 2406240f 04d0e868 3043e860  ,a.h$.$....h0C.`
 0110 012070bd 001d121d 091f0029 e5d10020  . p........)...
 0120 70bd0000 23016745 003c0240 ab89efcd  p...#.gE.<.@....
 0130 55550000 00300040 ff0f0000 aaaa0000  UU...0.@........
 0140 01020000                             ....
Contents of section PrgData:
 0144 00000000                             ....
Contents of section DevDscr:
 0148 01015354 4d333246 34787820 466c6173  ..STM32F4xx Flas
 0158 68000000 00000000 00000000 00000000  h...............
 0168 00000000 00000000 00000000 00000000  ................
 0178 00000000 00000000 00000000 00000000  ................
 0188 00000000 00000000 00000000 00000000  ................
 0198 00000000 00000000 00000000 00000000  ................
 01a8 00000000 00000000 00000000 00000000  ................
 01b8 00000000 00000000 00000000 00000000  ................
 01c8 00000100 00000008 00001000 00040000  ................
 01d8 00000000 ff000000 64000000 70170000  ........d...p...
 01e8 00400000 00000000 00000100 00000100  .@..............
 01f8 00000200 00000200 ffffffff ffffffff  ................

我们所需要的正是以上信息，接下来的任务只需要将以上文件的几个函数提取出来即可



static const uint32_t STM32F4xx_1024_prog_blob[] = 
{
    0XE00ABE00,0X062D780D,0X24084068,0XD3000040,0X1E644058,0X1C49D1FA,0X2A001E52,0X4770D1F2,
    0X0E000300,0XD3022820,0X1D000940,0X28104770,0X0900D302,0X47701CC0,0X47700880,0X49424843,
    0X49436041,0X68016041,0X0F090709,0X68C16001,0X431122F0,0X694060C1,0XD4060680,0X493D483E,
    0X21066001,0X493D6041,0X20006081,0X48374770,0X05426901,0X61014311,0X47702000,0X4833B510,
    0X24046901,0X61014321,0X03A26901,0X61014311,0X4A314933,0X6011E000,0X03DB68C3,0X6901D4FB,
    0X610143A1,0XBD102000,0XF7FFB530,0X4927FFB9,0X23F068CA,0X60CA431A,0X610C2402,0X06C0690A,
    0X43020E00,0X6908610A,0X431003E2,0X48246108,0XE0004A21,0X68CD6010,0XD4FB03ED,0X43A06908,
    0X68C86108,0X0F000600,0X68C8D003,0X60C84318,0XBD302001,0X4D15B570,0X08891CC9,0X008968EB,
    0X433326F0,0X230060EB,0X4B16612B,0X692CE017,0X612C431C,0X60046814,0X03E468EC,0X692CD4FC,
    0X00640864,0X68EC612C,0X0F240624,0X68E8D004,0X60E84330,0XBD702001,0X1F091D00,0X29001D12,
    0X2000D1E5,0X0000BD70,0X45670123,0X40023C00,0XCDEF89AB,0X00005555,0X40003000,0X00000FFF,
    0X0000AAAA,0X00000201,0X00000000,
};

static const uint32_t STM32F4xx_1024_flash_dev[] = 
{
    0X54530101,0X4632334D,0X20787834,0X20424D31,0X73616C46,0X00000068,0X00000000,0X00000000,
    0X00000000,0X00000000,0X00000000,0X00000000,0X00000000,0X00000000,0X00000000,0X00000000,
    0X00000000,0X00000000,0X00000000,0X00000000,0X00000000,0X00000000,0X00000000,0X00000000,
    0X00000000,0X00000000,0X00000000,0X00000000,0X00000000,0X00000000,0X00000000,0X00000000,
    0X00010000,0X08000000,0X00100000,0X00000400,0X00000000,0X000000FF,0X00000064,0X00001770,
    0X00004000,0X00000000,0X00010000,0X00010000,0X00020000,0X00020000,0XFFFFFFFF,0XFFFFFFFF,
};

static const program_target_t STM32F4xx_1024_flash =
{
    (RAM_BASE + 0X003D),  // Init
    (RAM_BASE + 0X006F),  // UnInit
    (RAM_BASE + 0X007D),  // EraseChip
    (RAM_BASE + 0X00A9),  // EraseSector
    (RAM_BASE + 0X00F5),  // ProgramPage
    0x0,                    // Verify,
    // BKPT : start of blob + 1
    // RSB  : address to access global/static data
    // RSP  : stack pointer
    {
        (RAM_BASE + 1),
        (RAM_BASE + 0x168),
        (RAM_BASE + 0X800),
    },
    (RAM_BASE + 0XA00),                      // mem buffer location
    RAM_BASE,                      // location to write prog_blob in target RAM
    sizeof(STM32F4xx_1024_prog_blob),    // prog_blob size
    STM32F4xx_1024_prog_blob,     // address of prog_blob
    0x00000400,                      // ram_to_flash_bytes_to_be_written
    0x0                    
};

以此类推，我们将想要支持的目标芯片的下载算法一个个解析出来，放到工程中，就完成了DAP离线下载的主要几个过程：初始化DAP–>DAP连接芯片–>确认连接方式–>清除目标板Flash–>烧写程序。

还剩一个最重要的步骤，我们要烧写的文件从哪里来？

有两种获取文件的方式：

  • 将要烧写的文件放到外部flash中，通过文件系统读取文件（脱机下载）
  • 通过模拟U盘，将烧写文件拖拽到U盘中，直接一包包转发出去（拖拽下载）

两种获取文件的方式，分别实现的两种离线下载的方式，DAPLINK的源码提供的正是拖拽下载的方式，然而美中不足的是ARM官方DAPLINK的拖拽烧录只能针对某一个型号单片机，要想支持其他单片机必须手动更新调试器的固件，对使用者门槛较高，导致这么方便的功能食之无味弃之可惜。

作为一个下载器，如果只能对一款芯片进行离线下载，那就太不合格了，所以我对Cortex-M系列的大量芯片做了适配工作，其中意法半导体STM32，国产芯片兆易创新GD32基本都以适配完成，还在持续增加其他型号。

U盘拖拽下载支持HEX文件和BIN文件，HEX文件自带地址信息，自动根据HEX中的地址选择烧录的位置，BIN文件默认下载的地址为0x08000000，以下演示视频是将HEX文件复制到U盘中，完成固件下载：

U盘拖拽下载

看到此处，自制的这款下载器已经可以满足我的日常需求了，但是，你以为就此结束了吗？

作为一个搬了小十年砖的码农，深知并不是每一个设备装机后都会预留SWD接口或者JTAG接口的，并且一定一定出厂的产品中还存留着一些漏网之鱼的BUG等着客户去踩雷。

所以我在想能不能提供一个稳定可靠的BootLoader程序嵌入到产品中，一旦需要升级，仅仅通过预留的串口、485或者其他通信接口，客户就可以傻瓜式的将升级文件拖拽到虚拟U盘中自动完成升级固件呢，就像这样：
视频是将bin文件复制到U盘中，完成升级文件的传输

microlink U盘拖拽 ymodem下载

要想实现这样的功能，我在这个下载器中内置了ymodem文件传输协议。Ymodem协议在多次重传时仍能保持数据的完整性，非常适用于嵌入式系统的固件更新。

YModem协议是一种串行通信文件传输协议，基于早期的XModem协议进行改进，增加了对批量传输多个文件的支持，并在传输时提供了文件名、大小、修改日期等元数据信息。它使用**CRC（循环冗余校验）**进行错误检测，相比XModem具有更高的传输效率，并支持1KB的数据块大小（YModem-1K），因此能加快大文件的传输速度。

通过ymodem协议离线下载文件的数据流如下：

要想使用内置的ymodem协议发送文件，仅有下载器还是不够的，还需要目标设备支持ymodem协议接收文件，好人要做就要做到底，我做了一个非常稳定的BootLoader开源代码框架：
MicorLink简介：https://microboot.readthedocs.io/zh-cn/latest/tools/microlink/microlink/
MicorBoot简介：https://microboot.readthedocs.io/zh-cn/latest/
MicorBoot开源代码：https://github/Aladdin-Wang/MicroBoot

至此，本下载器功能已基本完成， 但是还远远没有结束。。。

功能特点

  • 支持SWD/JTAG接口，下载调试速度超越JLINK V12（时钟10Mhz）
  • 支持使用OpenOCD的IDE下载调试ARM/RISC-V等芯片
  • 支持USB转串口，最大10M波特率无丢包
  • 支持大量Cortex-M系列芯片U盘拖拽下载，内置大量下载算法，自动识别目标芯片
  • 内置ymodem协议栈，U盘拖拽文件自动触发ymodem通过串口传输文件到目标设备（需配合带ymodem协议的bootloader）
  • 支持系统固件升级，为后续添加更多功能
  • 采用winusb对window10免驱，即插即用
  • 支持3V3/5V大电流输出电源
  • 内置防倒灌和过流保护，外部电流无法反向流入USB口，防止损坏USB
  • 支持通过U盘读取目标芯片固件
  • 支持通过U盘读取目标芯片任意文件
  • 支持Cortex-M系列芯片脱机下载，自动识别目标芯片，自动触发下载
  • 支持RISC-V系列芯片U盘拖拽下载，内置大量下载算法，自动识别目标芯片
  • 支持RISC-V系列芯片脱机下载，自动识别目标芯片，自动触发下载

结合以上特点，为开发者提供了下载调试，批量生产，售后维护，固件升级等一站式解决方案。

本文标签： 下载器jlinkDAPLink

版权声明：本文标题：受够了盗版jlink，我手搓了一个高速DAPLINK下载器 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://m.elefans.com/xitong/1728154421a1147555.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。