Thanks for being a part of WWDC25!

How did we do? We’d love to know your thoughts on this year’s conference. Take the survey here

Custom ethernet device does not reconnect on M4 iPad Pro

We are experiencing problems with the USB port on iPad Pro 11 inch (M4) model number MVW13NF/A. Our custom peripheral device (based on Raspberry Pi Pico + tinyUSB stack, is configured as a network adapter class and has communication with our App over UDP protocol. Our device also acts as a DHCP server, providing the IP address for iPad.

The problem can be described as a “bus stall” or "bus hold" after sleep mode. To reproduce it we just send the iPad into sleep mode using a power button, the USB bus on M4 goes to the suspended state and won’t resume anymore when we wake the iPad up.

The problem has occurred since the upgrade to iOS 18.2.1 and has not been observed before on the previously installed iOS 17 on the same iPad Pro M4.

Also, the problem does not happen on the iPad Pro 11 inch (3rd gen with M1) model number MHW73FD/A, with the same iOS 18.2.1 installed. The problem also does not arise, if we connect our device via USB hub to the same iPad Pro M4.

We have tested different versions of tinyUSB stack (either included in RPi Pico SDK or native unpatched). The problem is independent of the library version. It occurs always if our device is connected directly to the USB port of iPad Pro (M4) with iOS 18. It also stays after upgrading to the latest iOS 18.3 (beta)

In the attached logs is (reduced for clarity) debug output from tinyUSB library about events on the USB bus. These logs were captured via RTT debugging output, using Segger J-Link debugger, so logging process does not affect the timings on the USB bus.

There are three logs attached, for cases 1: "iPad Pro M4 + iOS18" (i.e. problematic case), 2: "iPad Pro M1 + iOS18", and 3: "iPad Pro M4 + iOS18 + external USB hub" (they are non-problematic cases).

This was already posted as feedback with id FB16366509

This was already posted as feedback with id FB16366509

Thank you, that's the most important step with something like this. Poking at a few details from you description:

The problem also does not arise, if we connect our device via USB hub to the same iPad Pro M4.

Is the USB hub powered? If the hub is providing power, then that ends up creating an entirely different scenario, as the device is going to keep the USB bus relatively "active" so that it can continue to pull power.

The problem can be described as a “bus stall” or "bus hold" after sleep mode. To reproduce it we just send the iPad into sleep mode using a power button, the USB bus on M4 goes to the suspended state and won’t resume anymore when we wake the iPad up.

I haven't dug into the logs, but are you seeing any activity on the bus when the iPad wakes up again? Similarly, did the working device fully power down the bus durring sleep?

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

No we did not. You can find the latest activity reported in the logs in the case1_usbd_log.txt after 5 seconds of sleep: USBD Suspend : Remote Wakeup = 0 BUS RESET USBD Bus Reset: Full Speed

Huh. Have you tried using a bus analyzer to compare the two cases, particularly the hub vs. no hub case?

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Have you tried using a bus analyzer

No, as we do not have access to one. We are considering getting the Cynthion USB Protocol Analyzer. Do you think it does the job?

Have you tried using a bus analyzer

I received the analyzer today and was able to capture the packets on the USB bus. The M4 iPad Pro shows, that after some time, when the iPad is sleeping only malformed packets with the content FF are sent. See attached image. This situation does not recover after the iPad becomes awake.

A M1 iPad Pro on the other hand never sends malformed packets.

Custom ethernet device does not reconnect on M4 iPad Pro
 
 
Q