-
Notifications
You must be signed in to change notification settings - Fork 96
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
issue with UOWN bit #23
Comments
Interesting. Yeah, they have lots of chips that have the "same" interface, but have all these quirky things that are different between them. Much like this one. Have a look at caeab53 :) |
Hey thanks for this report. This will no doubt save me some time at some point. Are you using M-Stack for another project? |
Ha! That's rich... it looks like you had to do it the other way around for the J50! Leave it to microchip! I haven't used M-Stack yet in any projects. I've just followed your work as it seems so much cleaner than the MLA versions. Thanks. |
I've been using the 18F2x/4xK50 for some USB projects lately, and recently ran across an issue you might want to be aware of.
Once in a while the device would just stop responding to host requests (I was using CDC at the time, and a different USB stack). Poking around I found that the K50 was sending a STALL response to the host DATA_IN packet, and everything just stopped.
Reading through the K50 datasheet there's a note that caught my eye:
I haven't seen that note in previous datasheets, but it's also in other recent ones like the 16F1xxxx w/USB.
The old MLA stack doesn't follow the note's recommendations. Looking at newer versions of the mchip code I see they've changed it to meet the above (quite a while ago, actually).
I made that change to my stack code and bingo, things started working like normal. Don't know if it effects other chips or not, but the newer mchip code changed it for all chips as I recall.
The text was updated successfully, but these errors were encountered: