可能是发生NAK 后，软件错误地把整个192B 传输重新提交了。这会引出两个现象： 1、HCTSIZ / PKTCNT 被重新写。 这时会看到，本来还剩一部分没发完，结果 PKTCNT 又回到 3。 2、NPTX FIFO 被重复灌数据。 因为同一段 192B 又被重新塞进FIFO，最后可能卡在 USB_WritePacket()。 原因很可能是控制 OUT 的NAK 重试逻辑有问题。 你要确认下，设备回了 NAK 之后，主机是不是把整段192B 又从头提交了一遍。 具体来说，就是观察在出错或被 NAK 后再次发送时，是否简单地再次SubmitRequest(192)，并把 xfer_count 清零。 正常情况下，主机只应重试还没成功发送的那一包，而不是不管前面已经发出去多少，又把整段数据重新发一遍。
这段发送流程里通常没必要手动 SNAK，SNAK 一般是需要停止传输时才使用的动作。 STALL状态在 F4系列OTG模块 上通常不是硬件操作的，而是软件处理的。 可以重点搜索代码里哪里写了 DIEPCTLx.STALL，再跟踪是谁、因为什么条件触发了这条路径。
先写个bootloard，里面规定一个固定的地址，代表要跳转A区还是B区， 你升级的时候，自己去先读这个地址的数据，是A就改为B，是B就改为A,要注意先进行OTA 升级包校验，校验过来再设这个地址，再重启
修复后解决了么？ 没有的话，可以参考一下例程 STM32Cube_FW_F4_V1.28.1\Projects\STM324xG_EVAL\Applications%uSB_Device\CDC_Standalone
厂家有现成的例程，可以跑跑或参考一下 STM32Cube_FW_L4_V1.18.2\Projects\NUCLEO-L476RG\Examples\FLASH\FLASH_EraseProgram
因为我没太理解你的需求，看看下面这串代码是否能给你带来启发。 #include <stdio.h> int main(void) { int ADC = 58888; // 0-9 ascii:48-57 int value = 0; int temp = ADC; while (temp != 0) { value = temp % 10; temp = temp / 10; printf("%d\n", value); } return 0; }
