nrf5x: fix hfclk_running() for nrfx v2.0.0#3766
Conversation
Hardware-in-the-loop (HIL) Test Reporthfp.json✅ 52 passed · ❌ 0 failed · ⚪ 0 skipped · blank not run
tinyusb.json✅ 311 passed · ❌ 28 failed · ⚪ 11 skipped · blank not run
|
|
|
This adds only an Which also means CI here doesn't exercise it. Verified by building CircuitPython's nRF52840 boards (nrfx v2.0.0), which don't compile without it. |
There was a problem hiding this comment.
Pull request overview
This PR fixes hfclk_running() in the Nordic nrf5x device controller (dcd_nrf5x.c) to compile with nrfx v2.0.0 (MDK 8.29.0) by avoiding APIs that were only introduced in nrfx v2.1.0.
Changes:
- Add an explicit
CFG_TUD_NRF_NRFX_VERSION == 2code path forhfclk_running(). - Use
nrf_clock_hf_is_running()for the v2 tier to maintain compatibility with nrfx 2.0.0.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
nrf_clock_is_running() was added in nrfx 2.1.0 (MDK 8.30.2), but the version autodetect puts 2.0.0 (MDK 8.29.0) in the v2 bucket, so hfclk_running() fails to compile on that nrfx. Route v2 through nrf_clock_hf_is_running(), which all of 2.x provides. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
e27b69c to
72e14c7
Compare
fcd5a0603 -> 5453ed09f. Picks up hathach/tinyusb#3766, which adds an nrfx v2.0.0 path to hfclk_running() in dcd_nrf5x.c; without it the nordic port does not compile, since CircuitPython pins nrfx v2.0.0 (MDK 8.29.0) and tinyusb's v2 path called nrf_clock_is_running(), added in nrfx 2.1.0. Only other change in the range is a docs line in AGENTS.md. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
I am re-org the hil pool, it will be a bit up and down with random failure for a while until my new pcie usb card + splitter arrived |
|
@hathach - Thx for the confirmation. I figured all the HIL testing is newly added. Glad to see it getting implemented. |
TinyUSB has been doing HIL for a couple of years, and go through a few hardware iteration (old pc, new usb card, new organizer/divider and mostly cable management). I would take a pix later when it looks more oragnized :). The pools increased one by one when I got more spare dev kits. There is several device and host tests already. But I tried to more upgrade to get more coverage since there is lots of LLM code nowsaday and they always sound very reasonable on reading, but could have side-effect and corrupt/cause more race. So it is best to verify with real hardware :). PS: previously it ran as batch job, but I found that having the test result in comment make it easier to monitor/maintain. The downside is there is lots of bot reviewer and pr comments atm. I may try to make them less annoyning later. |
|
That is really interesting. I'm curious to see how the current setup looks. I had thought this was Scott's ESP32-P4 PHIL board being implemented. |
|
it is nothing fancy, just an old dev PC with bunch of (unusded/available) dev boards. The cable management is a mess though. I used this breakout hub since type A head are too big and bulky plus it is 7-port hub, which reduce the number of hub level for larger pool. The complete list can be found in test/hil/tinyusb.json and hfp.json (separated rig from @HiFiPhile VM) 
|
|
Thx. I see how this works. I'm surprised you used a hub without uhubctl for hard power-cycle capability to each board. |
uhubctl support too few hubs or they are too expensive. Apart from some J-Link OB glitch it's rare that a power cycle is needed. My hub with soldered cables for space saving: |
|
my messy setup, there are currently 5 boxes, each has 2x7-hubs which have ~7 boards (each boards has its own flasher/debugger). each leaf hub is connected to 1 of 4 rootport of pcie renesas card (which is ppps). For board with host stack, there is a 4-port hub connected to the DUT with an msc + cdc (cp210x,ftdi,ch34x) with tx <-> rx for testing. 
|
|
Oh, this is a cool rig. I understand now why the independent USB root ports are important with the PCIe setup you are using. As well as the hubs for storage / serial. Inspired by your setup I started putting together my own mini HIL wall mount rig. See lightblue Skadis board in background. I'd like to verify PRs before pulling them out of draft to not waste anyones time. I'm using a mix of JTAG hardware (stlink, pico debug, jlink mini) on the major archs only RP2, nRF52840, M4, ESP32-S3. I should be able to get PPPS control with this $50 RSHTECH 10-port with maybe a little scripting work around. I expect have something more interesting to show next week. 
|
|
that is a nice hub, my ci rig is a VM with passthrough pcie usb card. The hil test abuse the usb bus enough It can hangs usb controller and have kernel into D-state several time a day. an pice card make it easier to unbind/rebind, or jsut reboot VM. there is a test script https://github.com/hathach/tinyusb/blob/master/test/hil/hil_test.py which take config json typically https://github.com/hathach/tinyusb/blob/master/test/hil/tinyusb.json and flash all example binaries and do check of msc and its contents, cdc (echo) etc.. if you are interested. |
|
Thanks the hil_test and json config are helpful reference. I put together my own per board probe pattern yesterday setting up OpenOCD. I'll see how far I get with uhubctl today. Waiting on more parts.... |
|
feel free to @ me if you need any helps. I have struggled with this for some time :) |
|
Thanks I appreciate the help. Honestly, since the moment I've hooked up the dedicated hardware I've been using it non-stop. Invaluable. |
|
I think I'm gonna buy one of this during my summer holiday, a card with PLX switch + 4*uPD720201 controller: |
|
Looks like a nice card and only ~$35 USD? I asked Limor about writing a guide based on the wall mount Skadis HIL Farm I started scrapping together. It won't be as capable, but also can work with almost any Host OS setup. 
|
They have several variants, this one is about $60 on taobao. The max version has 32 ports 🤣 |
|
nice card, but rather expensive though. I already go with the splitter and the cheaper uPD 4-port sibling (on order). Would consider this if found it earlier since this would sit nicely in the rig case. I guess I just have more boxes and put these card into one outside of the main rig. There is tons of boxes of boards anyway PS: @mikeysklar is your 10-port hub a single hub with 10 ports or 7 + 4, or 3x4. If they are the later, you would want to put the debugger/probe on the leaf hub since they don't change. 
|
|
I see uhubctl supports the Renesas uPD720202, but you have the uPD720201 (one version earlier) which is not listed. The 10-port hub I'm using RSH-ST10C-6 is confirmed as 9 out of 10 ports working with uhubctl (by others). They are chained 4->4->4 so I'll need to do my own scripting to determine the virtual port to physical port mapping. pt approved the Skadis HIL Farm guide so I'm printing out mounting hardware. More to come. What is the best way to reach you? I don't see you on discord or have your adafruit e-mail. |
|
Seems my HIL VM with FL1100 card is glitchy |
yeah, the new usbtest/testusb https://docs.tinyusb.org/en/latest/examples/device/usbtest.html is a really stresstest on both firmware and controller. It is kernel level test, kernel will spam controller with tons lots of URBs then cancel mid-flight, stall mid-flight, send random control etc... I throw away 4 x moschip card since it failed 2 of the tests due to silicon issue with frame index. Moschip is pure EHCI, I was trying to to get pass 32 device per xHCI renesas card. For renesas card, it needs to use latest firmware else It will also got "HC dead" https://github.com/hathach/tinyusb/blob/master/test/hil/hil_test.py#L171. FL1100 does not seems to have loadable firmware (ROM only) to fix any silicon issue. Have you tried to unplug the jlink on the lpc43, only that got the issue. The hil run does 30/30 on all board in initial test. Due to command spamming from kernel, Renesas card can only carry 4 (USBTEST_PARALLEL) usbtest concurrently else its command buffer will overflow and got wedged as well. Maybe FL1100 have a shorter buffer, we can test with USBTEST_PARALLEL=1. PS: @HiFiPhile now I also want to buy your card as well, that is all-in-one 360 cny card with pcie switch + 4 cards and only 1 power cable is super nice. I wish I know this sooner. Probalby just stack the on-order spliter + card in a drawer 🤣
uPD720201/2 are the same controller, 01 has 4 root port, 02 only has 2. Same 5 Gb up link. 01 is used when you want max speed on every ports.
all ppps is super nice, easier to have per-board recovery 👍
I have a discord but not use that much, I think I register with personal emmail. Let me try to change that, you can reach me with thach@adafruit.com or thach@tinyusb.org |
|
Yesterday I've soldered another Ch334x hub to separate target and flasher ports, the result is not good at all, even on manual run without usbtest it fails randomly. It seems something is off, I've a uPD720201 in my PC, will try to swap in to see if it helps. |
|
You may want to use the latest firmware for renesas card. Let me try to replicate my driver setting on your rig |
hfclk_running()doesn't compile against nrfx v2.0.0 (MDK 8.29.0):nrf_clock_is_running()was added in nrfx 2.1.0 (MDK 8.30.2):53) puts MDK 8.29.0 in the v2 bucket, which calls itCFG_TUD_NRF_NRFX_VERSION=1doesn't help: v1'snrf_clock_hf_is_running()takes 1 arg, v2.0.0's takes 2Fix: route v2 through
nrf_clock_hf_is_running(), present in all of 2.x.The other two v1-gated sites (
nrf_clock_event_clear,nrf_clock_task_trigger) already use v2.0.0-compatible signatures — this is the only broken call.Verified on nRF52840 (CircuitPython pins nrfx v2.0.0). Blocks adafruit/circuitpython#11093.
Note: I checked 2.0.0 and 2.1.0, not every 2.x in between. If you'd rather be exact, gate on
MDK_VERSION < 83002instead of the whole v2 tier.