2016-07-10 11:28 PM
In the file ''usbh_msc.c'' generated by CubeMX there seem to be various instances of null pointer dereferencing.
Many functions begin with this statement: MSC_HandleTypeDef *MSC_Handle = (MSC_HandleTypeDef *) phost->pActiveClass->pData; which doesn't check whether pActiveClass is NULL. It seems that in some places the issue is quite harmless since there are other guards, like if(phost->gState == HOST_CLASS) in USBH_MSC_IsReady() Nevertheless, in other places the problem is there, and it exists even when harmless (e.g. if you catch null pointer dereferencing by MPU-disabling access to the address 0x00000000.) Is this a bug, or should the user code manually check for something, before calling functions like USBH_MSC_IsReady()? What are those checks?2016-07-13 07:26 AM
Hi stefano.qi,
Using CubeMX, the usbh_msc.c is not added if you don't select the correct class.So I don't think that such issue may occur.-Mayla-To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2016-07-14 01:11 AM
The issue exists when everything is configured, too.
In ''usbh_core.c'', phost->pActiveClass is inited to NULL (USBH_Init() and USBH_DeInit()), and set to the proper value only during the device enumeration (USBH_Process(), case HOST_CHECK_CLASS). Of course I can work around the problem by performing the check myself: if(phost->pActiveClass && USBH_MSC_IsReady()) but it feels like USBH_MSC_IsReady() should do the check itself, instead of assuming everything is all right.