2 Commits

Include renames

Author	SHA1	Message	Date
3 people	e951b4fe60	test: pin the CAD commands and LR20x0Interface's busy check against a… (#12036) ... * test: pin the CAD commands and LR20x0Interface's busy check against a modelled chip The LR2021 refuses SetLoraCadParams exit mode 0x02, the value of RadioLib's RADIOLIB_LR2021_CAD_EXIT_MODE_RX, with CMD_PERR (-706), and LR20x0Interface::isChannelActive() reads the error as a free channel: on the bench the node transmitted over live frames (16/16), and a Mesh-Tracker X1 gave no busy verdict in 539 scans. RecordingHal gains deferred replies N transactions out (the IRQ status read has no opcode), a rejectUnless() chip model, and an IRQ pin that reads high so scanChannel() returns. lr2021_tests.h and lr11x0_tests.h pin the CAD command bytes, the exit-mode defines, and that a refused command returns an error and starts no CAD. lr20x0_interface_tests.h runs the real isChannelActive() against the modelled chip: a detected preamble must read busy, and sending 0x02 fails both of those tests (checked by mutating LR20x0Interface.cpp). * test: bring RecordingHal and suite-order comments in line with the code digitalRead() also models the IRQ line now, a deferred reply has a stated precedence when two come due on one transaction, and the LR20x0Interface set runs after the LR2021 set for the same DC-DC reason. * test: three small corrections to the CAD test comments and macros The RADIO macros still passed `true` for reply()'s fourth argument, which this branch turned from a bool into `uint8_t after`, a count of transactions to defer by. It converts to 1, so nothing changed, but 1 and 2 now mean different things - lr2021AnswerIrq() passes 2 - so the call sites should not read as a bool. The comments described the refused exit byte as something develop does. It does not: develop's isChannelActive() sends 0x01 from its own local CAD_EXIT_MODE_RX, and these tests are what keep it there. Reworded in test_main.cpp, lr2021_tests.h and lr20x0_interface_tests.h so a later reader does not go looking for a live bug. test_lr2021_cad_irq_routed_to_dio's comment claimed DIO5 is "the line the interface's ISR watches". 5 is LR2021::irqDioNum's in-class default in RadioLib; the firmware assigns irqDioNum in LR20x0Interface::init() from LR2021_IRQ_DIO_NUM, IRQ_DIO_NUM or portduino_config.irq_dio_num, and falls back to RadioLib's default only when the variant defines neither. The assertion is worth keeping - it just pins RadioLib's default rather than the firmware's choice. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011C7D9biGfpxLruq7DFLzsP --------- Co-authored-by: Jonathan Bennett <jbennett@incomsystems.biz> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>	2026-11-02 21:52:34 +00:00
Tom	7fe3176a40	Radiolib recording hal tests (#11997) ... * test: exercise RadioLib's drivers through a recording HAL, pinned to RadioLib 7.8.0 test_radiolib_drivers drives the RadioLib calls Meshtastic's radio interfaces make against RecordingHal, which logs every SPI transaction and answers with a success status, a few scripted replies (the packet type the LoRa setters check) and, for SX127x, a register file. One set per chip family - SX126x, SX127x, SX128x, LR11x0, LR2021 - each ending in a list of the reply-dependent tests still to write. SX126x and SX128x get the SPI framing their begin() would set. RadioLib is pinned to 7.8.0 to show the failure: the LR2021 DC-DC workaround (jgromes/RadioLib#1864) passes sizeof(uint32_t) as a word count, and under [env:coverage] ASan aborts the LR2021 set with a stack-buffer-overflow in readRegMem32. The other four sets pass. * test: pin RadioLib to the DC-DC word-count fix NomDeTom/radiolib@3509dbc8e (branch lr2021-dcdc-regmem32-len, on RadioLib master after 7.8.0) passes 1 as the word count at the three DC-DC workaround call sites. The overrun is gone and the LR2021 set runs to completion. test_lr2021_dcdc_freq_lf_write_sends_one_word still fails, on a second RadioLib bug: LRxxxx::writeCommon() sends 4 + 4*len bytes whatever the address width, so every LR2021 WriteRegMem32 (24-bit address) carries one uninitialised trailing byte - 10 bytes where 9 are meant. * test: keep RecordingHal reachable across a failed assertion A failed TEST_ASSERT longjmps out of the test, skipping destructors, so each test's local RecordingHal leaked its transaction log. LeakSanitizer then reported it at exit, and under [env:coverage] a plain assertion failure came out as an ERRORED suite (run 36412456860: 26 Tests 1 Failures, then a 384-byte leak from RecordingHal::spiTransfer). One static HAL, reset at the start of each test, stays reachable, so a failure reports as FAILED. * test: run the RadioLib driver suite against develop's RadioLib pin Revert the pin to develop's 510e00cfb (RadioLib 7.7.1). That RadioLib predates the LR2021 DC-DC workaround, so its three tests would only fail on their own premise there. They now register only when LR2021 has the public setRegulatorDCDC() that jgromes/RadioLib#1864 added with the workaround: any RadioLib carrying it runs them, and none is left ignored. Against 7.8.0 the suite shows the DC-DC overrun (ASan, run 36412379592). Against the DC-DC fix (NomDeTom/radiolib@3509dbc8e) it shows a second bug: every LR2021 WriteRegMem32 sends one byte too many, since LRxxxx::writeCommon() still sizes the frame for a 4-byte address after jgromes/RadioLib@e3af85867 made it 3 on the LR2021 (run 36412456860). Neither is reachable at this pin. * test: pin the coding-rate byte the radio interfaces send LR11x0Interface, LR20x0Interface and SX128xInterface all call setCodingRate(cr, cr != 7), so 4/5 goes out with the long interleaver. The modulation tests used the driver default (short), and only counted frames. Pass the flag the firmware passes, and add a test per chip that reads the coding-rate field back from the last modulation-params frame: 5 for 4/5 long, 3 for 4/7 short (RadioLib 7.7.1's encoding). Also correct test_main.cpp: at the 7.7.1 pin the LR2021 DC-DC tests are not registered, so the set does not fail; the 7.8.0 overrun is now stated as conditional on a RadioLib that carries it.	2026-09-30 12:09:08 +00:00