您尚未登录。

#1 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2024-07-24 19:49:31

cyj6588 说:

你好,大佬,请问如何解决的不支持SWD软复位的问题,能分享下经验吗,多谢!

// NVIC: Application Interrupt/Reset Control Register
#define NVIC_AIRCR     (NVIC_Addr + 0x0D0C)
#define VECTKEY        0x05FA0000  // Write Key

void swd_set_target_soft_reset()
{
  swd_write_word(NVIC_AIRCR, VECTKEY | 0x7);
}

此函数放在 DAP_SWJ_Pins 中检查 DAP_SWJ_nRESET 的分支中,这样无论Keil设置的是哪种复位都会同时进行软/硬复位:

  if ((select & (1U << DAP_SWJ_nRESET)) != 0U){
    if((value >> DAP_SWJ_nRESET) == 0)
      swd_set_target_soft_reset();
    PIN_nRESET_OUT(value >> DAP_SWJ_nRESET);
  }

#2 Re: Cortex M0/M3/M4/M7 » Keil 通过 DAPLink 连结 STM32F411 时,不发送 JTAG-to-SWD 序列。。 » 2023-07-05 14:48:12

抓取的数据包是在Keil进行什么操作时进行的?调试器中选择的协议是SWD吗?在选择协议的时候抓包,然后看下是否有切换协议的动作,其他动作有可能不再下发模式切换请求。这边测试5.29没有问题,方便的话可以上传一个5.36 MDK\ARM\BIN文件夹下的CMSIS_DAP.dll,这边测试下。

"使用 Keil 连接芯片时失败",使用的DAPLink是一直失败,还是偶尔失败;其他型号的芯片是否有相同现象,不过推测和芯片型号没有关系,可以降低SWD频率试一下。

#3 Re: Cortex M0/M3/M4/M7 » 求推荐宽供电范围,而且带USB的单片机 » 2023-05-05 10:50:55

@Blueskull
楼主的意思是节约成本,基于Cortex-M的MCU,FPGA有点偏离主题了。目前的问题就是不用电平转换芯片,是否能够做到,个人看法是做不到(其他FPGA增加成本方案除外)。

#4 Re: Cortex M0/M3/M4/M7 » 求推荐宽供电范围,而且带USB的单片机 » 2023-05-04 11:30:10

Blueskull 说:

@海石生风

他指的是USB低速和全速需要最低2.8V逻辑高电平输出,通常需要3.0V~3.6V供电。

对的,楼主的意思想实现MCU的SPI能够兼容一个比较大的电压范围,但是又想省去电平转换芯片(例如常用的74LVC245),那么我的一种思路就是动态调整MCU的供电电平(无论外部的LDO还是内部的LDO),VREF可以通过ADC实现,但是怎么调节LDO呢,供电一旦变化,MCU的最高主频也会变,外设主频也会跟着变,问题变复杂了,所以我认为这一思路不可行,想听听有无其他变通方案,可能孤陋寡闻,愿闻其详。

#5 Re: Cortex M0/M3/M4/M7 » 求推荐宽供电范围,而且带USB的单片机 » 2023-05-03 23:12:32

@海石生风
MCU总线外挂的均是外设啊,UART,USB,CAN等等。SPI要看MCU接入的SPI芯片规格,低压系列,通常芯片型号中有L,不支持5V。该楼主是要想通过USB实现宽电压的SPI支持,我想他的意思应该不只是3V3和5V,应该是1.7-5.5V这样一个范围,如果不用电压转换芯片,有好的方案可以抛出来一起讨论。

#6 Re: Cortex M0/M3/M4/M7 » 求推荐宽供电范围,而且带USB的单片机 » 2023-05-03 23:04:30

iamseer 说:
llinjupt 说:

@海石生风,USB外设比较特殊,规定了电平,SPI模块有提供独立的LDO?5V的MCU,例如沁恒的51系列,5V供电时SPI对外也是5V,需要电平转换芯片。

那也不一定。 ch552是5v但是ch559就只有3.3v

这里说的不严谨,改成支持GPIO 5V输出的系列,(记得CH551/2的有些脚5V供电时,也只能3V3)。

#7 Re: Cortex M0/M3/M4/M7 » 求推荐宽供电范围,而且带USB的单片机 » 2023-05-03 17:43:00

@海石生风,USB外设比较特殊,规定了电平,SPI模块有提供独立的LDO?5V的MCU,例如沁恒的51系列,5V供电时SPI对外也是5V,需要电平转换芯片。

#8 Re: Cortex M0/M3/M4/M7 » 求推荐宽供电范围,而且带USB的单片机 » 2023-05-02 12:30:04

@wh201906
个人感觉方案不可行,GPIO的电平和MCU供电电平相关,难道要调节MCU的LDO?而MCU的主频和电压也是有关的,USB时钟通常来自主频的分频,不是更复杂了?I/O电平转换芯片都是有VREF参考电平输入的,MCU如何输入该参考电平并进行电压调节?

目前未看到集成电平转换模块的MCU存在,可能是孤陋寡闻,如有愿闻其详。另外从转换芯片价格看,即便集成进去猜测成本未必有竞争力。

#9 Re: Cortex M0/M3/M4/M7 » 求推荐宽供电范围,而且带USB的单片机 » 2023-05-01 22:40:47

USB 3V3电平要求,所以即便支持宽电压供电,还是要3V3,只是GPIO可以容忍5V,但是PY全系列手册未提到3V3时容忍5V,好奇楼主为何有如此需求。

#10 Re: Cortex M0/M3/M4/M7 » 国产王炸中的战斗机-普冉py32f003/py32f030(价格6毛起步) » 2023-04-16 16:53:40

STM8S上有True open drain 功能,可以开漏上拉到5V;该芯片没有此功能,3V3供电使用时需要注意。

#11 Re: Cortex M0/M3/M4/M7 » 国产王炸中的战斗机-普冉py32f003/py32f030(价格6毛起步) » 2023-04-16 12:17:12

该系列好像没有3V3供电时,可以耐受5V的PIN,开漏输出上拉不到5V,只有大约3.6V。

#12 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2023-04-07 09:47:35

Copper 说:

@llinjupt
这个上市的时候会支持比如GD32VF103这种risc-v芯片的下载调试么?另外lz有什么淘宝店之类的么?

国内很多RISC-V芯片调试下载机制都是基于开源的DAPLink魔改的,但是又没有开放协议(因为DAPLink毕竟是ARM开源出来的,但是RISC-V又是直接对手,所以...),所以需要进行协议分析并实现,但是目前看国内的这类芯片协议还不够稳定,一直在更新,而ARM的SWD/JTAG都是统一稳定的,每家芯片厂商只要采用ARM架构,那么就不需要重复实现这套协议;但是国内的RISC-V芯片厂商每家都有自己的一套私有协议,所以需要花很多时间进行协议分析和再实现,并且厂商更新后并不会说明更新部分,可能导致已发布固件无法工作,影响用户体验,得不偿失,至少目前阶段不会花时间支持,除非厂商合作或者开放协议。

刚刚看了下GD32V系列手册,好像是使用的原生的 RISC-V 标准配置和链状连接的 TAP 控制器来实现的。调试功能集成在 RISC-V 内核中。调试系统支持 JTAG 调试。这样看使用JLINK或者DAPLink,上位机直接采用Openocd是直接支持的,有个前提:DAPLink必须支持JTAG协议,市面上有些DAPLink可能没有实现JTAG协议。

#13 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2023-03-22 12:19:46

@huy666, 不用着急,功能无限版,暂命名为 iLINK Infinity,二季度国内上市,支持多种模式无缝切换,不丢固件,
支持 DAPLINK的V1/V2版本,全功能支持JTAG.SWD,SWO,
支持 STLINKV2 ,支持SWIM模式下带串口功能,原厂ST也无此功能,全功能支持JTAG,SWD,SWO
支持 STLINKV2.1,所有版本均支持原厂最新软件 STM32CubeProgrammer, 国内套壳的很多不支持该软件;全功能支持JTAG,SWD,SWO
支持 BLACK Magic Probe,用于开源环境的gdb调试
最最重要的是,支持官方固件升级。

支持 JLINK OB,该模式如果Segger官方有意见,可能会拿掉。

支持 AVRISP,全协议: ICSP,UPDI,PDI,TPI,上位机采用Arduino使用的开源AVRDUDE(最近替它的maintainer干了不少活,开源确实需要一种精神)
支持 AVRMKII,全协议,支持官方Atmel Studio.
支持 USBASP,该模式除了烧写AVR芯片以外,支持SPI/25/45 FLASH和I2C的 EEPROM烧写。

支持STC免按键烧写
支持 ARDUINO  optboot/urclock 模式烧写
支持供电脚开关,有些芯片烧写需要先下电,这样用户可以直接通过命令控制电源通断。

最最最重要的是,该硬件平台是开放的,提供DIY模式和硬件电路,用户可以自己开发调试器/烧写器固件,当然也可以开发任何自己喜欢的东西。
直接将固件拖入虚拟U盘即可。所以您只要知道目标芯片/设备/LCD/模块等的协议,就可以自己DIY。
而DIY的时候也不用担心丢失已有DAPLINKV1/2/STLINKV2/2.1/JILINKOB/BMP等等所有出厂所带模式,直接从DIY模式切换回来就可以了。

开放支持 PIC/MSP430的烧写,因为Microchip/TI的条款限制比较严格,所以这类芯片的烧写,提供DIY上位机和固件源码示例,自己根据Datasheet折腾吧。
如果愿意分享,他人也可以使用该固件直接在DIY模式升级固件,这样全球每一个愿意DIY的人都可以人人为我,我为人人。

其他芯片的烧写也采用这种方式,提供开放的源码和上位机(如果有开源的上位机,就优先考虑已经存在上位机和通信协议)模板示例,自己去折腾吧。

通过以上方式,基本解决了开放协议的(Datasheet可以查询到烧写算法时序)芯片、模块等等设备的开发者自由DIY的困境。不用总是就为了偶尔烧写某一型号芯片就要去不停采购编程器,最后一堆,不用了就成了电子垃圾。

MCU采用的就是软件生态环境非常成熟的F103CBT6,开发起来资源很多,个人根据提供的开源框架,增加新芯片型号的支持并不困难。所以命名为无限的意思也就在于,一是自带功能非常强,再是用户可以DIY自己的调试器/编程器,即便最终不用了,您也可以写个固件让它闪个多彩的LED给孩子把玩(:-D),不会沦为电子垃圾。如果用户愿意开放自己DIY的源码,或者固件,其他人也可以受益。

最终产品还是采用经典款铝壳,没错就是这么小小的铝壳(个人非常喜欢这个花花绿绿的彩壳,铝壳生产时比塑壳要麻烦,要调垂直),做到功能“无限“”,而最终价格定令人难以拒绝。

#14 Re: 技术人生/软件使用技巧/破解经验/技术吐槽/灌水 » 各种国产32满天飞,ST还有中国市场吗? » 2023-02-28 10:13:29

如果这一波使用国产芯片的产品投放出去,没有出现什么大问题,得到大家认同,那ST就麻烦大了。不管怎样ST想继续稳坐钓鱼台,是很难了。毕竟RISCV蚕食的是整个ARM。如果厂商能基于开放的RISCV开发一些与人工智能相关的硬核IP,那ARM和ST的压力都不小,不过ST自己也完全可以搞RISCV。

#16 Re: Cortex M0/M3/M4/M7 » 有趣的F103家族新添"不限量税后5.8" AIR32F103 和 MH32F103A » 2023-02-06 10:42:49

@IOsetting
感谢分享,看了您的帖子,很有探索意义,这款芯片的应用空间越来越大了。刚刚看了您的链接好像是开源 gcc 平台,如果能有keil平台的示例就完美了,大家验证起来更方便。

#17 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-12-06 13:52:09

@iamseer
你说的是WCH的私有下载协议,这种通过串口或者USB的协议,无需使用下载器,只需要外挂一个小模块来控制上下电即可,用个单片机实现USB转虚拟串口,然后内部处理下串口数据,根据指令控制某个PIN的I/O口,根据功率需要用它对外控制一个MOS管,或者继电器。

#18 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-12-05 14:36:56

@iamseer
下载器没法知道上位机的下电指令,所以要重写上位机才行。或者通过抓包来获取,但是需求量很小,我这边下载WCH的片子也是自己写了个程序额外下电,然后间接控制沁恒的上位机。

#19 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-12-05 14:33:40

foric 说:

DAPLink支持M33内核的SWM34SVE芯片吗?

看了下M33的说明,支持JTAG和串行线调试端口,所以DAPLink是支持的。

#20 Re: Cortex M0/M3/M4/M7 » 小封装大容量Cortex-M芯片型号有哪些? » 2022-09-05 14:50:30

芯片厂商一般都会提供选型手册,直接搜索FLASH容量,几家的手册看一遍也就差不多了。

#21 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-08-27 14:58:16

@posystorage
他们家的模式还是很清晰的,低价圈市场,拿风投。人家目的真不是赚烧写器产品自身的钱,而是看市场占有率找风头估价,那个东西硬件我批量也是做不到9.9,更别说包邮。我疑惑的地方是敢于把固件上传到第三方的公司或者个人有几个?另外这个市场很窄。但也许真的是新的商业模式呢?乐见其成吧。

#22 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-08-27 14:33:02

wefinger 说:

@llinjupt
不知楼主的link是否已经量产发售,很感兴趣。

show.png

第一张图对应本帖子所说的多功能DAPLink。
第二张图是多模STLinkV2/2.1/DAPLink/BMP,模式自由切换,支持官方升级。
第三张图是CKLink+WCHLink,模式自由切换,支持官方升级。

感谢关注,目前只做国外市场和国内批量,上方是某客商定制的烧写器上附带的接线卡,因为左下角是客商LOGO,避免广告嫌疑,打了MARK。之所以目前不做国内零售市场基于以下原因考虑:
1.国内愿意为性能买单的开发者很少,除非是专门做电商,否则基本无利可图,研发费用都不够。
2.国内某电商也谈过,但是因为老款的库存较多,这一系列一推出,基本上原库存没法出,留一线,好相见。
3.国内主要针对批量客户,像公司团够,培训机构,学校社团,定制客户LOGO。
4.等原库存出差不多了,就交给国内电商推。我们这边还是只做好自己的事:设计,研发,测试和生产。

这个东西成本主要还是在研发和测试,测试还占了大头。不在众多环境中验证,个人DIY下,根本没法批量出货,就简单的比如串口通信,做过环流压力测试的都很少。我们这边的最终目标也不是做调试器,是为了下一阶段用于全自动化流水线上的PCB烧写,测试,验证的产品做铺路。

#23 Re: RISC-V » 避坑指南-国产wifi蓝牙芯片W800/W801/W806的GPIO速度很慢 » 2022-08-25 13:06:30

如果侧重点在性能,MCU拿回来就要直接寄存器方式验GPIO的Toggle速度,因为这个是对外的,大脑发达,四肢萎缩,对外性能发挥不出来,而且是硬伤,什么黑科技都很难提高。基本上标称大FLASH,高主频,大RAM,但是价格又偏低的片子,这个速度不会太高。问题是W801的价格也不低,看不懂。

#24 Re: Cortex M0/M3/M4/M7 » 有趣的F103家族新添"不限量税后5.8" AIR32F103 和 MH32F103A » 2022-08-20 20:09:19

profile 说:

这货连参考手册都没,外设和ST有差别,便宜也正常

主要是主频够高,简单用用趟一趟雷,再做深入应用。目前开发看还没有遇到很大的缺陷,都可以通过软件进行弥补;就怕市场起来了,直接涨价。现在MCU市场低迷,短期还不用担心。

#25 Re: Cortex M0/M3/M4/M7 » 有趣的F103家族新添"不限量税后5.8" AIR32F103 和 MH32F103A » 2022-07-27 11:10:16

AIR32F103CB/CCT6 降价到4.8/5,STM32价格还在15-30,看不懂!

#26 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-07-15 12:08:11

Gentlepig 说:
llinjupt 说:

@Gentlepig
看芯片的IDCODE 0x2BA01477,这个是ARM核心ID,芯片厂商改不了。

在合宙air32Q群里问过这事,他们给的回复是就是M3核,没有依据说明0x2BA01477就是M4,应该是较新版本的M3?

可以看下同规格MH32F103A宣传页,里面的BUG描述和移植手册一模一样。我是根据IDCODE和该芯片确定是M4的。不过合宙官方说是M3,也不用纠结。

#27 Re: Cortex M0/M3/M4/M7 » 有趣的F103家族新添"不限量税后5.8" AIR32F103 和 MH32F103A » 2022-07-14 17:25:48

Timaker 说:

用air32f103做了个stlink,还不错

stlinkv2吗?我试了下SWIM好像工作异常,有没有类似问题?

#28 Re: Cortex M0/M3/M4/M7 » 有趣的F103家族新添"不限量税后5.8" AIR32F103 和 MH32F103A » 2022-07-13 21:45:54

怎么说呢,多种选择,对于下游来说不是坏事。

这个片子尽管可以达到216MHz,在晶振电路上要小心处理,否则可能无法达到预期。手册非常简陋,只能参考STM32的,但是部分明显不同(否则倍频不肯能达到216MHz,有些外设的分频处理也要跟着动),例如RCC部分,有个air.lib是闭源的,涉及到RCC的配置。难道是怕其他厂商抄袭?

#29 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-07-12 11:44:40

Gentlepig 说:

合宙的air32f103cbt6开发板也是9.9元,出厂是daplink固件。
这个片子好像可以超到200M.

刚刚拿到的这个板子,内置的也是HID V1版本的DAPLink,有点失望,貌似直接拿的开源固件烧进去的。毕竟是主推开发板,用于方便调试。按照这个芯片的超频能力,理论上稍微优化就有不错的性能。

reset.jpg

#30 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-07-06 09:28:17

@Gentlepig
看芯片的IDCODE 0x2BA01477,这个是ARM核心ID,芯片厂商改不了。

#31 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-07-05 21:38:29

Gentlepig 说:

合宙的air32f103cbt6开发板也是9.9元,出厂是daplink固件。
这个片子好像可以超到200M.

是的,当初还发过1个帖子讨论这个5.8的裸片,M4的内核,文档中主频最高216MHz,实际测试可以超频到240MHz。

#32 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-07-05 16:56:01

后面陆续测试下当前市面上的各类DAPLINK。看看性能如何。

PWLINK2Lite,第一个选它,就是因为便宜,推广期9.9顺丰包邮,限购2个,GD32F303CCT6主控,买回来拆芯片也划算,还要什么自行车。

HID版本,所以基本上性能不会太高,事实也是如此,基本和STLinkV2的烧写速度一致。特地使用示波器看了下SWCLK,可以接近8MHz,相信如果采用V2版本,速度定能提升不少。
另外虚拟串口短接测试吞吐量,波特率230400时丢包,波特率再往上丢包严重,且和单次发送数据长度无关。难道基本功能未测试?

优点:硬件设计优良,内有热缩管保护套(实际上氧化铝本身就是高度绝缘的,可能是为了安装更牢固),发烧友上的 产品售价不及半颗芯片,老板是赚是亏? 对硬件有详细分析。
和其他产品不同,它的铝壳塑料件是定制款,比较紧实,看来老板是想做好产品的。
疑问:OB21的稳压管最高支持700mA的输出电流,而FS的USB最大只能输出500mA,采用这种设计的目的是为了冗余?

实际上笔者感兴趣的倒不是它的硬件,而是商业模式,敢在某个很窄领域运用互联网思维进行操作,定是艺高人胆大,期待后续发展。

#33 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-07-01 16:37:58

@上海航芯市场
这个邮费18高了点,个人建议推广期还是含邮30以内比较有优势。笔者的N合1版本指导价也不高,目前只对经销商,电商,外贸等批量客户进行OEM生产。

#34 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-07-01 16:18:32

速度比较一定要使用相同的目标MCU,相同的上位机,相同的SWCLK设置下,进行比较。同样是128KB,Cortex-M7的MCU写入速度要比Cortex-M3快很多。希望能在相互PK中不停推动开源DAPLink的发展.

最近宣称高速的DAPLink有不少,抽个时间挨个评比下。

笔者最后量产的是N合一的调试器,也即1个硬件直接在N个Link间切换模式,XXLINKv2/2.1/DAPLink/AVRISP/AVRMKII,希望能给大家带来一点惊喜,价格国内亲民,主打海外。

#35 Re: Cortex M0/M3/M4/M7 » 有趣的F103家族新添"不限量税后5.8" AIR32F103 和 MH32F103A » 2022-06-14 22:09:56

刚刚试了下,可以二进制兼容,奇怪的是GPIO配置模式的时候,会自动输出一个小段低电平脉冲,真是画蛇添足,还要深入探究。

#36 Re: Cortex M0/M3/M4/M7 » 有趣的F103家族新添"不限量税后5.8" AIR32F103 和 MH32F103A » 2022-06-12 10:21:36

david 说:

@llinjupt
413有二进制兼容么?

据我所知,不能。从多家宣传二进制兼容的型号实测看,没有一家是真正二进制兼容,毕竟用的不是ST的版图,而是寄存器模拟。如果轻易相信二进制兼容,批量将付出惨痛代价。比如有的RST必须要接,有的USB枚举需要特殊处理,有的ADC需要外围特殊电路,有的VBAT供电不行,这些还都是比较容易测试出来的,一切实测为准。

#37 Re: Cortex M0/M3/M4/M7 » 有趣的F103家族新添"不限量税后5.8" AIR32F103 和 MH32F103A » 2022-06-11 11:22:32

david 说:

At32的替代芯片是403A还是413

M4F AT32F413
Cortex®-M4F Core
200MHz CPU
256KB Flash, 64KB SRAM
2xADC, 2xCAN, USB

M4F AT32F403A
Cortex®-M4F Core
240MHz CPU
1024KB Flash, 224KB SRAM
2xCAN, 8xUART, USB, XMC

可以看AT家的选型手册,编号越小,功能越强,价格同理。

#38 Re: Cortex M0/M3/M4/M7 » 有趣的F103家族新添"不限量税后5.8" AIR32F103 和 MH32F103A » 2022-06-09 15:12:09

再补充一个FCM32F/H103,对应72/96MHz主频,也是Cortex-M4内核。看来国内厂商抄作业抄得很齐整=D。细心的可以看下其他资料较全厂商的文档,基本都是照着ST Datasheet 改了改,很多框图都是照抄,真有意思。

#39 Re: Cortex M0/M3/M4/M7 » 有趣的F103家族新添"不限量税后5.8" AIR32F103 和 MH32F103A » 2022-06-09 12:31:24

airpumpkin 说:
llinjupt 说:
Gentlepig 说:

可以直接烧录为stm32f103编写的程序吗?

内核使用的M4,肯定是不行的。另外M3主频也做不到这么高的。

M3是M4的子集,管脚和寄存器保持一致,应该是可以的,AT32就是这么干的。

样片已在路上,到手实测后再来给各位报告。

#40 Re: Cortex M0/M3/M4/M7 » 有趣的F103家族新添"不限量税后5.8" AIR32F103 和 MH32F103A » 2022-06-09 08:59:14

Gentlepig 说:

可以直接烧录为stm32f103编写的程序吗?

内核使用的M4,肯定是不行的。另外M3主频也做不到这么高的。

#41 Cortex M0/M3/M4/M7 » 有趣的F103家族新添"不限量税后5.8" AIR32F103 和 MH32F103A » 2022-06-08 22:16:51

llinjupt
回复: 59

AIR32F103 是主打LuatOS软件平台的上海合宙推出的,不限量税后5.8RMB。另有不知名公司推出的 MH32F103A,可以确定是同一芯片,采用CortexM4,主频216MHz,128KB FLASH,还有6.3RMB的256K CCT6可选。不只是谁为谁代工,不过这并不重要。自从STM32F103涨价以来,国产替代型号层出不穷,价格也开始回归,面对5.8RMB的税后价,各位大佬有何感想?

个人近半年多来也评估了十多种替代方案,因为核心相同,生产工艺相同,除了外设设计区别外,性能区别并不大,核心功能没有发现大问题,当然有大问题也不可能量产,有些也可能是同一厂商直接OEM的。不知道大家对税后5.8RMB的AIR32F103是持何种态度?

#42 Re: Cortex M0/M3/M4/M7 » 【重开旧坑】8051上的CMSIS-DAP调试器——TinyDAP开发过程记录 » 2022-06-08 10:05:43

大神回归,“建议在设备端对TMS和TDI等引脚上拉”,这个忘记是在ST还是ARM的文档中看到过,官方推荐设备端不要接任何上下拉电阻,而是由调试器端控制。遇到过有些开发板使用了太小阻值的上下拉电阻,而导致调试异常问题,主要是调试器一侧没有使用推挽方式,而导致驱动力不足。

期待楼主后序。

#43 Re: Cortex M0/M3/M4/M7 » 新坑神器-204MHz Cortex-M4内核国产芯Air105 » 2022-05-08 00:14:50

个人评估该芯片至少有几点需要注意:
1.裁切了一些标准M4的东西,RCC等初始化很简单,所以一些外设模块如果没有官方DEMO,很可能会踩坑
2.GPIO速度最高6.3MHz@204MHz,使用GPIO想做一些高效通信的情况需要斟酌(不过内核@204MHz编解码快了,可以弥补这一块)
3.没有HAL库,只有标准库
4.Keil下-Otime优化后不执行
5.功耗可能要实测看是否符合需求
6.文档未提及读保护,产品如何保护固件?

意外惊喜:FLASH写入速度很快。对于需要驱动屏幕挂字库应用是不错的选择。如果只是基于其OS平台编写Lua脚本应用足够应付。

#44 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-05-03 13:46:10

3. SWD速率

分析完入口,分析出口部分。在Keil上位机上设置调试器选项页有一个Max Clock参数,最大值为10MHz,它设置的就是SWCLK的频率,而不是SWD的通信速率。实际的通信速率要结合SWD的协议分析。这里不再单独贴图,可以结合metro的帖子。

静荷速率大约是 (8+32)/(8+5+32+1)≈87%,这样结合10MHz的计算,那么理想情况应该在 10MHz/8*0.87 = 1.1MB/s,这个数据是惊人的,也就是目标MCU可以提供的灌入/读取速度可以达到如此高的速度。实际上查看ARM官方的数据,其SWD模块可以最高支持到24MHz。STLINKV3就是使用的该频率,然而频率越高,噪声越大,抗干扰能力也越差,对外部排线长度和质量都有更高要求,反而得不偿失。

笔者第一次拿到某DAPLink的时候,尝试与STLINKV2比较,发现STLINKV2的SWCLK频率在4.xMHz,那么显然应该比STLINKV2要快,然而事实和预期恰恰相反,后来通过示波器查看波形才有了帖子开头上贴的那张图。如果使用那张图上的实际频率来计算,大约最高静荷速率为700K/8*.87=76.125KB/s。

即便是糟糕的76.125KB/s和STLINKv3的实测速率应该也不差,但是注意这里是双向的速率,毕竟SWD是半双工,收发交替进行,另外这里的静荷速率是指GPIO一刻不停地TOGGLE,事实上MCU解码/编码数据会占用大部分时间。此时整个波形平静如一,没有任何数据通信。

可以参考 Vllink Lite 作者 le062 的帖子 CMSIS-DAP兼容调试器,其中有相关的时序图。

结论:如果实际的SWCLK是10MHz,那么完全满足需求,因为单向就是 1.1MB/s / 2 =550KB/s,所以在GPIO出现瓶颈时,USB那边会首先成为瓶颈,问题是笔者测试的DAPLink的时钟为何如此之低,当看到 ARM 官方的源码时,这个结果在意料之中。

#45 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-05-03 12:40:35

2. USB通信速率
USB传输分为interrupt传输,bulk传输,iso传输。这里只讨论DAPLink2.0 bulk传输的通信速率。

尽管名义上FS速度为12Mbps,HS速度为480Mbps,这个是最终的物理层面的波形速率,也就是算上了所有控制字段,校验字段等。并且不考虑发送和接收端的等待时间,就像公路上排满了车,前后距离达到极限,每辆车都能以相同高速行驶,这样计算公路的运量显然是不合理的。但是最终有意义的数据是静荷,必须把那些控制字段去掉。USB是相对复杂的协议,采用计算的方式可能和实际测试结果相差甚远。实测才有真正意义。

USB2.0 5.11.3 有一个公式,其中有一个传输因子2.083,个人理解就是,理论速度/2.083就是实际设备可以达到的极限静荷速度。对于12Mbps的极限速度就是12M/8/2.083/8=720KB/s 。这样就有了一个参考,如果实际测试结果和该值相去甚远,那么应该考虑测试方法问题。

这里测试USB吞吐量时有几个注意点:
1.不要通过HUB,也不要使用虚拟机,这将大大影响性能
2.其他同一总线上的USB口也不要接入其他设备(同一总线上的USB速度是设备共享的)。
3.读写操作调用usb_write/read(这里上位机使用libusb-1.0)时一次发送/接收尽量大(MB)的数据,OS底层会自动处理。
4.下位机中不要做任何打印,复制,统计等处理操作,直接ACK
5.下位机编译都应打开-O3和-Otime或-Ofast,并且开启I/Dcache(如果有)

这样就可以得到USB在特定MCU上读和写的实际速度。笔者测试的单向写的数据如下:

len:64 clk ms: 3302, 520.993347 KBytes/s
len:64 clk ms: 3306, 520.982483 KBytes/s
len:64 clk ms: 3309, 521.129028 KBytes/s
len:64 clk ms: 3312, 521.275391 KBytes/s

双向速率如下:
len:64 ms: 1382, 380.109985 KBytes/s
len:64 ms: 1728, 379.851837 KBytes/s
len:64 ms: 2076, 379.314056 KBytes/s
len:64 ms: 2433, 377.528992 KBytes/s
len:64 ms: 2779, 377.689819 KBytes/s
len:64 ms: 3127, 377.573395 KBytes/s

实际上后来测试数据还有提升,因为没有记录结果,这里只是作为参考,这样就得到了USB的实际理想速度。但是由于DAPLink采用Ping-pong方式,那么就要根据实际的情况来模拟这种行为,也就是发64,收64字节,看看吞吐量如何。

作为目标速度PK的参照,ST-LINKV3的实际烧写速度也只有90KB/s左右,换算成双向,也只有180KB/s。MCU处理USB均是使用DMA方式,MCU自身并不需要消耗太多CLK来处理USB通信,结论是通信瓶颈不在USB上。在这里优化就像使用更粗的水管替换已经够粗的水管,效果很差。

#46 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-05-03 11:42:18

1.优化思路概述

整体上描述下优化思路。这里将数据流和水流做比,那么数据在不同设备间的传输(搬移)就像水流通过一段一段串联起来的水管。很明显,水流从源头到目的地的最大流速由这些串联起来的水管中最细的一根决定,如果想要增大流量,最直接的办法就是换掉这根最细的水管。但是数据通信中的环节瓶颈通常不是那么显然的。

DAPLink 整个通信流程大体分为以下几个步骤。

       (USB)                     
PC<------------>MCU(缓存)<--------->MCU(解码)<------->SWD/JTAG(时序)<------->目标 MCU

要知道通信瓶颈,最好的办法就是针对每一部分进行单独测试,找出问题的根因,对症下药,这样就不会无的放矢,效果不明显。下面尝试解释USB HS为何不能大幅提升烧写速度(和优化过的ELF DAPLink FS相对比,而不是和没有优化过的开源方案相比)。

#47 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-05-03 11:29:37

宁. 说:

@llinjupt
楼主,最新这个用的什么主控呀?目前进度怎么样了?想复刻一个。
开源的话 能现在就把代码扔到gitee或者github吗?迫不及待了=D

开始使用的是C51方案,进行功能验证和性能评测,不过51的FLASH通常比较小,想做比较多的功能可能不够,最后使用RISIC-V方案量产,目前已进入最终产品线,所以暂不方便全面开源,不过解决方案帖子里都已经阐述,只是需要根据硬件平台适配调整。整个优化过程会详述,希望对他人有参考意义。

#48 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-04-16 16:12:30

ELF/ELF+

物流耽搁了半个月,拿到PCB开焊。
目前支持功能根据目标芯片分四种:

1)ARM-CortexM0/0+/M3/4/7 全系列:

CMSIS-DAP v1/v2 SWD/JTAG  软复位,SWD性能目前测试Keil下不输StlinkV3。(保留V1是因为苹果机对V2支持不好)
STLinkV2 SWD/JTAG/SWO      支持Cube升级固件,支持串口(目前没有看到能在STLinkV2支持STM8且支持虚拟串口的固件)
目前最普遍流行的铝管版,均不支持SWO和JTAG,也没有虚拟串口。

2) STM8 只要是STLinkV2支持的型号全支持

3) STC 支持全系列免冷启动下载

4) AVR全系列下载
经典协议: ICSP
最新协议: UPDI (Microchip收购后的单线下载调试协议)
其他协议:PDI/TPI

至于一些小功能:救砖时钟,MCU RC校准,只要目前标准开放的功能全支持,不再罗列。

支持Arduino IDE 和 AtmelStudio (AVRStudio)。对于DIY完全够用了。性能优化部分再跟帖详述。

#49 Re: ST/STM8/STM8S/STM8L » 谁能拒绝在自己的项目中添加终端工具用于调试呢? » 2022-04-03 23:48:23

真的是很烦 说:

有个 clish   , 还有个 klish
操作起来风格更交换机的cli很类似,  有自动不全,有帮助提示

对,就是这个,这个移植到单片机上面工作量还不小,但是功能很强,该有的都有,操作起来也很顺手。如果能用JSON格式替代掉繁琐的XML就更好了。

#50 Re: ST/STM8/STM8S/STM8L » 谁能拒绝在自己的项目中添加终端工具用于调试呢? » 2022-04-02 19:29:59

hox 说:

这玩意我也写过一套,汗;
另外,GITHUB 上这兄弟也写了一套,感兴趣的可以看看,
https://github.com/NevermindZZT/letter-shell

这种CLI以前在交换机上很多,后来都被GUI替代了,以前的嵌入式开发者对这类应用很熟悉,后来基本被Shell取代,大约十几二十几年前,CISCO,LINKSYS的gateway上都是这种,看起来很神秘高科技的东西,一个时代的渐行渐远。

那时候的CLI可以做得很炫,有些还带动画,ASCII码图,多种颜色,看了 letter-shell 好像也不支持对参数的帮助,只提示命令的 desc帮助。

ping [A.B.C.D/URL] 会提示单个参数的格式等等,记不太清楚了,很有趣的应用,所以想写一套针对单片机的寄存器任意位操作的CLI,并给出位段的功能提示,相当于一套内嵌的实时的datasheet,这样对于diy来说,可以在最底层验证寄存器的功能,可惜一直没空弄。

#51 Re: ST/STM8/STM8S/STM8L » 谁能拒绝在自己的项目中添加终端工具用于调试呢? » 2022-04-02 10:36:33

点赞。刚刚试了下,1.不能tab补全,2.退格处理也有问题 3.不能打印对参数的帮助,如果能对寄存器进行操作,并打印寄存器各字段的帮助信息就更棒了。一直都在想做一套类似的东西,这个就可以对任意寄存器进行设置了。但是要移植一套CLI,参考的是Linux平台程序,但是工作量不小,一直搁置,如果上面的功能完善了,基本就和自己当初设想的一致了。

#52 Re: Cortex M0/M3/M4/M7 » 有没有大神用过CH32V103/20x/30x系列的片子 » 2022-04-01 15:11:07

@海石生风

可能您不明白我说的意思,如果您使用专业工具验证过,并经常关注专业分析报告,您就不会下此定论了,很多国内芯片都是分钟级读取固件,连物理入侵都不用,破解已经是一部分人“正经”生意。硬件设计的漏洞数不胜数,只不过关注这方面的人比较小众。

像低功耗功耗这一块也不行,极端环境的稳定性如何?从90%到追齐到100%,这最后的10%所要付出的努力比前面90%所付出的不会少太多。

#53 Re: Cortex M0/M3/M4/M7 » 有没有大神用过CH32V103/20x/30x系列的片子 » 2022-03-31 18:48:03

echo 说:

CH573不如选CH571F,不到3块钱,带USB,18kB SRAM+192kB FLASH,性价比爆炸。正点原子那个烙铁都用CH571F了。

嗯,这个系列根据需要都可以考虑。

现在国产MCU在很多方面都设计得很人性化了,工程师可以少很多麻烦,比如USB的防反射电阻,内置LDO等等,原来很多在国外高一级系列的片子上有的功能,也被集成进来,例如SPI支持任意bit(<=32bit)长度。只要再过几年,稳定性,安全性能够和国外持平就更幸福了。

#54 Re: Cortex M0/M3/M4/M7 » 有没有大神用过CH32V103/20x/30x系列的片子 » 2022-03-31 12:06:47

Gentlepig 说:

air105这个和stm32f03开发区别大吗?没看过air105的库呢。
没usb和can是挺可惜的。还有qfn手工焊接有点难度。
-------------------------
额,是有usb的。

QFN要多焊几次,找找手感,另外推荐用热风枪+BGA助焊剂+锡膏(劣质的锡膏和助焊剂就不要考虑了,完全是浪费时间),
其他方式个人经验,手工各种问题,良率很低。

QFN的最大问题是焊接后无法直接通过万用表测试引脚通断,只能测试相邻脚是否短路,这对于普通爱好者
可是头大的很,个人用的是JTAG 边界扫描方式测试通断,不过没有JTAG口的片子就不行了,通常对于PIN脚较多芯片都会提供JTAG接口。
这对于BGA封装的片子同样适用。

#55 Re: Cortex M0/M3/M4/M7 » 有没有大神用过CH32V103/20x/30x系列的片子 » 2022-03-29 11:38:48

事实证明一分钱一分货。CH573的性能不给力,配了个内置的SPI FLASH,代码只能在RAM中才能达到相应主频的性能,但是RAM只有18KB,需要一定的技巧。另外GPIO切换只支持bit clear,不支持bit set,有意为之?果断拿出吃灰中的AIR105,FLASH 4M+640K SRAM,204MHz的CortexM4核,使用C+ASM开发,真是信马由缰,自由奔腾。2/30x系列外设有所不同,High USB+CAN, AIR105没有,PK下性能会如何? 真是一个困难选择症状的美好时代。

简单总结:
CH573=>性能不要太强的需求,但是要大FLASH的应用
AIR105 => 性能+FLASH+RAM平衡需求,QFN
CH3XX => HighSpeed USB+CAN

#56 Re: 8051/STC8/AT89C51/N76E003 » 针对51的代码压缩方法,榨取FLASH空间浅谈 » 2022-03-21 14:00:56

参看第9条 tongue

再补充一条,不过这种都是小打小敲了,例如有的表数据类型是四字节的,但是数值都是某个值的整倍数,此时可以压缩成双字节或者单字节,用的时候乘回来就行,这种优化都是针对特定应用,基本还是能用单字节,不用双字节这个原则。

最好一开始选型的时候就足够大,一劳永逸。

#57 Re: 8051/STC8/AT89C51/N76E003 » 针对51的代码压缩方法,榨取FLASH空间浅谈 » 2022-03-21 13:44:17

posystorage 说:

crc表 查表法用const固化在flash就行了吧 没必要拷贝到ram?

如果访问FLASH的速度和XRAM的速度一致或者对性能不敏感,确实如此,需测试验证。

#58 8051/STC8/AT89C51/N76E003 » 针对51的代码压缩方法,榨取FLASH空间浅谈 » 2022-03-20 13:03:05

llinjupt
回复: 6

这几天遭遇了头疼的事,就是功能增加太多,每个子功能调通后,开心地合并代码时傻眼了,代码超出了大约8KB,
这可不是超过一星半点,并且写程序的时候也已经相当注意数据类型的使用,所以到底能不能搞定,还真是头疼,
经过几天的“奋斗”,终于塞进去了。

把相关方法总结下,方便他人参考,也算抛砖引玉。

通常代码大小和代码速度存在矛盾,为了兼顾速度,而同时保持代码较小的目标,可以从以下方面考虑:

1.优先使用单字节类型
双字节和四字节大大增加处理代码,如果可以转化为单字节类型可以明显减小代码。这对于51单片机绝对是优化利器。如果想深入了解为什么,可以对比生成的汇编代码。
1.1 变量优先使用单字节
1.2 返回值优先使用单字节
1.3 如果bit类型够用,那么优先使用bit

2. 宏定义转为函数
宏定义存在多分拷贝,如果宏比较大,而又不是用在关键路径上,可以转换为函数。此法效果明显,但是要注意不能是性能关键路径。

3.优先使用data类型
data存储类型处理时对应的指令代码要比xdata和code的类型小得多。指针同样适用,优先使用特殊指针,而不是通用指针。

4. 查表法使用的表数据使用算法初始化
查表法可以大大提高程序执行效率,但与此同时将大大增加FLASH占用,那么可以在程序启动的时候初始化该表,这样RAM占用不变,FLASH只占用初始化的算法,而且不影响程序性能。

因为程序中有3比较大的表,两个CRC表,奇偶校验表,一下子解决2K空间,此法优化神速,但是对于没有采用查表法的程序基本无用。

5.打印字符串使用错误码
如果整个系统错误码不超过256个,那么一个错误码只需要占用1个字节,但是一行打印却要占用数十个字节,所以在调试时可以使用错误码转换函数,当正式版时不要编译该转换函数和错误字符表,而只打印错误码。这样可以通过源码的错误表,来解读错误信息。1个中型项目大约可以解决数K甚至数十K的FLASH空间。

不同的子系统也可以定义独立的错误码,那么基本可以保证使用单字节就可以完成整个系统的错误码定义了。

7. 如果不在意性能,那么使用size优先编译选项,通常可以压缩个好几K

8.超级武器
汇编

9.终极武器
$,$$,$$$,当然还有您的卓见。欢迎分享优化大法。

#59 Re: Cortex M0/M3/M4/M7 » 有没有大神用过CH32V103/20x/30x系列的片子 » 2022-03-20 10:57:15

echo 说:

用过CH32V103C8T6,感觉还可以,就是没有CH571F便宜

刚刚看了下 CH571F/3F 系列,这个FLASH够大,不知道他们的定价策略,CH32V103系列只有64KB,但是价格比57x系列高,难道只是因为QFN封装。
上次买样片时附带了几片573F,扔在一边吃灰,正好可以折腾折腾。

#60 Re: Cortex M0/M3/M4/M7 » 有没有大神用过CH32V103/20x/30x系列的片子 » 2022-03-15 16:46:30

是的,另外由于RISCV带有BCR/BSHR寄存器,GPIO的切换速度可以做到比ARM快一倍。ARM只能先读,修改,再写,否则同一端口的其他PIN的状态无法保证。

目前看有个缺点就是代码密度低,同样的程序编译出来比ARM的大不少,这一点代码量比较大的时候要考虑。
另外测试发现静态功耗要比ARM的高30-40%,不过只要不是电池供电的设备不用太担心。

好在价便宜,希望能保持一段时间,让采购订几包趟趟雷。

#61 Cortex M0/M3/M4/M7 » 有没有大神用过CH32V103/20x/30x系列的片子 » 2022-03-14 12:35:40

llinjupt
回复: 16

有没有大神用过CH32V103/20x/30x系列的片子,这段时间做了初步评估,
从性能上看,完全不输对应的ARM系列,不知道有没有大神批量使用过,有没有暗坑?
感谢。

#62 Re: 8051/STC8/AT89C51/N76E003 » 51单片机的一个多线程编程模型 » 2022-03-09 13:37:25

感谢作者分享,但是感觉示例给的有问题,delay_ms 中没有进行任何调度,如果一个线程中 delay_ms(1000),另一个 线程中 delay_ms(100),个人分析两个LED只能以1.1s左右闪烁,而不是一个1s,另一个0.1s闪烁。

这个库很小巧,但是不能在线程中使用死循环方式进行延时。

#63 Re: 8051/STC8/AT89C51/N76E003 » Arch Linux 下给 STC-ISP 打 wine 包 » 2022-02-18 16:06:07

开源的 stcgal 应该也可以写这些字段的,有兴趣可以了解下。

#64 Re: Cortex M0/M3/M4/M7 » 说说航顺的M0--优秀的国产替代 » 2022-02-18 11:41:01

rainman 说:

那些国产山寨ST的MCU 多多少少都会有些问题。

实际上说所谓兼容,都是有限兼容,不可能做到完全兼容,除非拿到ST的版图,不过就算拿到,也不会有人冒着这个风险去生产,
否则只要开盖就能被原厂发现,那是卖多少赔多少,人还得进去。另外ST对各大厂商的仿制芯片,也是睁只眼闭只眼,毕竟现在主推G系列了。

实际上如果是自有源码的软件,根本不需要非采用这个型号,其他类型的片子功能已经做得相当强大,移植起来也不会有太大困难。只是国内替代芯片因为没有经过长时间的实际应用,在某些细节方面多多少少有些问题,不过这个过程过个三五年会有很大改善。目前最大的问题是国内有些厂商对问题遮遮掩掩,只有碰到了才会定向提供解决方案,这无疑给大家增加了很多试错成本,实际上产品的成熟单靠MCU厂商自身的有限测试是不足的。举这个例子,国内大部分的替代MCU多少都有安全隐患,大部分系列的固件可以在很短时间(分钟级)破解出来,安全这些部分还需要很大加强。

#65 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-02-18 11:30:58

taotieren 说:

会支持 rs-flash 吗?

不知您说的是不是 probe-rs,如果是的话,支持,因为本身它就是使用rust语言写的openocd,只不过功能上有所区别。
只要是兼容CMSIS-DAP标准协议的DAPLink,该工具都是可以支持的。

#66 Re: Cortex M0/M3/M4/M7 » 自己做的一个STM32开发板 » 2022-02-08 18:51:45

赞,也凑热闹晒晒手头的开发板,一路从购买,到设计打板,最后还是发现裸片香 tongue ,主要是做评估省时省力,观察信号方便,外设可随意替换,各种参数随便调,最大自由度折腾。这种方式对MCU适用,不太适用外挂RAM的片子。

FluxBB bbcode 测试

#67 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-02-07 22:57:56

avr

新年新消息,原本打算过段时间,有大突破了再更,先来张图吧,支持ARMCortexM/STC/AVRISP 的 DAPLink 出炉,外加支持 STLinkv2/STM8 的板子还在路上。AVRISP 协议版本太多,目前为了方便使用 ArduinoIDE,移植的是ArduinoISP(也即STK500v1,ATMEL Studio可以通过扩展工具支持),不过要支持更高速的MKII方案(ATMEL Studio 直接支持,这样就为后序继续集成PIC MCU的烧写铺平了道路),移植还需时日!

#68 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-02-07 22:33:10

posystorage 说:

欢迎探讨
开源CH551/2实现的汇编优化高速DAP-Link (CMSIS-DAP v2)
https://whycan.com/t_7786.html

首先支持开源,不过个人觉得高速DAP-Link说法欠妥,因为ARM官方的DAPLink v2版本也没有冠以HS的说法,况且真正可以算 “高速”的 STLINKv3 也没有提 HS。从CH552的工作频率上看,下载速度在目标芯片未形成瓶颈时,不会超过 STLinkV2(4.4MHz),优点在于CH552价格便宜,当板载的MCU FLASH不是很大时,用于板载还是划算的。

#69 Re: Cortex M0/M3/M4/M7 » 开源CH551/2实现的汇编优化高速DAP-Link (CMSIS-DAP v2) » 2022-02-07 22:13:43

支持,CH552用于做板载调试器成本低,DAPLink的JTAG调试FPGA?这个需要上位机支持吧,还是说自己在调试器中实现FPGA的一套JTAG协议?

#70 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-01-26 11:48:06

手头正好有类似的片子,测试结果:

正在检测目标单片机 ... 
  单片机型号: STC8A8K64D4
  固件版本号: 7.4.2U

当前芯片的硬件选项为:
  . 系统ISP工作频率: 24.074MHz
  . 内部IRC振荡器的频率: 11.064MHz
  . 掉电唤醒定时器的频率: 34.675KHz
  . 振荡器放大增益使能
  . P3.2和P3.3与下次下载无关
  . 上电复位时增加额外的复位延时
  . 复位引脚用作普通I/O口
  . 检测到低压时复位
  . 低压检测门槛电压 : 2.00 V
  . 上电复位时,硬件不启动内部看门狗
  . 上电自动启动内部看门狗时的预分频数为 : 256
  . 空闲状态时看门狗定时器停止计数
  . 启动看门狗后,软件可以修改分频数,但不能关闭看门狗
  . 下次下载用户程序时,将用户EEPROM区一并擦除
  . 下次下载用户程序时,没有相关的端口控制485
  . 下次下载时不需要校验下载口令
  . 内部参考电压: 1188 mV (参考范围: 1100~1300mV)
  . 内部安排测试时间: 2021年11月1日

  单片机型号: STC8A8K64D4
  固件版本号: 7.4.2U

开始调节频率 ...			[0.922"]
调节后的频率: 11.064MHz (0.043%)

正在重新握手 ... 成功			[0.141"]
当前的波特率: 115200
正在擦除目标区域 ... 完成 !		[0.657"]
芯片出厂序列号 : F7F4C63909E07A
正在下载用户代码 ... 完成 !		[0.031"]
正在设置硬件选项 ... 完成 !		[0.015"]

更新后的硬件选项为:
  . 系统ISP工作频率: 24.074MHz
  . 内部IRC振荡器的频率: 11.064MHz
  . 掉电唤醒定时器的频率: 34.675KHz
  . 振荡器放大增益使能
  . P3.2和P3.3与下次下载无关
  . 上电复位时增加额外的复位延时
  . 复位引脚用作普通I/O口
  . 检测到低压时复位
  . 低压检测门槛电压 : 2.00 V
  . 上电复位时,硬件不启动内部看门狗
  . 上电自动启动内部看门狗时的预分频数为 : 256
  . 空闲状态时看门狗定时器停止计数
  . 启动看门狗后,软件可以修改分频数,但不能关闭看门狗
  . 下次下载用户程序时,将用户EEPROM区一并擦除
  . 下次下载用户程序时,没有相关的端口控制485
  . 下次下载时不需要校验下载口令
  . 内部参考电压: 1188 mV (参考范围: 1100~1300mV)
  . 内部安排测试时间: 2021年11月1日
芯片出厂序列号 : F7F4C63909E07A

  单片机型号: STC8A8K64D4
  固件版本号: 7.4.2U

  . 用户设定频率: 11.059MHz
  . 调节后的频率: 11.064MHz
  . 频率调节误差: 0.043%


操作成功 !(2022-01-26 11:46:09)

建议对照官方文档中的下载电路,在TX上反串二极管再测试,很可能是电流通过TX灌入导致的。

#71 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-01-25 14:43:45

实际上 STC-ISP 支持 CDC 还有更大的问题, 也即序号只能到 255,实在是很扯的一件事,所有其他串口终端程序都可以直接列出来可用的串口,唯独它枚举出来所有的COM0-255,找要找半天,而CDC序号是没有限制的,完全可以超过255,此时STC-ISP扫描串口的时候,就死在那了,然后重启程序直接死掉。

不过普通用户倒是不用担心,因为平时不会在一台电脑插入如此多的CDC设备,所以通常不会遇到这类问题。而我因为测试的原因,会插入很多不同序号的CDC设备,每次端口会被预留,这样很快就超过255了。该问题已反馈给STC,看他们怎么解决吧。

#72 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-01-25 14:08:49

@ifree64

你说的现象很奇怪,因为手动操作上下电就和DTS没有关系了,我没有出现这样操作下载不成功的情况,
不知道你的目标MCU是什么型号?老型号只支持到9600波特率,并确保输出的波特率和设置的是一致的,有些CDC做得不好,实际并没有配置正确的波特率,
可以使用逻辑分析仪抓取 RX/TX信号,看看波特率是否正确,并确认目标MCU有回应。

#73 Re: Cortex M0/M3/M4/M7 » 同样是HAL库,为什么H7系列的编译这么的慢,而F1F4编译的很快 » 2022-01-24 22:03:39

试试把编译器改为 Version6,早用早受益!Version6 采用了并行加速,速度提升不在一个数量级。

#74 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-01-24 11:14:55

@ifree64

PC 到串口的流程:

PC上位机 --------- USB 驱动  ---- USB EPs ----- TX/RX ----- 目标 MCU

VCP 和 CDC 的区别就只在于 PC 上位机使用的驱动不同,其他没有区别,所以基本和 CDC 没有关系,注意 CDC 没有准确(或者说是很多上位机没有完全遵守CDC的规范下发 DTS 命令)提供 DTS 功能,STC下载的关键点是进入冷启动,所以要模拟 DTS 信号,然后让芯片彻底进入冷启动状态。

实际上STC完全可以做到非冷启动下载,可能是为了兼容以前的产品,原厂才一直保持这种很诡异的下载方式。

#75 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-01-22 00:08:43

ifree64 说:

强帖,串口CDC在win10以上系统是不是不用装驱动?我在arm windows虚拟机里没有ch340的驱动,没有串口用,重金买回来的m1 macbook成了摆设。

WIN10 上集成了很多通用的 USB 驱动,例如 CDC 和 WINUSB,所以这类设备均无需安装驱动,对于 WINUSB 设备需要在 USB 描述符中提供 GUID 字段,系统会自动匹配驱动。

据我所知,CH340应该不是 CDC,而是类似CP2102的 VCP,需要安装厂商的私有驱动才能工作。
在虚拟机中使用USB设备,速度会大受影响,少量数据通信可以,不能用于测试评估用。

MacOS好像不支持 CDC 类设备,这和 Linux 不同,Linux 天生支持的很好。

#76 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-01-14 13:23:47

最近要做的工作好多,但是楼主绝不弃楼,先上图:

ELF家族

前段时间突发奇想,是否可以做到让 DAPLink 完全兼容 STLinkV2,毕竟有些时候需要开发STM8,那么就需要 SWIM,
另外一点就是支持最新的 STM32CubeProgrammer 升级. 现在在软件和硬件上已经得到了初步验证。

现在忙于规模稳定性测试,文档书写,备料,外加继续新增 AVR ISP 支持,感兴趣的可以参考开源项目 LUFA,速度比普通 USBAsp 不在一个级别,
并且完全支持官方最新开发环境 ATMEL Studio 7。AVR在国内 DIY 中不像 ST和STC流行,但是在国外用户众多,所以打算加进来, 这样就不需要一堆下载器了。不过要进行完全移植还需要时间。

等折腾完了,将部分功能源码开放,并把整个优化思路贴出来。

#77 Re: Cortex M0/M3/M4/M7 » DAPLink添加WINUSB支持。。 » 2022-01-13 21:35:15

楼主功德无量,DAPLink 上面可以做的文章很多,由于它支持自由扩充命令,可以做出来很多好玩的东西,例如 ATMEL EDBG 就是基于DAPLink 的。

#78 Re: Cortex M0/M3/M4/M7 » DAPLink添加软件复位功能。。 » 2021-12-26 16:09:01

XIVN1987 说:
llinjupt 说:

不知道楼主有没有测试过一些国产芯片,例如GD,APM,这种方式不起作用?

没测试,,

如果 SCB->AIRCR 不能复位它们,,那要怎样软件复位??写它们自己定义的外设寄存器吗?

按理说这个功能上ARM CortexM架构自带的功能,但是我这边验证对某些国产MCU不起作用,估计只能找这些MCU原厂解决了。

#79 Re: Cortex M0/M3/M4/M7 » DAPLink添加软件复位功能。。 » 2021-12-26 10:18:44

不知道楼主有没有测试过一些国产芯片,例如GD,APM,这种方式不起作用?

#80 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2021-12-23 15:09:55

echo 说:

用相同的序列号,其实是为了换设备或者换USB接口的时候不重新装驱动,大多数时候一台PC只带一个调试器,重新装驱动很烦的。

WIN7需要装驱动,并且只需要装一次。WIN10自带驱动,无需安装,第一次插上设备后就自动匹配驱动,几秒s就可以使用了。序列号本身的用途就是用于唯一区分设备的。

ARM 关于DAPLink的USB设备配置有如下描述:
https://www.keil.com/pack/doc/CMSIS_Dev/DAP/html/group__DAP__ConfigUSB__gr.html

Update String Settings - Product String to indicate the Debug Unit. Note that "CMSIS-DAP" must be part of that string to allow identification by debuggers (or part of interface string for USB composite device).
设备的产品描述符中或者IF描述符中必须包含 CMSIS-DAP字符串。

Optionally each Debug Unit may provide a unique Serial Number String. If the String Settings - Serial Number String is not provided, only one Debug Unit can be connected at the same time to a host computer since it is impossible to identify multiple Debug Units.
每一设备可以提供唯一的序列号,否则同时只能接入一个调试器,因为无法区分多个调试器。

#81 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2021-12-23 15:07:22

@iamseer

感谢提供的测试思路,简单测试了下:

F:\DOSUN\Openocd\openocd-win64\release\openocd-w64-new>pyocd flash -t STM32H743VITX STM32H743.bin -f 10m
0002279:INFO:load_cmd:Loading F:\DOSUN\Openocd\openocd-win64\release\openocd-w64-new\STM32H743.bin
[==================================================] 100%
0023668:INFO:loader:Erased 1048576 bytes (8 sectors), programmed 1048576 bytes (1024 pages), skipped 0 bytes (0 pages) at 47.93 kB/s

F:\DOSUN\Openocd\openocd-win64\release\openocd-w64-new>pyocd flash -t STM32H743VITX STM32H743.bin -f 24M
0002218:INFO:load_cmd:Loading F:\DOSUN\Openocd\openocd-win64\release\openocd-w64-new\STM32H743.bin
[==================================================] 100%
0031080:INFO:loader:Erased 1048576 bytes (8 sectors), programmed 1048576 bytes (1024 pages), skipped 0 bytes (0 pages) at 35.51 kB/s

该速度是包含擦除烧写和校验的,所以要比OpenOCD的要慢,可以将烧写时间和Keil对比,但是结果明显不对,后来用示波器测试发现STLinkV3工作在4.8MHz,也即-f参数对STLinkV3不起作用,已提交给社区,等解决后再比对。

ISSUE: https://github.com/pyocd/pyOCD/issues/1276

#82 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2021-12-23 13:48:54

4.3    STLinkV3可能不兼容他家MCU
参考 https://pyocd.io/docs/debug_probes.html

Recent STLink firmware versions will only allow access to STM32 targets. If you are using a target from a silicon vendor other than ST Micro, please use a different debug probe.

意为最新的STLink对目标MCU进行了限制,猜测是内置了ID寄存器,用于辨识是否为原厂。笔者进行了部分验证,使用两款国产替代IC,测试发现STLinkV3确实不能发现,更不用说烧写和调试了。与此同时,STLinkV2没有此问题,也许以后升级也可能会被限,所以不要随便升级。感兴趣的小伙伴可以测试更多的非ST原厂MCU,看看是否完全不能使用。

不知道ST原厂为何会做这种限制,实际上这样做根本无法阻止替代,反而给人以作茧自缚的感觉,也难怪STLinkV3不像V2那么被大众接受了,价格是一个原因,更大的原因应该是从开放走向了封闭。

不过如果属实,从另一面考虑,倒可以使用STLinkV3鉴别IC是否为原厂,成为一个FAKE芯片的识别工具。

#83 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2021-12-22 21:06:55

4    性能对比
4.1    测试环境和方法
这里性能主要对标的是ST原厂的STLinkV2和STLinkV3MINI,STLinkV3MINI功能上比STLinkV3有所简化,但是SWD协议性能上是一致的,SWD的实际工作主频可达24MHz。

测试环境:
PC WIN10 64bit
Keil uVision 5.29.0
OpenOCD 0.11.0-rc2+

注意不要使用虚拟机测试,也不要将调试器通过USB HUB连接到测试主机。

调试器均升级到较新固件本版,并选择最高支持的SWD工作频率,这里需要注意只有Selected后面显示的频率才是实际的工作频率。而DAPLink没有该项,所以DAPLink的工作频率只能靠示波器来查看。

STLinkV2 V2J37S7 4MHz
STLinkV2 配置

STLinkV3MINI V3J9M3 24MHz
STLinkV3 配置 

ELF DAPLink V2 10MHz

Keil性能测试方法,由于Keil无法单独打印烧写速度,只能通过统计时间来预估,这里通过在上一次烧写完毕后直接按F8进行下一次烧写,然后统计时间间隔。该时间是包含擦除,烧写和校验的,如下图打钩Verify。所有被烧写的程序都使用接近FLASH大小的bin文件,也即64KB的FLASH使用接近64KB的bin文件。

使能校验

上一次下载即将结束时按住(尽量减小两次下载的间隔)F8键立即进行下一次下载,统计时间间隔48-38=10s,然后取三次间隔的均值:
间隔

目标芯片的IDCODE查看方法,因为某些丝印为STM32的芯片使用的是国产打磨后重印的芯片,所以这里给出测试芯片的IDCODE,以防遇到这类情况。通常情况下厂商间的IDCODE是不同的。
idcode

4.2    测试结果

result
(0)    OpenOCD 烧写SAMD21脚本报错,待解决
(1)    无法发现目标MCU,尝试降频同样失败
(2)    W表示写入速度,V表示验证速度
(3)    尽管设置了最大频率24MHz,但是OpenOCD进行了降频使用

需要说明的是以上数据均是多次测试的结果,对于明显违背于知觉的测试数据,使用另一台PC进行了交叉验证,可以保证以上数据的客观,可重现,具有代表性。这里对测试结果进行简单的分析归纳。

这一组数据是很有趣的,有些还出乎笔者意料,看起来有很多矛盾的地方。例如DAPLink在Keil上的表现要远远好于OpenOCD,经分析OpenOCD的源码,它没有针对DAPLink的缓冲队列进行优化,而Keil的驱动层明显是使用该优化的(通过USB抓包可以看到在烧写时,每次发送DAP_PACKET_COUNT个请求)。而OpenOCD每次只发送一个请求然后等待响应。

在某些芯片上,比如M3/4系列上,ELF DAPLink可以微弱反超STLinkV3。在高性能MCU上,ELF DAPLink和STLinkV3在Keil上都达到了烧写算法的上限,但是在OpenOCD上,明显STLinkV3更优,ELFLink大约慢了20%,OpenOCD上位机针对DAPLink还有很大的优化空间(为什么这么说,因为Verify的速度是一致的,速度瓶颈并不在DAPLink这边)。

在内置较小FLASH的MCU上性能对比不明显,因为烧写前的准备工作所下发的命令数是相同的,比如设置SWCLK的频率,初始化GPIO端口,LED状态设置,这样速率平均下来就变慢了。就像车子只行驶几米的速度也要算上启动时间一样。

不过发现STLinkV3M在使用24MHz工作情况下,不太稳定,因为V3 MINI是高度集成的,而MCU的主频很高,与此同时SWCLK工作在基本达到调试接口可以支持的最大24MHz,EMI干扰较大(可以观察波形,明显劣化),连接目标板时,调试线要尽量短,并且地线要紧靠目标MCU的GND,否则很容易报错,其他网友也有此反馈,应该不是个例。

SAMD21G18A这颗MCU,STLinkV3M完全发现不了,很是奇怪。有带该MCU的开发板的小伙伴,并且手头有STLinkV3的可以帮助验证下。

这里提出一些看似反常的问题,后面会尝试详细分析为何会有这样的对比结果。STLinkV3M相对于STLinkV2的最高4MHz工作频率,性能有大幅提升,但是相对于它的硬件配置,似乎并没有完全发挥出来:
1.STLinkV3是USB High Speed,也即USB可以达到480Mbps的通信速率,为何烧写速度对比优化过的ELF DAPLink没有明显优势?
2.STLinkV3的SWCLK可达24MHz,对比优化过的工作在10MHz的ELF DAPLink为何没有明显速度优势?

#84 Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2021-12-21 23:15:45

llinjupt
回复: 88

折腾了一段时间,总算有所成果,随写随贴... 抛砖引玉,先分析当前能够见到的DAPLink的问题。

1.当前DAPLink产品存在的问题

1.1 烧写速度
如果有细心的人尝试比较过市面上的DAPLink和STLinkV2,那么可以发现DAPLink的烧写速度要慢于STLinkV2。

如果目标芯片的FLASH比较小,例如网红芯片STM32F103C8T6,只有64KB,那么对比烧写速度是不明显的,但是要烧写FLASH大小为512KB,甚至1M的MCU时,速度差距就非常明显。

这并不意味着DAPLink做不到更高的速度,或者硬件方案不能满足,实际上当前的DAPLink硬件解决方案和STLinkv2的硬件解决方案通常都是基于XX32F103C8/BT6实现的。由于近段时间原厂STM32芯片的价格大幅上升,目前基于原厂STM32的方案很少(或者用拆机回收芯片),大部分进行了国产替代。但是无论哪种硬件,速度上是完全可以满足SWD协议需求的,后面会分析为什么。

在metro的大作中将CMSIS-DAP移植到了增强型C51单片机CH558 上,并实现了下载到目标芯片STM32F407的速度70KB/s。这个速度实际上已经可以比肩STLinkV3(注意,不是V2)的速度了。也就是说72M主频的STM32方案是完全可以做到更高速度的。

这里简单分析下制约当前市面上DAPLink下载器下载速度的瓶颈,主要归结为两种:

原因1:HID协议
大部分产品都是基于CMSIS-DAP HID协议的。CMSIS-DAP提供了两种USB通信协议版本,早期的HID协议版本(DAPLink v1)和最新的Bulk版本(DAPLink v2)。HID和Bulk均是USB协议中的通信实现方式。HID是针对人机交互设备的,例如平时使用的鼠标,键盘,游戏手柄等,这类设备通信数据量很小,但是要保证最小时延。由于USB2.0协议通信是需要主机发起的,也即设备不能主动通告,HID规定最小时间间隔为1ms,PC会轮询一次设备来读取信息。 USB2.0最大支持的包长为64字节,这就意味着HID最理想的通信速率是64/1ms = 64KBps,这看起来还不错。但是CMSIS-DAP协议是Ping-pong模式的,也即需要发一个命令请求,然后等待响应,然后继续发下一个命令,这样就导致,即便在理想情况下发送64字节至少需要2ms,直接速率打对折,极限速度只能到32KBps。

原因2:SWD/JTAG实际频率远远未达到10MHz
通过Keil等上位机可以设定DAPLink调试协议的工作频率,通常默认就是最高频率10MHz,这比STLinkV2的工作频率要高一倍(STLinkv2的SWD频率官方宣称为4MHz,实测大约在4.3MHz)。

而市面上的大部分DAPLink虽然设置了10MHz,然而实际测试发现,工作频率只有600-700KHz。这相当于实际工作频率只有标称频率的10分之一都不到。

SWD实际工作频率测试方法很简单,调试器连接目标芯片,Keil下载程序然后进入调试模式,此时只要将SWCLK接示波器探头,GND接示波器探头地,然后选择下降沿触发即可看到波形,测试某产品在选择10MHz时的实际工作频率:

实际工作频率

令人感到意外的是,笔者使用过3种不同硬件,不同包装方式(亚克力外壳版本,仿STLinkV2铝壳版以及TypeC接口的裸板版本),每一种使用的芯片都不同,另外这些产品的序列号是不同的,也即基本可以确定不是使用的同一固件,但是却得到了相同的工作频率,这就可以猜测,这些厂商都是直接拿ARM开源社区的源码进行了简单移植,也即直接编译的。并没有针对特定的硬件平台进行时序的调整。

所以这类固件即便将USB协议切换为Bulk也是无法提高烧写速度的。

1.2    CDC虚拟串口卡死
基于USB协议的虚拟串口通常有2种实现方式:VCP和CDC,最主要的区别就是VCP是需要安装厂商定制驱动的,例如基于CP2102芯片方案的USB转TTL小板就是VCP方案。由于厂商的驱动针对自身硬件方案进行了特殊优化,通常情况下VCP的性能更好。

CDC是USB协议提供的通用串口虚拟方案,各类操作系统自带驱动, 无需再安装驱动,使用方便,但是性能通常没有VCP的好。但是对于只用于打印调试信息的调试器来说,CDC方案已满足这种需求,并且提供了即插即用的便利性。

但是目前测试发现,所有被测的三款产品都会出现CDC卡死问题,特别是在下载和调试时,如果同时使用虚拟串口打印,那么很容易出现卡死现象,并且只能重新插拔才能继续使用。目前看是DAPLink基于STM32F103的开源方案在处理UART接收上有问题,否则不可能所有的厂商都犯相同错误。

手头有类似调试器的朋友可以使用串口测试工具,例如UartAssist.exe来测试下串口吞吐量,直接将RX/TX短接,然后关闭数据回显,间隔时间调整到最低,每次发送64-256字节的数据包,基本上几分钟就会卡死。从现象看应该是典型的Cortex-M方案的UART ORE上溢错误。这类错误一旦出现如果不清0相应寄存器,则UART硬件模块就不再接收新数据,现象为串口卡死。

1.3    不支持软复位
软复位是SWD协议特有的针对Cortex-M芯片实现的无需RST硬件连线就可以实现复位的功能。

DAPLink调试器在收到上位机的软件复位命令时,会在RST管脚生成一个复位脉冲(低电平),与此同时在SWDIO数据口发出一段复位序列,Cortex-M芯片中的DAP调试模块收到该序列后就会复位芯片,起到和连接RST相同的作用。

可惜的是这些调试器都没有适配该功能,查看了ARM开源社区的源码后,发现也没有实现该功能,这就解释了为何大部分厂商没有(似乎也不知道如何)适配该功能。

1.4    不支持JTAG
之所以不支持JTAG,理由似乎也和不支持软复位一样,原开源代码中只实现了JTAG协议,但是没有实现USB数据到JTAG数据的对接。

JTAG协议是相比于SWD更通用的调试协议,对于具有DIY精神的朋友,如果了解了JTAG协议和OpenOCD或者pyOCD,那么通过DAPLink的JTAG协议就可以做出烧写其他芯片的方案,当然实现调试要困难一些。

此外通过JTAG协议还可以实现边界扫描,对于了解目标MCU的芯片设计有很大帮助。有国外网友通过JTAG破解XXX,有兴趣的可以了解下。

SWD提供了普通用户的调试和烧写需求,而JTAG则为更富DIY精神的Geek们提供了了解MCU内部硬件结构的大门

1.5    其他小问题
遇到有一家的DAPLink的所有产品都是使用的开源代码中写死的A0000xxx序列号,也就是说你一台PC只能插入一个调试器,如果需要同时调试多块板子,或者一块板子上有多个MCU需要同时调试,那么只能换一台PC,因为上位机只能识别出一个调试器。对于这种低级错误只能无语了。

有些产品没有提供5V供电接口。

有些只是使用串接小电阻的方式兼容3.3V和5V,实际上这很容易引起电流倒灌,导致调试器工作不稳定,长时间使用引起元器件失效。

大部分产品提供了自恢复保险丝,可以在5V短路时有效保护电脑USB主板。但是如果3.3V供电口不小心碰到地,或者触碰到5V端子上,LDO可能直接损坏,固件丢失,或者电压输出不在正常范围之内,导致调试器工作异常。(这里提醒手头有这类调试器的网友不要做此类实验,山寨的STLinkV2也不要做,否则很可能瞬间损坏,笔者进行过故意接错实验,发现丢固件现象,几乎必现,毕竟STM32芯片不支持5V供电,所以“易耗品”的名头很可能是此原因导致的)。

2 现有产品亮点
目前看能在官方DAPLink上能有所创新,功能有所增强的很少,大部分的做法都是(有意或者无意)在软件功能和硬件上做减法。对于普通的消费者这是好事,但是能够购买到更快更稳定的产品也是终端用户的需求。

但是这并不意味着所有厂商都只奔money,而是有所创新,无论是在外观上还是功能上。MuseLab家做的DAPLink是可以支持JTAG和软复位的,必须点赞。

有的厂家适配了TypeC接口,这样更小巧精悍。实际上笔者并不认同必须使用TypeC(micro USB口也一样,对于DIY来说更易焊接),因为根本就使用不到USB3.0,但是它的意义在于可以将USB通信端延长,而缩短调试线的长度,这样SWD/JTAG通信距离变短,更加稳定。此外不得不承认TypeC接口更美观。

使用USB A口(STLinkV2的USB口)的调试器,如果用在台式机上,那么由于A口只能直接插在主机上,那么调试线就要很长,否则开发板必须放在主机旁边,很不方便。这一点深有体会。或者使用A口的延长线,但是没有TypeC和micro USB口的延长线常见,基本上买手机或者其他电子产品都会附送这类USB传输线。

相比于STLinkV2的单一铝壳封装,可以找到各种封装的DAPLink,为喜欢DIY的人提供灵感。笔者最开始看到的是透明亚克力外壳,看起来比较精致,这种外壳原本是用于一些USB电流电压表,后来被用于改造DAPLink。缺点也很明显,容易刮花,个头大,实际上高度可以压缩一半,体积也可以做得更精致,但是需要定制,量不大的话无疑增加成本。另外A口调试接延长线不是很方便。

DAPLink同样也有类似STLinkV2的铝壳封装,这种封装比较小巧,但是只开一个孔,电源灯和信号灯都是通过该孔观察,算个小缺陷。不知道为何当初STLinkV2的山寨厂商不多打一个孔?而且固执得坚持这种外壳形式很多年,变得只是上面的丝印和LOGO(说一个有趣的事情,曾在某宝评论区看到某用户发此评论:本来是要买ST原厂的,发的竟然不带ST的Logo。所以也可以看到ST公司对山寨厂商们的容忍程度,竟然让终端用户以为打了ST的Logo的STLinkV2就是原厂的,不过固件确实都是原厂的)。另外,同样地A口接延长线不方便。(也正因为有铝壳,STLinkV2版本各类“奇异”芯片神出鬼没,只要能兼容原厂固件即可。)

裸奔,这种类似开发板发售的形式成本最低,硬件底板形状随意,功能扩展容易,不会受到底板大小的限制,所以为何只做呆板无趣的长方形?完全可以充分发挥想象力,做个卡通形象,例如紫色佩奇,增加亮点吸引小小开发者:-)。正因裸奔,不用考虑外壳的限制,可以衍生出TypeC版本。缺点也很明显,裸奔就意味着有被咸猪手触碰的风险,使用的时候很容易触碰到裸露的金属点,造成调试器异常,甚至烧毁芯片,此外也不防水防潮。所以为何不加个透明的外衣热缩管,来点诱人的朦胧美?使用裸奔的方式,一般不会遇到打磨芯片,因为是找骂,没人会尝试。

3  笔者尝试的DIY
基于以上罗列的现有产品问题和特点,总结前人经验,目前做了两种版本的硬件,经过一段时间的使用,现在使用最频繁的是加了透明外衣的TypeC版本(原谅看着脏兮兮,一直在服役),桌子上放几块开发板也不会显得很乱。身材娇小,异次元着装,一眼望去满桌子的科技感(电路板)。

人肉焊接工程样机

首先感谢metro 的帖子和 ljbfly的帖子,以及参与讨论的众多高手。这些信息给了笔者很多启发。但是很可惜没有看到metro把东西做完善。因为从他的测试效果来看,如果测试环境都没问题的话,速度已经比肩STLinkV3(不是V2)了,也即和V3一样都达到了目标芯片支持的烧写算法的上限。最最令人惊讶的是他采用的是一颗主频只有56MHz的增强型C51单片机 CH558,最开始看到这个帖子的时候笔者没有太多留意,直到后来发现手头的类似调试器性能很差,和帖子中达到的速率相差甚远,外加ARM开放了DAPLink的源码,这才重新回过头来,结合源码来仔细分析SWD和JTAG协议和时序,最终在性能和功能上有所增强。

实际上软件移植工作在8月底就完成了,但是不想做一个不稳定的东西出来,不然徒然浪费时间,没有什么实用意义,功能强但不稳定,是不能进行大面积使用的。所以近来几个月都在公司内部大面积测试使用,发现并解决了一些小问题,整体上达到了高速和稳定并举的状态。双串口+烧写/调试同时并行使用,非常稳定。

如果有细心的网友仔细观察上图中的排针,就会发现和市面上的其他DAPLink的区别,也即是2X6而不是2X5。目前达到的功能和性能:
1.经过高度优化的基于Bulk协议的DAPLink V2让性能达到STLinkV3 80%-90%,远远超过STLinkv2。烧写STM32H743,1M FLASH只需15s.(不同性能的PC对速度略有影响,但是不大。后附有完整的针对Cortex-M0+/3/4/7的各样例芯片的实测结果和用例)。
2.支持Bulk版本的DAPLink V2的同时,支持HID 版本的DAPLink V1,只需要简单切换模式即可。有效兼容老版本的开发和下载软件。
3.支持双路虚拟串口,这就是为何排针使用2X6的原因。双路虚拟串口可以单独设置波特率,互不影响,支持常见的固定波特率9600到230400,相当于两个USB转TTL小板,远远满足日常调试打印需求。
4.同时支持SWD和JTAG协议。
5.支持SWD软复位,使用SWD下载时,无需连接RST线。
6.支持虚拟U盘的升级和模式切换,无需安装驱动和软件。支持升级时意外掉电防变砖。
7.支持3.3V和5V供电输出,带自恢复保险丝,3V3和5V不小心接地短路不会对调试器电路造成损害。双LDO,输出3V3和MCU的3V3由独立的LDO供电,更稳定,互干扰更小。3V3可稳定对外输出150mA。5V输出由USB协议供电决定,也即500mA去掉MCU自身供电,大约40mA。(上图中是最初版本,硬件未支持双LDO)
8.UART硬件兼容5V和3V3电平。
9.支持STC的免冷启动下载功能。

下载速度的提升,对比较大的项目可以节约大量的下载等待时间,对于一个开发组更可观,在公司层面效率提升就更显著了,目前在调试基于STM32H743芯片的项目上下载效率提升明显。

另外为何要做双UART呢?一开始打算实现SWO协议,但是发现SWO需要占用一路UART,但是SWO并不是所有的Cortex-M都支持,它依赖于芯片内部的ITM模块,但是Cortex-M0/0+没有内置该模块,此外ITM打印过多时会丢数据,基于以上考虑,去掉SWO功能,改成更实用的两路UART,这样对于调试多UART口的MCU时更方便,不需要借助其他USB转串口小板。

支持STC免冷启动下载是他人提出的功能,感觉很有用,就加了上来。这对于初学者,比如在校生,爱好者或者同时需要开发ARM和STC单片机的开发者无疑带来了方便:抽屉里一堆下载器,找的时候又常常不见所踪。

总结,1个ELF DAPLink = 普通DAPLink+BULK高速下载+1USB转TTL小板+1STC免冷启动下载器。体积小巧,携带方便。之所以给它取名字叫ELF,意为小精灵,但人小鬼大,一个顶仨。

先唠叨这么多,看起来成长篇大论了,后面贴性能对比图,外加加速思路,分析和实现。

#85 Re: Xilinx/Altera/FPGA/CPLD/Verilog » FT4232H可用的Xilinx FPGA JTAG调试器EEPROM分享 » 2021-10-13 13:42:14

搬石头者 说:

@llinjupt
用 FT2232HL 实现,也是 dump 原厂的固件。
使用 FTDI 的 FT_Prog 程序就可以 dump 到 EEPROM 的固件,但是烧录不了的,会丢失一半的数据。有 256 字节的数据,FT_Prog 默认烧录成 0xFF。

我记得Xilinx 的Vivado就只用了其中的一些字段判定是否是Digilent的固件,这个CH552方案,应该要完全模拟相关上位机的请求,并反馈相同应答,如果这个方案真实存在,(网上说是打磨芯片,不确定是否是WCH),那么逆向工程做的还挺有趣的,因为它还模拟了FT_Prog的一套请求,也即USB这一套指令,应该使用了内部FLASH做EEPROM,这种模拟确实很新奇,可以推广用于模拟其他USB方案的芯片,这样成本就大大降低了

#86 Re: Xilinx/Altera/FPGA/CPLD/Verilog » FT4232H可用的Xilinx FPGA JTAG调试器EEPROM分享 » 2021-10-09 21:47:18

@david 这倒是挺有趣的,FT232应该是实现调试Xilinx系列FPGA的最简JTAG方案了,大多都是抄的Digilent固件,不知道这个ch552如何模拟的FT232?我记得FT系列的芯片上位机由其自身专门的驱动,USB要完全模拟FT232的行为还是要费点功夫,不知道有没有相关的实现连接?谢谢

#87 Re: Xilinx/Altera/FPGA/CPLD/Verilog » 想用国产FPGA真不容易 » 2021-10-03 10:54:01

思路不改变,总是以为有什么高科技,藏着掖着,实际上那些东西都是别人玩过多少年的,现在是把握生态,就能把握市场,否则蛋糕只能被别人切,最后连汤都喝不上,只能靠价格,实际上算上额外的开发成本,还有产品供应不稳定,潜在成本非常大,小厂做东西就是:成熟方案.

#88 Re: Xilinx/Altera/FPGA/CPLD/Verilog » FT4232H可用的Xilinx FPGA JTAG调试器EEPROM分享 » 2021-10-03 10:48:58

以前玩矿板的时候,用FT2232HL做过,那时候芯片挺便宜,现在翻了几番

#89 Re: VMWare/Linux/Ubuntu/Fedora/CentOS/U-BOOT » 解决 github.com 克隆速度太慢的问题 » 2021-10-03 10:45:09

谢谢分享,如果谁能把arduino环境安装的给clone过来就好了,很多环境都要单独下载,单独安装。

#90 Re: Cortex M0/M3/M4/M7 » 在Sipeed RV-Debugger Plus上移植CMSIS-DAP » 2021-09-15 16:26:25

@metro 从规格上看,BL系列好像是对标的ESP,请问相对ESP系列比有什么优势?

#91 Re: DIY/综合/Arduino/写字机/3D打印机/智能小车/平衡车/四轴飞行/MQTT/物联网 » 捡了个便宜的高级ZYNQ XC7Z010 开发板玩玩 » 2020-12-21 19:02:25

你们都太给力了,注意去原系统密码一定要模拟nand,实际测试用使用 mtdram是不能成功的。

# modprobe jffs2
# modprobe mtdblock
# modprobe nandsim first_id_byte=0x20 second_id_byte=0xa2 third_id_byte=0x00 fourth_id_byte=0x15 # 64Mb,由于rootfs大小为64Mb,这里必须设置为64Mb,其他大小参考:http://linux-mtd.infradead.org/faq/nand.html

# mtdinfo /dev/mtd0
mtd0
Name:                     NAND simulator partition 0 # 确保模拟出的是nandflash
Type:                      nand
Eraseblock size:              131072 bytes, 128.0 KiB # 必须和FLASH芯片规格保持一致
Amount of eraseblocks:          512 (67108864 bytes, 64.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:0
Bad blocks are allowed:         true
Device is writable:             true

破了原系统密码,就可以使用passwd设置新密码,这样ssh就可以进去了, 不用SD卡槽,不用串口,如果感兴趣可以改改原系统和硬件,自己生产矿机了,
原机web的登录名和密码都是admin和admin

页脚

工信部备案:粤ICP备20025096号 Powered by FluxBB

感谢为中文互联网持续输出优质内容的各位老铁们。 QQ: 516333132, 微信(wechat): whycan_cn (哇酷网/挖坑网/填坑网) service@whycan.cn