USB Host Bulk Input NAK || STM32U575

[RRajb.2]

Hi All,

I am working on the STM32U575 for host mass storage class.

I am not using stm32 middle ware for this due to some reasons.

I am using TinyUSB open-source stack to implement the Host mass storage class.

with my current implementation I am able to use HID device, but I got stuck at MSC enumeration.

Currently facing below issue.
1. During enumeration process After sending the Unit Test Ready Command I am getting correct CSW
response from device but soon after that Getting NAK from USB device.
-- What could be the reasons for getting the NAK - Also I after getting NAK I am continuously getting Channel halted interrupt.

I have attached the logic analyzer file for batter understanding.

Any Help will be highly appreciated!

[RRajb.2]

Sorry my bad, you have to change in _endpoint_xfer() function only,

if (ep->ep_type != 2)

{

    uint8_t *toggle = (hc->ep_is_in) ? &hc->toggle_in : &hc->toggle_out;

    *toggle = ep->toggle;

}

I kept one more check in HAL_HCD_HC_NotifyURBChange_Callback(), but it was for some other purpose.

regarding handling of data more then 256 bytes(rather size more then wMaxPacketSize), you will face that problem may be after making this change. because that is not handled currently in that driver file.

[ACapo.1]

Great thanks for that, I will change that in _endpoint_xfer()...

[ACapo.1]

Hi @RRajb.2

That _endpoint_xfer() change brings it all to life, thanks very much.

If I have the USB inited as HS then both FS and HS devices work fine, I do not get the issue with the transfers being bigger than the packet size.

With it inited as FS then I see the issue that you mention with HS devices, but strangely FS devices work even though the transfers are bigger than the packet size.

Very strange!

Once again thanks for all your help on this, it is really appreciated.

Andy

[Piranha]

https://github.com/hathach/tinyusb/tree/master/src/portable/st/stm32_fsdev

https://github.com/hathach/tinyusb/tree/master/src/portable/synopsys/dwc2

These are the TinyUSB drivers for STM32 devices, not some HAL broken bloatware again.

[ACapo.1]

Hi @Piranha 

But there is no host support which is what we are talking about.

[Piranha]

OK, but then it would be even better to implement that driver at a somewhat decent level and upstream it to the TinyUSB project. :)

[ACapo.1]

Got to get it working properly first though :)

[Piranha]

And, to do that, you have to get rid of the HAL...

[ACapo.1]

Well I now have it all working with the HAL so I guess that is not true.

The trick is to use the HAL in the standard way to read full length from IN endpoints but to split the transfers for the OUT endpoints into packets. Obviously it would be better if they would fix this in the HAL but there is a workaround.

The advantage for me for using the HAL is I don't have to learn all the register layout and processes, all I have to do is call a few functions.

Don't get me wrong, I'm not a fan of the HAL but for me this is just a hobby, it's not like what I'm doing is production code.

[Piranha]

The real problem is that people are so unaware of the actual software issues, that they do not even realize that those exist and therefore think that HAL is acceptable or even fine. Don't get me wrong either, but it is a consequence of a general lack of competence in the whole software industry. ;) That said, ST's "genius" team is at fault here, not hobbyists. The following flaw alone is enough to disallow the use of HAL in anything decent:

https://community.st.com/t5/stm32-mcus-embedded-software/bug-stm32-hal-driver-lock-mechanism-is-not-interrupt-safe/m-p/289837

Also an abstraction layer is a good thing, when used in places, where it is appropriate. The ironic thing is that the HAL is also falling short in that front either. Again because it's API is designed by "geniuses". Just look at what amounts of workarounds one must develop to implement even a simple USART reception:

https://community.st.com/t5/stm32-mcus-embedded-software/stm-uart-dma-to-receive-multibyte-packet/td-p/619031

A decent driver written from scratch, which integrates all that and is even better, is much shorter and simpler than the workarounds alone... :D That said, if you've got the version with HAL at least somehow working, cleaning replacing the HAL and then improving the overall design shouldn't be that hard. :)