Posible race condition on usb_device_dci.c

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Posible race condition on usb_device_dci.c

1,692 次查看
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();

标签 (2)
0 项奖励
回复
1 回复

1,541 次查看
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 项奖励
回复