USBX DFU crashes dereferencing a NULL pointer

[DmitryR]

Good day all,

 

USBX crashes at line 171 of the file ux_dcd_stm32_initialize_complete.c, as the dcd structure is not initialized at this point. I have tried this on two different MCUs, U575 and H753. In concert, on the H753 the code generator does not generate the call to MX_USBX_Device_Init() and in both cases the call to HAL_PCD_Start() is not generated as well, so this functionality will not work out of the box either. I suppose that I should insert some more calls for initialization, does anyone have idea?

 

Regards,

Dmitry

[FBL]

Hi @DmitryR 

First, would you attach IOC file to reproduce for H753?

Second, do you confirm this line is failing https://github.com/STMicroelectronics/x-cube-azrtos-h7/blob/3e4c2f475bd18eaaec0c74b2719c9e9e19f7d66e/Middlewares/ST/usbx/common/usbx_stm32_device_controllers/ux_dcd_stm32_initialize_complete.c#L171C1-L172C1

Which board are you using?

[DmitryR]

Hi @FBL ,

 

yes, exactly this string. I use STM32H753I-EVAL2 and NUCLEO-U575ZI-Q.

 

Regards,

Dmitry

[FBL]

Hi @DmitryR 

MX_USBX_Device_Init() is called in app_usbx_device.c

Second, USBX doesn't use HAL_PCD_Start(). Check this article How to implement USBX in standalone mode - STMicroelectronics Community

[DmitryR]

@FBL ,

 

What you are writing here contradicts to what is written after the link. This document states to add both MX_USBX_Device_Init() and HAL_PCD_Start(). In any case it describes only one particular case. For example I use USB_FS and not USB_HS and not in OTG mode. Because of this all references to HS and OTG do not work for me. OK, I have just omitted usb_otg.h and corrected HS to FS. By the way, the code generator for U575 generates the call to MX_USBX_Device_Init(). It is simply terrible that the same functionality is generated differently in different bundles. 

 

But it still does not work because the function _ux_device_stack_class_register() returns an error. In concert, if I add add one anther class as it intended to be (storage class) it returns error even earlier, at ux_device_stack_initialize().

 

It is interesting if you understand that all this makes the code generator virtually unusable? The main use of the code generator is a quick success, a work "out of the box". Your engineers were too lazy to program it to the end and the fact that the last 10% of the code generation must be done manually destroys all the benefit. It makes you to write an additional documentation and to answer tons of questions here. And it still does not work. 

 

Regards,

Dmitry

[DmitryR]

By the way, I have tried also to generate it in normal mode, not standalone. The function app_ux_device_thread_entry() is generated empty and I have no idea what to call there as neither ux_system_tasks_run() nor ux_device_stack_tasks_run() are not implemented despite both are declared in the ux_api.h

 

Regards

[FBL]

Hi @DmitryR 

Indeed, the function calls might differ from those generated on my target. This discrepancy could be due to the fact that some lines were released at different times. Additionally, STM32U5 uses the USBX native library, whereas H7 relies on the classic library, which could result in differing function calls.

I couldn't reproduce on my end. Would you attach a minimum project to reproduce the issue?

[DmitryR]

@FBL 

I am sorry to say that I have not understood what you have not be able to reproduce? The fact that the function app_ux_device_thread_entry() is generated empty and neither ux_system_tasks_run() nor ux_device_stack_tasks_run() are implemented? 

 

Also, it is very, very bad that different devices use different stacks. This means that I must verify on the exact device I am aiming and cannot use kit I have. I find this situation very disappointing. Please see https://community.st.com/t5/stm32cubemx-mcus/stm32cubeprogrammer-cannot-connect-to-usbx-dfu/m-p/776629, I have significantly moved forward meanwhile.

 

Regards,

Dmitry

[FBL]

Hi @DmitryR 

I understand your frustration! MX_USBX_Device_Init() is generated from MX using latest version without issues on H7. Try to update to latest version X CUBE AZRTOS H7 and CubeMX. app_ux_device_thread_entry is indeed generated empty as it is considered as user code. For reference, here is a working example STM32CubeU5/Projects/NUCLEO-U5A5ZJ-Q/Applications/USBX/Ux_Device_DFU at main · STMicroelectronics/STM32CubeU5

Both products use 2 stacks. However, U5 is native " originally developed using the " USBX. But H7 is native "originally developed using the " USB classic library. 

[Andrei Chichak]

I've been working with USBX and FileX recently and getting past the init stage has always come down to adding memory to the pools. There's no hints as to how much memory is needed, and when the allocators fail it's impossible to figure out how much memory it was looking for, but it is very clever code.

Anyway, see if adding memory helps