iPad pro becoming unresponsive

[rcdsystems]

I have a couple of iPads with USB-C ports (2nd gen pro and mini). On both devices, I programmed the Flirc USB receiver so I could use a stereo remote to play/pause and skip songs on the iPad. It works fine, but after a few hours of not using the ipad at all the ipad becomes unresponsive. The touch controls will lag, apps won't launch, etc. The only solution I found was to reboot the ipad and then it works again until you let it sleep for a while and then the issue repeats itself. I've isolated the problem to the flirc receiver, since it happens on two different ipad models and it does not happen when the flirc receiver is not connected. Any ideas on how to solve this?

I'm using firmware 4.9.3

[jason]

What happens when you unplug it when it is in this state?

[rcdsystems]

It doesn't seem to help. Once it gets into the bad state it stays like that until you reboot, regardless if you unplugged the receiver or not.

[rcdsystems]

Since no remotes are actively sending commands to the receiver when this happens (in the middle of the night), I'm wondering if maybe there is some sort of "keep awake" feature that is causing the iPad to go into this state. Is there some setting that I can modify in the flirc config to validate this?

[rcdsystems]

Looking at the ipad logs, this does look suspicious (see text in bold):

Date/Time:        2022-08-21 08:57:49.762 -0600
End time:         2022-08-21 09:02:25.724 -0600
OS Version:       iPhone OS 15.6.1 (Build 19G82)
Architecture:     arm64e
Report Version:   35.1
Incident Identifier: 69EE6824-8C85-46ED-B9BF-2A55AD464A6C
Share With Devs:  Yes

Data Source:      Microstackshots
Shared Cache:     FA21C079-94F7-35A0-B38A-8B4CEF88650F slid base address 0x180538000, slide 0x538000

Command:          backboardd
Path:             /usr/libexec/backboardd
Architecture:     arm64e
Parent:           launchd [1]
PID:              66

Event:            wakeups
Action taken:     none
Wakeups:          45001 wakeups over the last 276 seconds (163 wakeups per second average), exceeding limit of 150 wakeups per second over 300 seconds
Wakeups limit:    45000
Limit duration:   300s
Wakeups caused:   45001
Wakeups duration: 276s
Duration:         275.96s
Duration Sampled: 274.89s
Steps:            318

Hardware model:   iPad14,1
Active cpus:      6
HW page size:     16384
VM page size:     16384

Advisory levels:  Battery -> 2, User -> 3, ThermalPressure -> 0, Combined -> 2
Free disk space:  110.13 GB/238.40 GB, low space threshold 150 MB

[jason]

Thanks for the log, that was helpful. Can you attach your config?

 

** EDIT ** - To clarify, the configuration from Flirc

[rcdsystems]

my_flirc_config.fcfg

[jason]

Can you disable the built in profiles. Fire up the GUI, go to advanced, and then disable all those profiles. Let me know if it's any better after that. 

Outside of that, if it doesn't work, can you clear the config, and just leave the flirc in there, and see if it happens again? I know that seems silly, but it would tell me if it's something wrong with my USB stack, rather than the usb submission of codes (because nothing would ever be received/submitted).

Thank you. I'll see if I can reproduce locally. Is it in there with just an adapter, or a hub with other devices? A link to the adapter would be helpful.

[rcdsystems]

Hey Jason, really appreciate all the help here. I've disabled the profile and will leave it plugged in overnight to see if it happens again.

I was able to reproduce the issue with 2 different adapters:

https://www.apple.com/shop/product/MUF82AM/A/usb-c-digital-av-multiport-adapter

https://www.amazon.com/Anker-Upgraded-Delivery-Pixelbook-A83460A2/dp/B07ZVKTP53

Another data point to report is that I've tried leaving it plugged in the hub/adapter without the power supply. The next morning when I checked the iPad battery had been drained completely. This is perhaps another indication that the usb receiver prevents the ipad from sleeping. If I leave the usb-c power connected to the adaptor then it will eventually become unresponsive as described. 

 

[jason]

50 minutes ago, rcdsystems said:

Hey Jason, really appreciate all the help here. I've disabled the profile and will leave it plugged in overnight to see if it happens again.

I was able to reproduce the issue with 2 different adapters:

https://www.apple.com/shop/product/MUF82AM/A/usb-c-digital-av-multiport-adapter

https://www.amazon.com/Anker-Upgraded-Delivery-Pixelbook-A83460A2/dp/B07ZVKTP53

Another data point to report is that I've tried leaving it plugged in the hub/adapter without the power supply. The next morning when I checked the iPad battery had been drained completely. This is perhaps another indication that the usb receiver prevents the ipad from sleeping. If I leave the usb-c power connected to the adaptor then it will eventually become unresponsive as described. 

 

All really helpful clues, thank you. It's strange, because tens of thousands of users use flirc in pi's, and htpc's while in sleep, and allow the remote to wake up the PC. I would have a lot of complaints of users that can't get their devices to stay asleep. 

However, Apple's USB stack, and especially on their ipad is a different beast. I have not tested it, and that isn't to say there is something I'm missing. I'm thinking it's not so much with the device receiving a signal and waking up the ipad, but something in the USB response that reports a wake-up event.

I have one more idea. Do you have anything like this: https://www.amazon.com/Syntech-Adapter-Thunderbolt-Compatible-MacBook/dp/B07CVX3516/ref=sr_1_4?crid=18PWPIJS0D44O&keywords=USB+A+to+C&qid=1661473174&sprefix=usb+a+to+c%2Caps%2C155&sr=8-4

Something without a hub to rule that out?

Curious, how did you extract the log? 

[rcdsystems]

I do have one those. My guess is that it will drain the battery in the middle of the night, but I'll give a try and report back.

You can extract the log using Xcode. Go to Window -> Devices and Simulator, select you iPad that is plugged in via the usb cable and click the "View Device Logs"

[rcdsystems]

Ok, disabling the profiles didn't make a difference. iPad was still toast this morning. I've cleared all the configurations and will leave it plugged in to see what happens.

Haven't tried the dongle you suggested yet. That's next.

[rcdsystems]

Ok, cleared the config (and confirmed receiver was no longer responding to the remote) and it also didn't change anything. Next up is the test with a simple dongle and no power supply.

[rcdsystems]

ok, so even weirder results:

Using the simple dongle did not freeze the iPad. But using one of the hubs plus a power supply (without the receiver connected) doesn't freeze either. 

[rcdsystems]

ok, so I think I figured it out the issue. Since flirc behave as an usb keyboard, I've tried the same setup, but with an usb keyboard instead: usb-c hub + power adapter + external usb keyboard. After a couple of hours the iPad froze the same way as with the flirc receiver. So basically it's an Apple bug with external keyboards. Hopefully Apple will fix this in a future release.