-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
System gets stuck in hot interrupt loop from USB ERR interrupt #190
Comments
@mhmayyan if you're able to apply the changes from branch https://github.com/mcci-catena/Arduino_Core_STM32/tree/issue190, it should solve the problem. If you have an OTII, it would be good to compare power between a "good board" and a "bad board" -- I suspect a "good board" goes into USB suspend and drops power. So we may need a more elaborate fix, but at least this will show if we're going in the right direction. If using a debug BSP is too much of a pain, I'll make a pre-release, so you can download via the IDE. |
Thank you @terrillmoore. Yes, this fix solved the problem. I used a DMM (set as an ammeter) to check the amps drainage of four Catena 4612 boards (two good and two bad ones). They all drain almost the same. |
Thanks for testing @mhmayyan! I'll get a patch release out shortly. |
I've made the release. The fix is in v3.0.5, which is available in the Arduino Boards Manager. |
Some units (Catena 4612 specifically) seem to have problems if USB is enabled but no cable is connected. Specifically, they lock up.
Investigation by @mhmayyan in #189 show that there is an issue with the handling of the
ERR
interrupt. This is always enabled when USB is enabled, but it appears to get stuck sometimes if the USB hardware shows a single-ended 1 (DP and DM both 1). The ISR software dismisses theERR
request, but makes no attempt to mask the interrupt; the interrupt is immediately presented again; so the BSP gets caught in a hot interrupt loop until the condition goes away.The appearance of this condition appears to be chip-specific and possibly board specific -- we've not seen it on the 4610 or 4630; we see it frequently on the 4612 and 4618, possibly due to layout artifacts, or bad luck on a lot of stm32 chips that are more prone to this due to leakage currents.
However, it's easy to fix. We don't use the
ERR
interrupt and it can be always masked. Even manually masking on a board particularly prone to this fixed the problem:Originally posted by @mhmayyan in #189 (comment)
A full log of the debug process is in the comments for #189.
The text was updated successfully, but these errors were encountered: