软件执行收到很多因素影响，并不能固定速度。 比如，缓存，中断，DMA搬运周期也非固定... 所以需要高精度只能依靠硬件。MCU的硬件来自于时钟源。如果时钟源的抖动超过了需求，那就实现不了。
哥们，下载了一下，在固件包文件夹的Demonstrations里面，Modules有BLE的示例!(data/attachment/forum/202608/22/201750kzqg9p37ib1c8130.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/300 "image.png")
NC 你就当作占用脚就好了 实际没有什么作用 用过很多BLE BLEmesh WIFI&BLE 然后就是 ESP32C3 S3 这些模组都很怕干扰,也没有说NC一定要接地 或者单焊盘无布线的方式焊接在板子上 NC 代表的都是没有作用 只是为了焊接方便, 引脚定义也可以看出来 是没有任何作用的 有作用至少会写个I 或者 O这样子 理论上来说你不给他焊盘都没事😄
M24LR的能量收集是由多圈PCB天线、片内RF电路和外接滤波电容一起实现的 这块板子只完成RF能量收集演示，RF通信由另一块收发板(绿色)完成
那你直接用寄存器操作好了，不用绕弯子，最接近底层，MCU执行也非常快。但是开发周期会很慢。 用HAL库不用操作寄存器，层层封装，好理解，开发快。
这段发送流程里通常没必要手动 SNAK，SNAK 一般是需要停止传输时才使用的动作。 STALL状态在 F4系列OTG模块 上通常不是硬件操作的，而是软件处理的。 可以重点搜索代码里哪里写了 DIEPCTLx.STALL，再跟踪是谁、因为什么条件触发了这条路径。
可能是发生NAK 后，软件错误地把整个192B 传输重新提交了。这会引出两个现象： 1、HCTSIZ / PKTCNT 被重新写。 这时会看到，本来还剩一部分没发完，结果 PKTCNT 又回到 3。 2、NPTX FIFO 被重复灌数据。 因为同一段 192B 又被重新塞进FIFO，最后可能卡在 USB_WritePacket()。 原因很可能是控制 OUT 的NAK 重试逻辑有问题。 你要确认下，设备回了 NAK 之后，主机是不是把整段192B 又从头提交了一遍。 具体来说，就是观察在出错或被 NAK 后再次发送时，是否简单地再次SubmitRequest(192)，并把 xfer_count 清零。 正常情况下，主机只应重试还没成功发送的那一包，而不是不管前面已经发出去多少，又把整段数据重新发一遍。
关于前段时间SDADC卡死的那个问题 我想了想 结合目前的现象 推导出的合理机制是 在溢出的同时擦除flash会导致溢出位无法正常清零 卡住置1 而手册上明确指出 当溢出位置为1的时候 SDADC无法响应新的触发请求 这就会导致SDADC无法正常更新而主循环及其他中断可正常触发的现象 原工程代码中4h写一次flash 也符合几个月撞上一次的这个触发频率 在没有擦除Flash操作时，SDADC中断回调函数内里有一个函数会自动等待转换完成，同时使得状态寄存器复位，溢出位清零。 但现在，由于SDADC溢出位卡住置1使得无法响应触发请求，导致： 程序无法进入SDADC中断； 溢出位一直卡死为1； 最终造成中断失效和ADC无法采集数据。 目前的现象完全符合之前的描述，而关于SDADC溢出的原因，推测是由MCU内部的通讯或其他控制任务以及长时间运行导致溢出。 同时观察到如果在调试模式下是无法稳定复现该bug的，需上电时全速运行可稳定复现。
先写个bootloard，里面规定一个固定的地址，代表要跳转A区还是B区， 你升级的时候，自己去先读这个地址的数据，是A就改为B，是B就改为A,要注意先进行OTA 升级包校验，校验过来再设这个地址，再重启
Keil 好像不支持 STM8 的开发。 目前见到的有以下 IAR Embedded Workbench for STM8Cosmic STM8 + STVD
可以试试，将这个例程移植到DISCOVERY 板上 STM32Cube_FW_F3_V1.11.4\Projects\STM32303C_EVAL\Applications%uSB_Device\CDC_Standalone
微信公众号
手机版
