【求助】USB带电状态下枚举后第一次数据上传，PC收不到

各位大佬好，我在工作使用NUC123这款设备，发现芯片带电情况下进行USB枚举后的第一次的上传数据，
PC有几率收不到，通过Debug发现设备发送了，但是PC就是没收到。
于是在NUC123例程Keyboard的基础上做了小修改，通过短接连接PD2（ 64 pin51引脚）和地，每连接一次会上传keyboard的两条数据 00 00 04 00 00 00 00 00 和 00 00 00 00 00 00 00 00从而输出一个字母a，但是发现实际测试中设备带电下插上USB枚举后的第一次操作，同样有几率PC收不到00 00 04 00 00 00 00 00只能收到00 00 00 00 00 00 00 00，请问各位大佬有遇到这种情况吗？
小弟在此附上上述测试代码，希望大佬们赐教。

请问这样做是为了规避缺陷吗？还是说链接usb后，就该先发一个空数据。

请问这样做是为了规避缺陷吗？还是说链接usb后，就该先发一个空数据。

1.如果是需要提前上传，为什么这个现象是有再现率的呢？
2.如果有再现率的话，用户在插上键盘后有概率通过Bus Hound抓包发现第一条无效数据，这个能避免吗
照我的流程，用catc抓是正常的
代碼跟你的電池供電無關。
基本上，mcu有電就開始跑代碼。
有usb plug event的時侯，就可以先寫資料到usb usb buffer之中。

我这边也有同样问题，搬小板凳坐等大神回复

a_ziliu 发表于 2018-7-10 09:12
是的，基本上USB DEVICES都是准备好资料，让主机端来拿走。

无效数据可以发0字节码，像这样USBD_SET_PAYLOAD_LEN(EP2, 0);

a_ziliu 发表于 2018-7-10 09:12
是的，基本上USB DEVICES都是准备好资料，让主机端来拿走。

谢谢大神，我还有几点疑问，
1.如果是需要提前上传，为什么这个现象是有再现率的呢？
2.如果有再现率的话，用户在插上键盘后有概率通过Bus Hound抓包发现第一条无效数据，这个能避免吗？
3.您之前说后开USB中断，如果是自带电池供电的键盘USB中断这块，如何处理好呢（是枚举成功后断开USB中断，然后准备usb buffer资料，在开启USB中断？）

是的，基本上USB DEVICES都是准备好资料，让主机端来拿走。

a_ziliu 发表于 2018-7-9 10:00
這跟上電無關，usb enum之後，就開始要資料。
先把endpoint 2資料準備好，讓usb取走 ...

谢谢回复，那要是实际键盘环境下，枚举后没有键盘按下也要准备endpoint 2的资料（空的无效的数据），然后通过USBD_SET_PAYLOAD_LEN 发上去，您看是这个思路吗？

這跟上電無關，usb enum之後，就開始要資料。
先把endpoint 2資料準備好，讓usb取走