Updates, I committed a simple workaround in trunk, it seems to work under all conditions (tested using Linux Mint 18.2).
Could you confirm that it is working for you too? after confirmation I will backport in 16.7 too.
The root of the problem is that the XFRCM interrupt seems to arrive randomly later than STUP interrupt on the L4 and it is messing with the state machine, the fix is to ignore XFRCM if the state machine is not in a correct state. This is weakening the state machine checks so it is done only if STM32_OTG_SEQUENCE_WORKAROUND is defined, the L4 registry defines it.
Giovanni
STM32L476 USB HAL errors Topic is solved
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: STM32L476 USB HAL errors
Hi,
i have backported your fix to 16.1.8 and it seems not to work.
I am hitting this debug assert:
usbp->ep0state is USB_EP0_ERROR when the assert is hit.
Backporting in this case means replacing hal_usb.c, hal_usb.h, hal_usb_lld.c, hal_usb_lld.h, stm32_otg.h, stm32_registry.h with the trunk version and fixing up the thread creation in hal_usb_lld.c to match the old api.
What can i do to support you further?
Cheers
Vincent
i have backported your fix to 16.1.8 and it seems not to work.
I am hitting this debug assert:
Code: Select all
void _usb_ep0setup(USBDriver *usbp, usbep_t ep) {
size_t max;
osalDbgAssert(usbp->ep0state == USB_EP0_STP_WAITING, "not in setup state");
usbp->ep0state is USB_EP0_ERROR when the assert is hit.
Backporting in this case means replacing hal_usb.c, hal_usb.h, hal_usb_lld.c, hal_usb_lld.h, stm32_otg.h, stm32_registry.h with the trunk version and fixing up the thread creation in hal_usb_lld.c to match the old api.
What can i do to support you further?
Cheers
Vincent
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: STM32L476 USB HAL errors
I added that assertion with last changes for debug.
Does it fails in trunk too or just in 16.1.8? Could you check the EP0 state when the assertion is triggered? How are you testing?
Giovanni
Does it fails in trunk too or just in 16.1.8? Could you check the EP0 state when the assertion is triggered? How are you testing?
Giovanni
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: STM32L476 USB HAL errors
Could you try to change line 1006?
Set the value to 1 then try to just set the register to zero, I suspect there is another cause for this.
Another test, could you try to remove just that assertion?
Giovanni
Code: Select all
otgp->oe[0].DOEPTSIZ = DOEPTSIZ_STUPCNT(3);
Set the value to 1 then try to just set the register to zero, I suspect there is another cause for this.
Another test, could you try to remove just that assertion?
Giovanni
Re: STM32L476 USB HAL errors
Giovanni wrote:I added that assertion with last changes for debug.
Does it fails in trunk too or just in 16.1.8? Could you check the EP0 state when the assertion is triggered? How are you testing?
Giovanni
I did not have time to test it in trunk. That would require significant time to test. If you feel it is necessary, i will do it though.
As stated above, the EP0 state is USB_EP0_ERROR when the assertion is hit.
Last edited by lilvinz on Mon Aug 21, 2017 7:08 am, edited 1 time in total.
Re: STM32L476 USB HAL errors
Giovanni wrote:Could you try to change line 1006?Code: Select all
otgp->oe[0].DOEPTSIZ = DOEPTSIZ_STUPCNT(3);
Set the value to 1 then try to just set the register to zero, I suspect there is another cause for this.
Another test, could you try to remove just that assertion?
Giovanni
Very quick testing reveals:
otgp->oe[0].DOEPTSIZ = DOEPTSIZ_STUPCNT(1); -> still same error
otgp->oe[0].DOEPTSIZ = 0 -> still same error
Removing DebugAssert, while otgp->oe[0].DOEPTSIZ = DOEPTSIZ_STUPCNT(3); -> no assert hit, seems to work
Removing DebugAssert, while otgp->oe[0].DOEPTSIZ = DOEPTSIZ_STUPCNT(1); -> no assert hit, seems to work
Removing DebugAssert, while otgp->oe[0].DOEPTSIZ = 0; -> no assert hit, seems to work
Take these results with some caution as i didn't fully test the usb functionality but only checked, if the device is able to enumerate and continuing to operate properly.
Cheers
Vinz
Re: STM32L476 USB HAL errors
I am ready to check everything on my system, how can I get mentioned files?
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: STM32L476 USB HAL errors
Do you have a subversion client? if not I suggest "Tortoise SVN" for windows or "Rabbit CVS" for Linux, both very easy to use and integrated with the desktop environment. Rabbit CVS also handles git.
You need to checkout: https://svn.code.sf.net/p/chibios/svn/trunk
When we do changes that is the repository immediately updated.
Giovanni
You need to checkout: https://svn.code.sf.net/p/chibios/svn/trunk
When we do changes that is the repository immediately updated.
Giovanni
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: STM32L476 USB HAL errors
Based on Vinz observations I committed another change in trunk. Apparently it works here but need confirmation from multiple parts, this problem is really tricky.
This is what I understood about this:
There are DATA_COMP words in the RX FIFO before and/or after SETUP_COMP, those DATA_COMP events have all data size are zero. So one of the following:
1) The L4 OTG injects spurious DATA_COMP words.
or
2) The host for some reason sends zero size packets and the L4 OTG does not filter them unlike the other STM32s.
I think it is 1) but without an HW protocol analyzer I cannot tell for sure, the effect is the same, now the low level driver does some filtering on the L4.
Giovanni
This is what I understood about this:
There are DATA_COMP words in the RX FIFO before and/or after SETUP_COMP, those DATA_COMP events have all data size are zero. So one of the following:
1) The L4 OTG injects spurious DATA_COMP words.
or
2) The host for some reason sends zero size packets and the L4 OTG does not filter them unlike the other STM32s.
I think it is 1) but without an HW protocol analyzer I cannot tell for sure, the effect is the same, now the low level driver does some filtering on the L4.
Giovanni
Re: STM32L476 USB HAL errors
I checked out the trunk and replaced next files in my project:
I have hardware USB sniffer; halt occurs after Setup packet "A1 21 00 00 00 00 07 00". The packet is acknowledged, but because of halt it is not replied.
- hal_usb.h
hal_usb.c
hal_usb_cdc.h
hal_usb_lld.h
hal_usb_lld.c
stm32_otg.h
I have hardware USB sniffer; halt occurs after Setup packet "A1 21 00 00 00 00 07 00". The packet is acknowledged, but because of halt it is not replied.
Who is online
Users browsing this forum: No registered users and 13 guests