RM530N-GL stuck with malformed single-interface descriptor (2c7c:0801) — need EDL / USB_BOOT test point location

IoT Modules 5G Module
1

Hi all, hoping a staff member or someone who has been through this can help.

My RM530N-GL (bcdDevice 0x0504, serial F3BB729E) appears to have corrupted firmware. The device enumerates over USB but exposes only a single malformed interface — no AT / DIAG / NMEA / QMI ports on any host OS. I have the replacement firmware package (RM530NGLAAR05A01M4G_01.201.01.201) already, but I cannot flash it because I cannot reach EDL mode (05c6:9008) by any software path.

I need to force EDL by shorting USB_BOOT to VDD_EXT before power-on, as Quectel staff have explained in other threads. What I cannot find publicly documented is which PCB test point on the back of the RM530N-GL is USB_BOOT, and which point is VDD_EXT.

Current USB state (identical on Linux, macOS, Windows 11)

  • idVendor = 0x2C7C, idProduct = 0x0801, bcdDevice = 0x0504
  • bNumInterfaces = 1
  • Only Interface 1 exists — no Interface 0. Linux kernel rejects the layout:
usb 3-3: config 1 has an invalid interface number: 1 but max is 0
usb 3-3: config 1 has no interface number 0
  • That single interface is vendor-class (bInterfaceClass = 0xFF, bInterfaceSubClass = 0x00, bInterfaceProtocol = 0x40), with three endpoints: interrupt IN (0x82, 10 bytes), bulk IN (0x81, 512), bulk OUT (0x01, 512).
  • Embedded inside are CDC functional descriptors (Header 0x0110, Call Mgmt, ACM caps=0x02, Union), but the interface class is vendor rather than CDC, so no standard host driver binds.
  • Windows Device Manager reports Problem Code 28 (CM_PROB_FAILED_INSTALL) for this device across driver installs (Quectel LTE&5G driver, generic USB Serial, force-installed).

What I’ve already tried

Software methods (all failed):

  • CDC control transfers — SET_LINE_CODING (115200 8N1), SET_CONTROL_LINE_STATE (DTR+RTS) — both return OK.
  • 12 vendor control transfers (bReq 0x70, 0x70 v=1, 0x78, 0xFE, 0xFF, 0x41/0x70 @iface1, 0xE1, 0x74, 0x0F, 0x24, 0x23/SEND_BREAK, 0x42) — all return STALL (LIBUSB_ERROR_PIPE).
  • Bulk OUT writes: AT, ATI, AT+QCFG=?, AT+QDOWNLOAD=1, Sahara HELLO_RESP, HDLC-framed DIAG version request (0x00 0x7E), Firehose NOP XML. Every bulk IN read times out with zero bytes. The device never transmits anything back, regardless of payload.

So the firmware stub accepts USB enumeration and CDC control, but has no AT parser, DIAG framer, Sahara responder, or Firehose handler. Software-triggered EDL is not reachable from this state.

Hardware methods (attempted):

  • Exposed all large copper pads on the back of the M.2 card — these are RF shield GND pads (all at ground potential); shorting any pair of them has no effect.
  • Small test pads are present near the M.2 connector edge (left and right of the “M 2518” silkscreen), but without labelled silk or a public diagram, I cannot identify which is USB_BOOT and which is VDD_EXT without risking damage.

Hardware setup

  • Module: RM530N-GL, bcdDevice 0x0504
  • Carrier: Waveshare M.2 to USB 3.2 Gen1 adapter (passive, no active chips — USB signals pass straight from M.2 B-key pins to USB-A)
  • Host: Linux (Alpine 3.23 aarch64, kernel 6.18.22) on a UTM QEMU VM with xHCI USB 3.0 passthrough; independently reproduced on bare-metal macOS 26 and Windows 11 ARM64
  • QFirehose compiled from the ROOter source package (OpenWrt feed), ready on Linux host
  • Firmware package RM530NGLAAR05A01M4G_01.201.01.201 unpacked, update/firehose/prog_firehose_lite.elf and rawprogram_nand_p4K_b256K_update.xml ready

What I’m asking for

  1. The exact location of the USB_BOOT test point on the RM530N-GL PCB — ideally a photo of the back of the card with the pad marked, or a silkscreen label to look for. bcdDevice 0x0504 in case there are multiple board revisions.
  2. Confirmation of the VDD_EXT rail — is it VDDIO_1V8 (M.2 pin 24), or a separate test pad on the card? Some staff replies describe it as “M.2 pin 24” but I’ve also seen “test pad on the back” in other threads.
  3. Any alternative method — for example a QCOM tool/command that could force EDL through the existing USB stub (given that CDC control is accepted), or a specific vendor request code that this firmware honours. The 12 I tried all STALL.
  4. If these details are handled FAE-direct rather than on the forum, I am already in an active email thread with Quectel support for the firmware package — happy to continue there if a staff member can escalate.

Thanks in advance to anyone who has successfully recovered a module from this state, or staff who can point me at the right test pad.

- Massimo

2

Dear @Auxaldeus
I have sent to you via Message, please check.