Hi all,
I’m bringing up a custom anchor board around the QM35825 and I’m stuck at a point where I think I need someone from Qorvo to look at it. Two boards, same behaviour, and I’ve run out of things to change on the hardware side. Here’s what I have.
The board
QM35825SR (SiP) on our own PCB. Host is an ESP32-S3 on HSSPI0 at 8 MHz through TXU0304 level shifters, VDDIO at 1.8 V, SS_IRQ wired, SS_RDY polled. Rails: VDD1/VDD3/VDD4/VDD5 = 1.8 V, VDD2 = 3.3 V, RRVDD tied to the VDDIO node, decoupling per Fig. 27 of the datasheet. 38.4 MHz TCXO into XTI, and the PLL lock test passes on channels 5 and 9. Chip antennas on ports 2 and 3, ports 1 and 4 terminated. There is no external Secure Element; GPIO4–7 (SPI3), GPIO15 (SE_WAKEUP) and GPIO16 are left unconnected.
The parts came up in the boot ROM with 0xF100020B (CERT_KEY_PUBLIC_KEY_INVALID), so I loaded Binaries/QM358xx/qm35825.bin from SDK 3.0.0 through the ROM protocol (SHA-256 57405519…c69938, package version QMV=13.1.0rc5_10711510941). The ROM accepted it, LOAD_FW_PKG_VERIFIED_IMGS_COMPLETED, and the chip boots into UCI afterwards.
GET_DEVICE_INFO says: fw 13.1.0 rc5, build-id 9D AF 74 7E 02 00 00 00, UCI/MAC/PHY 3.0.0, device-id 0xDECA0440, flavor “silver_lychee”, product-id 0xBA43BA25, SOI variant 1, ROM code v41217. ROM GET_SOC_INFO says: chip rev A1, device version 0x0440, LCS 2 (USER), working_model 1, business_ctx 14, customer-id 0, product-id 0, secure_debug 0, secure_boot_oem 0, sec_ver 0/0. Both boards report exactly the same.
What happens
After every hardware reset I get BOOT_NTF, DEVICE_STATUS READY, CORE_DEVICE_RESET OK, GET_DEVICE_INFO OK, and then CORE_DEVICE_STATUS_NTF 0xFF (ERROR) at +4.58 s on board 1 and +4.47 s on board 2. Every single time. A UCI CORE_DEVICE_RESET gets it back to READY and commands work again, but nothing on the radio completes: TEST_PERIODIC_TX goes ACTIVE and never sends a notification. QORVO_TEST_RTC (2B 04 00 02 E8 03) always comes back NTF 01 01 01 03, which I read as RTC_PROG_ERROR.
Power stats just before the ERROR show uptime 1.6 s with idle/tx/rx/wakeup counters all zero, and over a longer run the uptime counter runs 1.6 % (board 1) and 4.5 % (board 2) slow against the host clock, so the firmware is timing itself from an untrimmed RC source. The last QTRACE records before the ERROR are 0C 00 01 02 C0 E0 C0 FF 00 00 00 00 | 0C 00 01 00 60 00 1F FD 00 00 00 00 (trace id 0xFD1F0060), and that same record repeats afterwards.
Things that made no difference at all: host traffic (silent host vs a command every 0.4 s), LOW_POWER_MODE 0 or 1, holding WAKEUP high through boot, PmMinInactivityS4 (0xA9, reads 0, a write is rejected with status 05), RTC pins bare, with a crystal, or with an external 32.768 kHz CMOS clock driven into RTCI. CONFIG_MANAGER_LIST_KEYS returns 650 keys and none of them relate to clock source, SE or host interface.
Clock survey
I used the HW-test clock-out (OID 0x2D/0x2E, pin 0x21 EXTON) with the device in READY, QM358 clock ids:
| id | clock | on EXTON |
|---|---|---|
| 1 | LPOSC | 18.35 kHz square |
| 2 | RTC | flat (1.8 V with bare pins, 0 V with a crystal fitted) |
| 3 | RC32K | 0 V flat |
| 4 | XTI | 38.4 MHz |
| 5 | FOSC/4 | 22.74 MHz |
| – | output disabled | 1.8 V flat |
So the fast clocks and the LPOSC run and the output path works, but neither the RTC nor the RC32K source ever toggles.
The 32 kHz crystal
This is where it gets odd. On board 1 I first had the schematic crystal with 4.7 MΩ feedback and 2 × 20 pF: both pins sat at a flat 0.5 V, dipping to 0 V through reset, with no start-up attempt. A second crystal, with and without the load caps, did the same. Driving a clean 32.768 kHz 0–1.8 V clock into RTCI (10 MΩ feedback, 1 pF on RTCO as the datasheet suggests) changed nothing either.
On board 2 I built the RTC section up one step at a time, always with 10 MΩ feedback:
| configuration | RTCI / RTCO DC | oscillation (scope on RTCO) | ERROR after reset | TEST_RTC | clock id 2 |
|---|---|---|---|---|---|
| nothing fitted | 0 V / 1.8 V | – | +4.47 s | 01 01 01 03 | 1.8 V flat |
| feedback resistor only | 0.6 V / 0.6 V | – | not run | – | – |
| ECS-.327-7-34R (7 pF, 50 kΩ ESR), no load caps | 0.6 V | yes – clean 32.7 kHz sinusoid | +4.47 s | 01 01 01 03 | 0 V flat |
| Seiko SC20S 12.5 pF + 2 × 10 pF | 0.6 V | no | +4.48 s | 01 01 01 03 | 0 V flat |
So the oscillator amplifier is powered and biases itself through the feedback resistor, but it has very little gain: only the 7 pF / low-ESR crystal with no load caps starts, the 12.5 pF part does not with 10 pF or 20 pF loads. And the part that really puzzles me: with the crystal visibly running on the scope, the firmware still says RTC_PROG_ERROR, clock id 2 stays flat, and the 4.5 s ERROR arrives on schedule. The chip is not using a clock that is present on its pins.
Two boards with identical OTP identity doing exactly the same thing makes me think this is about the firmware image or the provisioning of these parts rather than my board, but I can’t tell from the outside.
What I’d like to know
- Which post-boot check fires at ~4.5 s and raises DEVICE_STATE_ERROR, and what is trace id 0xFD1F0060? If the QTRACE string table / decoder for build 9D AF 74 7E 02 could be shared I could decode the whole boot trace myself.
- Is the SDK 3.0.0
qm35825.binthe right image for parts with OTP customer-id 0 / product-id 0, LCS USER, working_model 1, business_ctx 14? What do those fields mean, and do the DK-05 radio-board parts report the same? Is there any chance this lot wasn’t fully trimmed (RC32K / LPOSC / oscillator)? - What exactly does RTC_PROG_ERROR mean, and what does the firmware need before it will accept a running 32.768 kHz crystal (OTP field, UCI parameter, GPIO strap, SE presence)? And why would RC32K (id 3) be flat as well?
- Does fw 13.1.0rc5 need anything that only the DK-05 has, such as the external Secure Element on SPI3 / SE_WAKEUP, the ID EEPROM, or a defined level on GPIO16 (“reserved” in the datasheet, “interface selection” in the DK pin table)?
- Is the 32 kHz oscillator bias current configurable, and which crystal (CL, ESR) do you recommend for the QM35825 in production? The schematic 12.5 pF part clearly doesn’t work here.
- Side question: once a valid image is in NVM, how do I get back into the boot ROM from a non-Linux host? The CS-low-across-reset sequence from libqmrom / the Zephyr driver worked on the blank parts but on a programmed part I only get a 5-byte fragment and no CMD_MODE_READY.
I have full HSSPI/UCI logs for both boards (reset to ERROR, clock survey, ROM GET_SOC_INFO) and can post or send them. I’ve also got the Aliro SDK v1.1.0 qm35825.bin (QMV=1.0.0rc0) and can repeat everything under that image if it helps narrow it down. I’d buy a DK-05 for a side-by-side comparison, but distributors are quoting 27 weeks.
Any pointers appreciated, thanks.