ChTomt-优快云博客

原创 STM32下载调试器link测速

我也想,但不知道为什么,优信家买的这个G431CB只有64KB flash能用,超出64KB就flash擦除失败,因为手头只有这一个,也不高兴进一步排查问题,姑且就用64KB了不影响本次测试)我自己已经用合宙的开源资料做了一个定制化的小link,自己做的STM32板子都预留定制化接口快速烧录调试不说,还有波特率可以高达6M的虚拟串口,合宙牛逼。STlink被爆杀,该用什么link不用我说了吧.很穷买不起,但我觉得合宙这个下载器应该不比百元的STLinkV3要慢.希望有大神可以测一测。

2024-04-05 02:52:20 453 2

原创 STM32硬件I2C时序配置和最高速度测试

关于timing参数的最小时间单位，我的理解是时钟树配给I2C的频率除去预分频就是了，例如160M主频如果不分频，那么timing的数字就表示多少个（1/160M）秒，但实测并不是这样，似乎时钟树提供给I2C的时钟首先已经被分频了一次，大约已经给到了10分频。SDADEL和SCLDEL可以参考下图我框出来的，I2C在SCL高电平时数据有效，这个时间主要就是为了防止SCL高电平时SDA数据还没准备好，可以想象大部分情况下给到0其实也不会有问题，但原则上还是至少给1避免不稳定因素。这是一个32bit寄存器。

2024-03-18 00:50:33 3225 1

原创记录超快的SDRAM驱动

在考虑到阻抗和等长的情况下,频率跑到了180M,已经远超单片机和SDRAM手册值,时序也是按照不出错为标准取的极限值。STM32H750XBT6通过16bit FMC驱动IS42S16160J-7。读写为全片32M,字节,半字,比特连续写入读出。使用32bit的TIM2计时,240M不分频。

2024-03-11 20:36:56 347 1

原创（整活）STM32H7在内电层连通良好的情况下,去耦电容的必要性测试

当然无法正常运行，甚至无法再次烧录，烧录报错无法复位内核。没有任何电容的情况下强行拉480M对于单片机确实是压力过大了，示波器打了一圈，发现是VCAP纹波过大，1.2V纹波足足有300mV，没有供电全是纹波。电源为电脑5V电源经过SY8089转为3.3V供VDD,3.3V再经过SY8089转为2.4V(其实是想1.8V,电阻配错就2.4V了)供VDDLDO。内核跑到了480M，初始化之后跑了TIM1三路PWM，有输出，调试也可以进，单步走也没问题。现在已经有三个2.2uF，优势在我，480M跑起。

2024-03-07 19:54:15 397

翻译 STM32的QSPI在dual-flash双闪存模式下读写寄存器描述,译自H743参考手册

这意味着，如果每个闪存存储器在提取状态寄存器指令后提供了 8 个有效位，那么 QUADSPI 必须配置为 2 字节（16 位）的数据长度，并且 QUADSPI 从每个闪存存储器接收一个字节。结果寄存器（数据寄存器）的最低字节是闪存 1 状态寄存器的最低字节，接着的字节是闪存 2 状态寄存器的最低字节。然后，数据寄存器的第三个字节是闪存 1 的第二个字节，而第四个字节是闪存 2 的第二个字节（假设闪存存储器具有 16 位状态寄存器）。在双闪存模式下，FLASH 1 接口信号的行为基本与正常模式相同。

2023-12-20 13:18:47 520 1

原创 STM32H723使用LL库驱动SPI时遇到的坑

一般情况下，SPI就可以正常收发了，但H7不一样，怎么往TXDR里面塞数据就是没输出，引脚一点波形也没有，看寄存器状态也不对，多塞几次状态寄存器就开始报错了。在使用DMA发送的时候，只是从DMA这边配置发送端和接收端的宽度还不行，DMA实际搬运的时候会受到LL_SPI_SetDataWidth设置值的影响，例如，设置了通道两端都是8bit，但最后一次设置的SPI数据宽度是16bit，SPI实际还是会以16bit进行发送。可能有的人要说，上面怎么算坑了，明明是你技术不行，H7一直都这样。

2023-11-29 11:19:14 1865 3

原创 STM32cubemx避免选中的引脚被修改

在核心板和底板的组合中,使用stm32cubemx开发的时候经常会出现一种情况,就是核心板已经分配的引脚和功能,在后续底板开发启用其他外设时,会出现修改复用的情况,例如核心板上已经占用LTDC_D0~D7,后续底板配置了SPI1 SCK MOSI MISO,可能存在,SPI的MISO占用了LTDC本来分配的D2,自动把D2复用到其他引脚上,这样肯定不行。

2023-11-27 10:50:16 428 1

原创记STM32外扩SDRAM

记录使用STM32H723外扩32MB的SDRAM，硬件和代码设计

2023-11-12 12:47:44 1214 3

原创记AIR32 IO最大翻转速率测试

nop延时就是很好的证明，明明理论上是单周期命令，已经深入到汇编层面了，但72M主频的单片机，nop72M次消耗的时间，远超预期的1S，可能会到10S，也就是说我们的代码实际执行速度比理论要慢得多，由于单片机内部原理过于复杂我也不了解，无法解释。这里再插入一个热知识科普，STM32的IO初始化时配置的“speed”（2M,10M,50M），实际不会影响翻转频率，改变的是“压摆率”，也就是波形上升和下降的速度。而高电平持续时间变成了理想的，高电平短于低电平，因为IO拉高比拉低需要的时间更长，符合预期。

2023-11-03 14:45:54 516