cancel
Showing results for 
Search instead for 
Did you mean: 

HAL_PCDEx_BCD_Callback defect in L4 1.12.0 HAL

Rob.Riggs
Senior

There was a change in the HAL_PCDEx_BCD_Callback() function defined in usb_device.c that, by default, results in the code not handling the PCD_BCD_DISCOVERY_COMPLETED notification.

The switch statement for processing the state changes in the new user code is wrapped in an if (hpcd->battery_charging_active){...} however battery charging is deactivated before calling HAL_PCDEx_BCD_Callback(PCD_BCD_DISCOVERY_COMPLETED), so the switch statement is never evaluated in that case.

The solution is to just remove the if() {...} guard completely. I fail to see why it was added.

2 REPLIES 2
Ben K
Senior III

This is in my opinion the worst design I have seen in ST code. If you call a function in order to get the result of an operation, the function should normally pass it back to you as a return value. Here however we have HAL_PCDEx_BCD_VBUSDetect() which instead of returning the PCD_BCD_MsgTypeDef result, it calls another function (HAL_PCDEx_BCD_Callback()), which the user should define separately, and handle the result there. So I wouldn't have high expectations on the quality of this code.

Rob.Riggs
Senior

It is a perfectly fine design. It simplifies the management of the ​state machine for the developer. That function is called back multiple times when the device is plugged in.