atsamd usb serial not receiving characters until close

[jacobrosenthal]

I have a usb commit in #104 here for pygamer When you open the port with screen /dev/blah 115200 and type nothing is printed on screen and Ive checked and the characters arent even received. I thought it was maybe interrupts, but I implemented the polling to upper case echo example and it has the same behavior.

So maybe my implementation is broken, but wait I noticed as you close screen, the led example will trigger and In the case of the polling to upper case example when you reopen screen you'll see your previous chars printed to screen.

So the act of closing is triggering for some reason. I can't confirm on itsy but I presume its the same. So maybe its my setup for some reason. I checked with stm32-usb and a upper case polling bluepill example and can confirm those characters are echoed immediately using screen so its not my setup.

I have a feeling using the stty as given in directions in Itsy, opens and closes and is thus triggering a flush somehow and so this hasnt been noticed until now.

Im not yet familiar with the usb device implementation but I think it would lie in there somewhere. Any thoughts @sajattack ?

[twitchyliquid64]

Works fine on the itsybitsy_m4, I only implemented 2 weeks or so ago.

but wait I noticed as you close screen

... Laptop screen?

I have a feeling using the stty as given in directions in Itsy, opens and closes and is thus triggering a flush somehow and so this hasnt been noticed until now.

One thing that might be worth doing is setting up usbmon and having a look at the USB packets going to and from the device in the working / not-working scenarios.

[jacobrosenthal]

Can you confirm itsy works with screen, not stty

…

On Mon, Oct 21, 2019 at 12:41 AM Twitch ***@***.***> wrote: Works fine on the itsybitsy_m4, I only implemented 2 weeks or so ago. but wait I noticed as you close screen ... Laptop screen? I have a feeling using the stty as given in directions in Itsy, opens and closes and is thus triggering a flush somehow and so this hasnt been noticed until now. One thing that might be worth doing is setting up usbmon and having a look at the USB packets going to and from the device in the working / not-working scenarios. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#105?email_source=notifications&email_token=AADPI5BXNH4ZARK7GTEEWT3QPVMMJA5CNFSM4JCV4C3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBZLYEI#issuecomment-544390161>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADPI5ESFXR4OFCUDELCDKDQPVMMJANCNFSM4JCV4C3A> .

[twitchyliquid64]

Will do when I get back to my hotel room.

If stty works but not screen, I expect it's due to the CDC ACM driver rather than the peripheral driver. Either way I'll give it a go.

[twitchyliquid64]

I couldnt get it working at all with screen. I used minicom instead as that should work.

I used wireshark and the usbmon module to monitor the USB packets coming out of my device. This is my observations:

• Setting stty thingy then doing the echo thing causes the usb controller to set the line state before and after sending data (this is the scenario that communications work)
• minicom does not send any control packets except at the beginning
• Sending data packets only (ie: minicom) hangs interaction till a control packet is sent
• Hanging up or closing minicom causes the interactions to miraculously start working again (presumably because it results in a control packet being sent).

As such, I think the likely culprit is a code path expecting a control packet and not handling the received non-control packet until that happens.

[twitchyliquid64]

Either way, this is a valid bug somewhere in the stack (possibly in the usb-device crate, possibly in the peripheral driver, possibly in the usbd-serial crate).

I'll be able to better investigate when I get home (travelling atm), where I can get the UART out and start pumping debug messages.

cc @mvirkkunen - does usbd-serial work with minicom et al on the devices you tested?

[jacobrosenthal]

mentioned above, the stm32-usbd on a bluepill example does work as expected with screen so I dont think its in the upstream traits or on my system. I think its in the atsamd impl

…

On Mon, Oct 21, 2019 at 10:37 PM Twitch ***@***.***> wrote: Either way, this is a valid bug somewhere in the stack (possibly in the usb-device crate, possibly in the peripheral driver, possibly in the usbd-serial crate). I'll be able to better investigate when I get home (travelling atm), where I can get the UART out and start pumping debug messages. cc mvirkkunen@ - does usbd-serial work with minicom et al on the devices you tested? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#105?email_source=notifications&email_token=AADPI5FQHWIG6OICF3S6IYTQP2GRJA5CNFSM4JCV4C3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB4SWOA#issuecomment-544811832>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADPI5BHZUQ2U7RAWFWLJCTQP2GRJANCNFSM4JCV4C3A> .

[jacobrosenthal]

From @mvirkkunen on matrix

I haven't exactly tested on anything except one device but "picocom" works on Linux and I forgot which terminal I used on Windows but it worked

[jacobrosenthal]

Ive got my debugger up and working to look at this. Nothing obvious yet but Ive never dealt with usb.

it seems like trcpt1 isnt being called to trigger the poll when the char is received
instead when disconnect happens, usb_other triggers the poll, which triggers something internally to finally trigger trcpt1 to be hit, forcing another poll, which finally receives the character

[twitchyliquid64]

There may be a quirk / undocumented behaviour where certain endpoints or states need to be serviced first before other interrupts fire.

A few ideas:

• Maybe we still need to check each endpoint if we get a suspend or reset interrupt (ie: device doesnt send trcpt1 if there is already a different interrupt pending).
• Maybe we need to check endpoints before checking suspend / reset interrupts.

Apologies for not helping out here, I have lots of free time but am currently pseudo-homeless, so unable to access my gear.

[jacobrosenthal]

I dont think its poll ordering. I wired up the start of frame interrupt, which seems to get fired on probably on every packet including heartbeats or something, to the poll function, and with that hitting poll constantly the reads come through fine.

So the register is showing the buffer has data and clearing it fine. So it does seem that for some reason the trcpt0 (I said trcpt1 last time, I think I now understand that input is on channel 0) interrupt isnt firing to trigger the poll

I looked through svds and those seem correct around interrupts registers...

[twitchyliquid64]

I spent hours and couldn't figure out why the interrupt wasn't firing. Given I havent found any open-source implementation not using the SOF interrupt, ive just submitted a fix PR that uses SOF. Can confirm it fixes our issues.

[jacobrosenthal]

Ive come to the same conclusion on suspend/resume

The fact is this chip does reset/suspend/resume and more for you. We could presumably be doing more low power stuff, but were not anyway.

Ive spent time rewriting but I still havent gotten the mix of flags. I THINK you need enable the wakeup interrupt when you suspend? But Ive found that damn bit set constantly and havent been able to then distinguish from suspend and not awake and suspend and awake. Would we need a local static variable?

The question comes down to does usb-device heavily profit from suspend/resume notifications? I dont know...

And yeah for interrupt. Ive spend days now. I just dont see anything in other implementations either

Maybe Ill try to disable sof in the arduino and see if it still works?