Alexis,
Thank you for your suggestion, but I'm still not entirely clear as to what the problem root-cause is.
Are you saying that the data from the currRecvBuf needs to be copied before the next send event?
If so then I can easily modify my code to achieve this, at present I simply signal an RTOS task to process this when ready.
Or, are you suggesting that the occurrence of a USB interrupt (calling USB_DeviceCdcVcomCallback) while USB_DeviceCdcAcmSend() is being called causes the corruption of the currRecvBuf?
As regards toggling the GPIO as you suggest, my understanding is that the send function USB_DeviceCdcAcmSend() simply queues the data for sending by the USB peripheral so the pin GPIOA would have to be set before sending and cleared in USB_DeviceCdcVcomCallback(). Is that what you are suggesting?
If so, then surely GPIOB toggling while GPIOA is high would simply be a function of the positioning of the two lines in USB_DeviceCdcVcomCallback().
By the way, I think the SDK example code contains a possible bug.
In USB_DeviceCdcVcomCallback() the handler for sending complete event includes code to reset the buffer for the next receive event (as shown in the code fragment below), why should the receiver be reset after a send event?
case kUSB_DeviceCdcEventSendResponse:
{
if ((epCbParam->length != 0) && (!(epCbParam->length % vcomInstance->bulkInEndpointMaxPacketSize)))
{
/* If the last packet is the size of endpoint, then send also zero-ended packet,
** meaning that we want to inform the host that we do not have any additional
** data, so it can flush the output.
*/
error = USB_DeviceCdcAcmSend(handle, vcomInstance->bulkInEndpoint, NULL, 0);
}
else if ((1 == vcomInstance->attach) && (1 == vcomInstance->startTransactions))
{
if ((epCbParam->buffer != NULL) || ((epCbParam->buffer == NULL) && (epCbParam->length == 0)))
{
/* User: add your own code for send complete event */
/* Schedule buffer for next receive event */
error = USB_DeviceCdcAcmRecv(handle, vcomInstance->bulkOutEndpoint, vcomInstance->currRecvBuf, vcomInstance->bulkOutEndpointMaxPacketSize);
}
}
else
{
}
}
I have removed this from my own code and have seen no obvious side effects.
Regards,
Padraig
