Posible race condition on usb_device_dci.c

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Posible race condition on usb_device_dci.c

1,046 Views
janbertran
Contributor II

I have not observed any issues yet, just was looking at code to understand buffer usage/copy ...

and came with this code:

file usb_device_dci.c of LPC SDK 2.5

function USB_DeviceTransfer at line 277 checks if endpoint callback is busy and then "enters critical" to mark it busy

if (deviceHandle->epCallback[(uint8_t)((uint32_t)endpoint << 1U) | direction].isBusy)
{
    return kStatus_USB_Busy;
}    "here is race ? if not, then why enter critical to set a boolean ?"
USB_OSA_ENTER_CRITICAL();
deviceHandle->epCallback[(uint8_t)((uint32_t)endpoint << 1U) | direction].isBusy = 1U;
USB_OSA_EXIT_CRITICAL();

I think it should be, first enter critical, check and mark it busy and in any case exit critical

USB_OSA_ENTER_CRITICAL();
if (deviceHandle->epCallback[(uint8_t)((uint32_t)endpoint << 1U) | direction].isBusy)
{
    USB_OSA_EXIT_CRITICAL();
    return kStatus_USB_Busy;
}
deviceHandle->epCallback[(uint8_t)((uint32_t)endpoint << 1U) | direction].isBusy = 1U;
USB_OSA_EXIT_CRITICAL();

Labels (2)
0 Kudos
1 Reply

895 Views
Alexis_A
NXP TechSupport
NXP TechSupport

Hi Jan,

The logic in this implementation is that you can't use this peripheral if its busy, you'll need to check if other endpoint is using the peripheral, if its available the endpoint enter the critical section and set the flag to indicate other endpoints that the peripheral is busy.

pastedImage_1.png

You're approach is also right, but in the rare case the endpoint that is keeping the peripheral busy sends an interruption in this interval, this will be lost.

I hope this helps you.

Best Regards,

Alexis Andalon

0 Kudos