Add Renode regression tests for the NUCLEO-F401RE target by fdesbiens · Pull Request #51 · eclipse-threadx/samplex

fdesbiens · 2026-08-31T15:32:01Z

Add Renode regression tests for the NUCLEO-F401RE target

Summary

The ARM target had no runtime test. Its CI job checked only that the ELF existed, so the clock configuration, the TIM2 HAL timebase, the console, and the heap bound were all unexercised. This brings it to parity with the PolarFire target, which already gates CI on a headless Renode run.

Follow-up to #50, which noted this gap under "Not addressed".

Renode platform

Renode ships no NUCLEO-F401RE board description, so renode/nucleo_f401re.repl derives one from the generic stm32f4.repl and corrects Flash to 512 KB and SRAM to 96 KB. The generic platform is sized for the larger F407/F429 parts, and both the linker script's heap reservation and the _sbrk() bound depend on those limits being accurate.

Startup self-tests

main.c gains seven self-tests that run before tx_kernel_enter(), so a failure is reported even when the scheduler never starts:

#	Self-test	Guards against
1	`_sbrk()` allocation lands inside the heap reservation	heap escaping its linker reservation
2	`_sbrk()` releases back to the heap base	broken negative-increment path
3	`_sbrk()` underflow rejected with `EINVAL`	shrinking below the heap base
4	`_sbrk()` rejects a request that fits SRAM but not the heap	bounding the heap at the end of SRAM
5	Heap reservation ends at or below the ThreadX byte pool	linker script layout regression
6	`SystemCoreClock` is 84 MHz	a silently wrong PLL configuration
7	HAL timebase (TIM2) tick advancing	`HAL_InitTick()` re-entry leaving TIM2 stopped

The regression guard, and what it revealed

Test 4 targets the heap bound fixed in #50. Requesting 32 KB fits inside the 96 KB SRAM but far exceeds the 512-byte heap reservation.

I verified the suite has teeth by reinstating the old end-of-SRAM bound and re-running it. It failed, and the failure was worse than expected: with that bound, newlib's firstmalloc() took roughly 4 KB and put the break at 0x20002170 — inside the ThreadX byte pool, which holds every thread stack and the queue buffer. That also broke self-tests 1 and 3, since the break had already escaped the reservation before they ran. The pre-#50 demo was therefore corrupting pool memory on every boot; it simply happened not to fault.

With the bound correct, _sbrk() refuses the oversized request, newlib retries smaller, and malloc(64) succeeds using 72 bytes of the 512-byte reservation. So the reservation is adequate as it stands and _Min_Heap_Size does not need raising.

Harness

scripts/test_renode.py drives nucleo_f401re_ci.resc, which advances a fixed span of virtual time and quits on its own rather than depending on wall clock. Beyond the self-tests it asserts the boot banner reached the console, that the blink thread and the 1 Hz application timer have both run (covering the LED path and the timer service), and that the mutex, queue, event-flag and semaphore counters are all non-zero.

renode/nucleo_f401re_demo.robot covers the same ground for renode-test, and nucleo_f401re_demo.resc is the interactive counterpart.

The new test-nucleo-renode CI job mirrors test-polarfire-renode, consuming the ELF artifact from build-arm-nucleo.

Verification

Locally, with Renode 1.16.1 and the CI-pinned Arm GNU Toolchain 14.2.Rel1:

All 7 self-tests pass; harness exits 0.
Reintroducing the heap-bound bug: 3 self-tests fail and the harness exits 1, so the gate genuinely gates.
Clean build, -Wall -Wshadow -Wdouble-promotion -Werror: 22068 B ROM (up from 20120 B for the self-tests), 6000 B RAM unchanged.

Also

main.c drops a hardcoded 0x20018000 in favour of BSP_RAM_END, now that board_config.h is in scope, and names the 4 KB main-stack margin. Same value, no behaviour change.

AI assistance disclosure

This work was AI-assisted by me (@fdesbiens). The self-tests live in main.c, whose header follows the project's existing MIT form; the AGENTS.md AI Disclosure headers added in #50 remain on the four BSP files that carry Codex-derived content.

The ARM target had no runtime test. Its CI job checked only that the ELF existed, so the clock configuration, the TIM2 HAL timebase, the console and the heap bound were all unexercised. This brings it to parity with the PolarFire target, which gates CI on a headless Renode run. Renode ships no NUCLEO-F401RE board description, so renode/nucleo_f401re.repl derives one from the generic STM32F4 CPU platform and corrects Flash to 512 KB and SRAM to 96 KB. The generic platform is sized for the larger F407/F429 parts, and both the linker script's heap reservation and the _sbrk() bound depend on those limits being right. main.c gains seven startup self-tests that run before tx_kernel_enter(), so a failure is reported even when the scheduler never starts. They cover the _sbrk() allocate, release, underflow and over-limit paths, the invariant that the heap reservation ends at or below the ThreadX byte pool, the 84 MHz SystemCoreClock, and that TIM2 still ticks after HAL_RCC_ClockConfig() re-enters HAL_InitTick(). Test 4 is the regression guard for the heap bound fixed in eclipse-threadx#50. Requesting 32 KB fits inside the 96 KB SRAM but far exceeds the heap reservation. Reinstating the old end-of-SRAM bound was verified to fail the suite: newlib's first malloc() then took roughly 4 KB and put the break at 0x20002170, inside the ThreadX byte pool, which also broke self-tests 1 and 3. With the bound correct, _sbrk() refuses the oversized request, newlib retries smaller, and malloc(64) succeeds using 72 bytes of the 512-byte reservation - so the reservation is adequate and no heap growth is needed. scripts/test_renode.py drives nucleo_f401re_ci.resc, which advances a fixed span of virtual time and quits on its own rather than depending on wall clock. Beyond the self-tests it asserts the boot banner, that the blink thread and the 1 Hz application timer have both run (covering the LED path and the timer service), and that the mutex, queue, event-flag and semaphore counters are all non-zero. The suite was confirmed to exit 1 on a reintroduced bug and 0 on the fixed tree. The Robot Framework suite covers the same ground for renode-test, and the new test-nucleo-renode CI job mirrors test-polarfire-renode. main.c also drops a hardcoded 0x20018000 in favour of BSP_RAM_END now that board_config.h is in scope, with the 4 KB main-stack margin named.

Two problems in the pipeline, one of them mine. The NUCLEO Renode job fetched renode-latest.linux-portable.tar.gz with no version pin and no checksum, while the PolarFire job three jobs above it already pinned Renode 1.16.1 and verified its SHA256. That pin landed in #49, so it was present in this file when #51 added the NUCLEO job; the new job was modelled on an older copy of the PolarFire step rather than the current one. The result was a suite whose emulator could change under it on any Renode release, with nothing verifying what was downloaded. The NUCLEO job now uses the same pinned, checksum-verified step as PolarFire. The checksum was recomputed from the published artefact rather than copied on trust. Separately, every run re-downloaded roughly a gigabyte: the xPack RISC-V toolchain at ~414 MB and Renode at ~52 MB in each of two jobs. All three are now restored by actions/cache, keyed on the pinned version so a future bump invalidates the cache instead of silently serving the old one. This completes what #53 started for the Arm toolchain. Caching only makes sense because these are now pinned. Caching an unpinned "latest" artefact would have frozen CI on whichever build happened to be fetched first, turning a reproducibility gap into an invisible one. All four jobs now follow the same shape: cache, install only on a cache miss, then put the tool on PATH as a separate step so it runs on hit and miss alike. The PolarFire job also gains a version-reporting step, matching the Arm job, so the log records which compiler produced the ELF. Verified both constructed download URLs resolve, and that the Renode 1.16.1 checksum matches the published artefact. Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-31T15:32:01Z

Add Renode regression tests for the NUCLEO-F401RE target

Summary

The ARM target had no runtime test. Its CI job checked only that the ELF existed, so the clock configuration, the TIM2 HAL timebase, the console, and the heap bound were all unexercised. This brings it to parity with the PolarFire target, which already gates CI on a headless Renode run.

Follow-up to #50, which noted this gap under "Not addressed".

Renode platform

Renode ships no NUCLEO-F401RE board description, so renode/nucleo_f401re.repl derives one from the generic stm32f4.repl and corrects Flash to 512 KB and SRAM to 96 KB. The generic platform is sized for the larger F407/F429 parts, and both the linker script's heap reservation and the _sbrk() bound depend on those limits being accurate.

Startup self-tests

main.c gains seven self-tests that run before tx_kernel_enter(), so a failure is reported even when the scheduler never starts:

#	Self-test	Guards against
1	`_sbrk()` allocation lands inside the heap reservation	heap escaping its linker reservation
2	`_sbrk()` releases back to the heap base	broken negative-increment path
3	`_sbrk()` underflow rejected with `EINVAL`	shrinking below the heap base
4	`_sbrk()` rejects a request that fits SRAM but not the heap	bounding the heap at the end of SRAM
5	Heap reservation ends at or below the ThreadX byte pool	linker script layout regression
6	`SystemCoreClock` is 84 MHz	a silently wrong PLL configuration
7	HAL timebase (TIM2) tick advancing	`HAL_InitTick()` re-entry leaving TIM2 stopped

The regression guard, and what it revealed

Test 4 targets the heap bound fixed in #50. Requesting 32 KB fits inside the 96 KB SRAM but far exceeds the 512-byte heap reservation.

I verified the suite has teeth by reinstating the old end-of-SRAM bound and re-running it. It failed, and the failure was worse than expected: with that bound, newlib's firstmalloc() took roughly 4 KB and put the break at 0x20002170 — inside the ThreadX byte pool, which holds every thread stack and the queue buffer. That also broke self-tests 1 and 3, since the break had already escaped the reservation before they ran. The pre-#50 demo was therefore corrupting pool memory on every boot; it simply happened not to fault.

With the bound correct, _sbrk() refuses the oversized request, newlib retries smaller, and malloc(64) succeeds using 72 bytes of the 512-byte reservation. So the reservation is adequate as it stands and _Min_Heap_Size does not need raising.

Harness

scripts/test_renode.py drives nucleo_f401re_ci.resc, which advances a fixed span of virtual time and quits on its own rather than depending on wall clock. Beyond the self-tests it asserts the boot banner reached the console, that the blink thread and the 1 Hz application timer have both run (covering the LED path and the timer service), and that the mutex, queue, event-flag and semaphore counters are all non-zero.

renode/nucleo_f401re_demo.robot covers the same ground for renode-test, and nucleo_f401re_demo.resc is the interactive counterpart.

The new test-nucleo-renode CI job mirrors test-polarfire-renode, consuming the ELF artifact from build-arm-nucleo.

Verification

Locally, with Renode 1.16.1 and the CI-pinned Arm GNU Toolchain 14.2.Rel1:

All 7 self-tests pass; harness exits 0.
Reintroducing the heap-bound bug: 3 self-tests fail and the harness exits 1, so the gate genuinely gates.
Clean build, -Wall -Wshadow -Wdouble-promotion -Werror: 22068 B ROM (up from 20120 B for the self-tests), 6000 B RAM unchanged.

Also

main.c drops a hardcoded 0x20018000 in favour of BSP_RAM_END, now that board_config.h is in scope, and names the 4 KB main-stack margin. Same value, no behaviour change.

AI assistance disclosure

This work was AI-assisted by me (@fdesbiens). The self-tests live in main.c, whose header follows the project's existing MIT form; the AGENTS.md AI Disclosure headers added in #50 remain on the four BSP files that carry Codex-derived content.

The ARM target had no runtime test. Its CI job checked only that the ELF existed, so the clock configuration, the TIM2 HAL timebase, the console and the heap bound were all unexercised. This brings it to parity with the PolarFire target, which gates CI on a headless Renode run. Renode ships no NUCLEO-F401RE board description, so renode/nucleo_f401re.repl derives one from the generic STM32F4 CPU platform and corrects Flash to 512 KB and SRAM to 96 KB. The generic platform is sized for the larger F407/F429 parts, and both the linker script's heap reservation and the _sbrk() bound depend on those limits being right. main.c gains seven startup self-tests that run before tx_kernel_enter(), so a failure is reported even when the scheduler never starts. They cover the _sbrk() allocate, release, underflow and over-limit paths, the invariant that the heap reservation ends at or below the ThreadX byte pool, the 84 MHz SystemCoreClock, and that TIM2 still ticks after HAL_RCC_ClockConfig() re-enters HAL_InitTick(). Test 4 is the regression guard for the heap bound fixed in eclipse-threadx#50. Requesting 32 KB fits inside the 96 KB SRAM but far exceeds the heap reservation. Reinstating the old end-of-SRAM bound was verified to fail the suite: newlib's first malloc() then took roughly 4 KB and put the break at 0x20002170, inside the ThreadX byte pool, which also broke self-tests 1 and 3. With the bound correct, _sbrk() refuses the oversized request, newlib retries smaller, and malloc(64) succeeds using 72 bytes of the 512-byte reservation - so the reservation is adequate and no heap growth is needed. scripts/test_renode.py drives nucleo_f401re_ci.resc, which advances a fixed span of virtual time and quits on its own rather than depending on wall clock. Beyond the self-tests it asserts the boot banner, that the blink thread and the 1 Hz application timer have both run (covering the LED path and the timer service), and that the mutex, queue, event-flag and semaphore counters are all non-zero. The suite was confirmed to exit 1 on a reintroduced bug and 0 on the fixed tree. The Robot Framework suite covers the same ground for renode-test, and the new test-nucleo-renode CI job mirrors test-polarfire-renode. main.c also drops a hardcoded 0x20018000 in favour of BSP_RAM_END now that board_config.h is in scope, with the 4 KB main-stack margin named.

Two problems in the pipeline, one of them mine. The NUCLEO Renode job fetched renode-latest.linux-portable.tar.gz with no version pin and no checksum, while the PolarFire job three jobs above it already pinned Renode 1.16.1 and verified its SHA256. That pin landed in #49, so it was present in this file when #51 added the NUCLEO job; the new job was modelled on an older copy of the PolarFire step rather than the current one. The result was a suite whose emulator could change under it on any Renode release, with nothing verifying what was downloaded. The NUCLEO job now uses the same pinned, checksum-verified step as PolarFire. The checksum was recomputed from the published artefact rather than copied on trust. Separately, every run re-downloaded roughly a gigabyte: the xPack RISC-V toolchain at ~414 MB and Renode at ~52 MB in each of two jobs. All three are now restored by actions/cache, keyed on the pinned version so a future bump invalidates the cache instead of silently serving the old one. This completes what #53 started for the Arm toolchain. Caching only makes sense because these are now pinned. Caching an unpinned "latest" artefact would have frozen CI on whichever build happened to be fetched first, turning a reproducibility gap into an invisible one. All four jobs now follow the same shape: cache, install only on a cache miss, then put the tool on PATH as a separate step so it runs on hit and miss alike. The PolarFire job also gains a version-reporting step, matching the Arm job, so the log records which compiler produced the ELF. Verified both constructed download URLs resolve, and that the Renode 1.16.1 checksum matches the published artefact. Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-31T15:32:01Z

Add Renode regression tests for the NUCLEO-F401RE target

Summary

The ARM target had no runtime test. Its CI job checked only that the ELF existed, so the clock configuration, the TIM2 HAL timebase, the console, and the heap bound were all unexercised. This brings it to parity with the PolarFire target, which already gates CI on a headless Renode run.

Follow-up to #50, which noted this gap under "Not addressed".

Renode platform

Renode ships no NUCLEO-F401RE board description, so renode/nucleo_f401re.repl derives one from the generic stm32f4.repl and corrects Flash to 512 KB and SRAM to 96 KB. The generic platform is sized for the larger F407/F429 parts, and both the linker script's heap reservation and the _sbrk() bound depend on those limits being accurate.

Startup self-tests

main.c gains seven self-tests that run before tx_kernel_enter(), so a failure is reported even when the scheduler never starts:

#	Self-test	Guards against
1	`_sbrk()` allocation lands inside the heap reservation	heap escaping its linker reservation
2	`_sbrk()` releases back to the heap base	broken negative-increment path
3	`_sbrk()` underflow rejected with `EINVAL`	shrinking below the heap base
4	`_sbrk()` rejects a request that fits SRAM but not the heap	bounding the heap at the end of SRAM
5	Heap reservation ends at or below the ThreadX byte pool	linker script layout regression
6	`SystemCoreClock` is 84 MHz	a silently wrong PLL configuration
7	HAL timebase (TIM2) tick advancing	`HAL_InitTick()` re-entry leaving TIM2 stopped

The regression guard, and what it revealed

Test 4 targets the heap bound fixed in #50. Requesting 32 KB fits inside the 96 KB SRAM but far exceeds the 512-byte heap reservation.

I verified the suite has teeth by reinstating the old end-of-SRAM bound and re-running it. It failed, and the failure was worse than expected: with that bound, newlib's firstmalloc() took roughly 4 KB and put the break at 0x20002170 — inside the ThreadX byte pool, which holds every thread stack and the queue buffer. That also broke self-tests 1 and 3, since the break had already escaped the reservation before they ran. The pre-#50 demo was therefore corrupting pool memory on every boot; it simply happened not to fault.

With the bound correct, _sbrk() refuses the oversized request, newlib retries smaller, and malloc(64) succeeds using 72 bytes of the 512-byte reservation. So the reservation is adequate as it stands and _Min_Heap_Size does not need raising.

Harness

scripts/test_renode.py drives nucleo_f401re_ci.resc, which advances a fixed span of virtual time and quits on its own rather than depending on wall clock. Beyond the self-tests it asserts the boot banner reached the console, that the blink thread and the 1 Hz application timer have both run (covering the LED path and the timer service), and that the mutex, queue, event-flag and semaphore counters are all non-zero.

renode/nucleo_f401re_demo.robot covers the same ground for renode-test, and nucleo_f401re_demo.resc is the interactive counterpart.

The new test-nucleo-renode CI job mirrors test-polarfire-renode, consuming the ELF artifact from build-arm-nucleo.

Verification

Locally, with Renode 1.16.1 and the CI-pinned Arm GNU Toolchain 14.2.Rel1:

All 7 self-tests pass; harness exits 0.
Reintroducing the heap-bound bug: 3 self-tests fail and the harness exits 1, so the gate genuinely gates.
Clean build, -Wall -Wshadow -Wdouble-promotion -Werror: 22068 B ROM (up from 20120 B for the self-tests), 6000 B RAM unchanged.

Also

main.c drops a hardcoded 0x20018000 in favour of BSP_RAM_END, now that board_config.h is in scope, and names the 4 KB main-stack margin. Same value, no behaviour change.

AI assistance disclosure

This work was AI-assisted by me (@fdesbiens). The self-tests live in main.c, whose header follows the project's existing MIT form; the AGENTS.md AI Disclosure headers added in #50 remain on the four BSP files that carry Codex-derived content.

The ARM target had no runtime test. Its CI job checked only that the ELF existed, so the clock configuration, the TIM2 HAL timebase, the console and the heap bound were all unexercised. This brings it to parity with the PolarFire target, which gates CI on a headless Renode run. Renode ships no NUCLEO-F401RE board description, so renode/nucleo_f401re.repl derives one from the generic STM32F4 CPU platform and corrects Flash to 512 KB and SRAM to 96 KB. The generic platform is sized for the larger F407/F429 parts, and both the linker script's heap reservation and the _sbrk() bound depend on those limits being right. main.c gains seven startup self-tests that run before tx_kernel_enter(), so a failure is reported even when the scheduler never starts. They cover the _sbrk() allocate, release, underflow and over-limit paths, the invariant that the heap reservation ends at or below the ThreadX byte pool, the 84 MHz SystemCoreClock, and that TIM2 still ticks after HAL_RCC_ClockConfig() re-enters HAL_InitTick(). Test 4 is the regression guard for the heap bound fixed in eclipse-threadx#50. Requesting 32 KB fits inside the 96 KB SRAM but far exceeds the heap reservation. Reinstating the old end-of-SRAM bound was verified to fail the suite: newlib's first malloc() then took roughly 4 KB and put the break at 0x20002170, inside the ThreadX byte pool, which also broke self-tests 1 and 3. With the bound correct, _sbrk() refuses the oversized request, newlib retries smaller, and malloc(64) succeeds using 72 bytes of the 512-byte reservation - so the reservation is adequate and no heap growth is needed. scripts/test_renode.py drives nucleo_f401re_ci.resc, which advances a fixed span of virtual time and quits on its own rather than depending on wall clock. Beyond the self-tests it asserts the boot banner, that the blink thread and the 1 Hz application timer have both run (covering the LED path and the timer service), and that the mutex, queue, event-flag and semaphore counters are all non-zero. The suite was confirmed to exit 1 on a reintroduced bug and 0 on the fixed tree. The Robot Framework suite covers the same ground for renode-test, and the new test-nucleo-renode CI job mirrors test-polarfire-renode. main.c also drops a hardcoded 0x20018000 in favour of BSP_RAM_END now that board_config.h is in scope, with the 4 KB main-stack margin named.

Two problems in the pipeline, one of them mine. The NUCLEO Renode job fetched renode-latest.linux-portable.tar.gz with no version pin and no checksum, while the PolarFire job three jobs above it already pinned Renode 1.16.1 and verified its SHA256. That pin landed in #49, so it was present in this file when #51 added the NUCLEO job; the new job was modelled on an older copy of the PolarFire step rather than the current one. The result was a suite whose emulator could change under it on any Renode release, with nothing verifying what was downloaded. The NUCLEO job now uses the same pinned, checksum-verified step as PolarFire. The checksum was recomputed from the published artefact rather than copied on trust. Separately, every run re-downloaded roughly a gigabyte: the xPack RISC-V toolchain at ~414 MB and Renode at ~52 MB in each of two jobs. All three are now restored by actions/cache, keyed on the pinned version so a future bump invalidates the cache instead of silently serving the old one. This completes what #53 started for the Arm toolchain. Caching only makes sense because these are now pinned. Caching an unpinned "latest" artefact would have frozen CI on whichever build happened to be fetched first, turning a reproducibility gap into an invisible one. All four jobs now follow the same shape: cache, install only on a cache miss, then put the tool on PATH as a separate step so it runs on hit and miss alike. The PolarFire job also gains a version-reporting step, matching the Arm job, so the log records which compiler produced the ELF. Verified both constructed download URLs resolve, and that the Renode 1.16.1 checksum matches the published artefact. Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-31T15:32:01Z

Add Renode regression tests for the NUCLEO-F401RE target

Summary

The ARM target had no runtime test. Its CI job checked only that the ELF existed, so the clock configuration, the TIM2 HAL timebase, the console, and the heap bound were all unexercised. This brings it to parity with the PolarFire target, which already gates CI on a headless Renode run.

Follow-up to #50, which noted this gap under "Not addressed".

Renode platform

Renode ships no NUCLEO-F401RE board description, so renode/nucleo_f401re.repl derives one from the generic stm32f4.repl and corrects Flash to 512 KB and SRAM to 96 KB. The generic platform is sized for the larger F407/F429 parts, and both the linker script's heap reservation and the _sbrk() bound depend on those limits being accurate.

Startup self-tests

main.c gains seven self-tests that run before tx_kernel_enter(), so a failure is reported even when the scheduler never starts:

#	Self-test	Guards against
1	`_sbrk()` allocation lands inside the heap reservation	heap escaping its linker reservation
2	`_sbrk()` releases back to the heap base	broken negative-increment path
3	`_sbrk()` underflow rejected with `EINVAL`	shrinking below the heap base
4	`_sbrk()` rejects a request that fits SRAM but not the heap	bounding the heap at the end of SRAM
5	Heap reservation ends at or below the ThreadX byte pool	linker script layout regression
6	`SystemCoreClock` is 84 MHz	a silently wrong PLL configuration
7	HAL timebase (TIM2) tick advancing	`HAL_InitTick()` re-entry leaving TIM2 stopped

The regression guard, and what it revealed

Test 4 targets the heap bound fixed in #50. Requesting 32 KB fits inside the 96 KB SRAM but far exceeds the 512-byte heap reservation.

I verified the suite has teeth by reinstating the old end-of-SRAM bound and re-running it. It failed, and the failure was worse than expected: with that bound, newlib's firstmalloc() took roughly 4 KB and put the break at 0x20002170 — inside the ThreadX byte pool, which holds every thread stack and the queue buffer. That also broke self-tests 1 and 3, since the break had already escaped the reservation before they ran. The pre-#50 demo was therefore corrupting pool memory on every boot; it simply happened not to fault.

With the bound correct, _sbrk() refuses the oversized request, newlib retries smaller, and malloc(64) succeeds using 72 bytes of the 512-byte reservation. So the reservation is adequate as it stands and _Min_Heap_Size does not need raising.

Harness

scripts/test_renode.py drives nucleo_f401re_ci.resc, which advances a fixed span of virtual time and quits on its own rather than depending on wall clock. Beyond the self-tests it asserts the boot banner reached the console, that the blink thread and the 1 Hz application timer have both run (covering the LED path and the timer service), and that the mutex, queue, event-flag and semaphore counters are all non-zero.

renode/nucleo_f401re_demo.robot covers the same ground for renode-test, and nucleo_f401re_demo.resc is the interactive counterpart.

The new test-nucleo-renode CI job mirrors test-polarfire-renode, consuming the ELF artifact from build-arm-nucleo.

Verification

Locally, with Renode 1.16.1 and the CI-pinned Arm GNU Toolchain 14.2.Rel1:

All 7 self-tests pass; harness exits 0.
Reintroducing the heap-bound bug: 3 self-tests fail and the harness exits 1, so the gate genuinely gates.
Clean build, -Wall -Wshadow -Wdouble-promotion -Werror: 22068 B ROM (up from 20120 B for the self-tests), 6000 B RAM unchanged.

Also

main.c drops a hardcoded 0x20018000 in favour of BSP_RAM_END, now that board_config.h is in scope, and names the 4 KB main-stack margin. Same value, no behaviour change.

AI assistance disclosure

This work was AI-assisted by me (@fdesbiens). The self-tests live in main.c, whose header follows the project's existing MIT form; the AGENTS.md AI Disclosure headers added in #50 remain on the four BSP files that carry Codex-derived content.

The ARM target had no runtime test. Its CI job checked only that the ELF existed, so the clock configuration, the TIM2 HAL timebase, the console and the heap bound were all unexercised. This brings it to parity with the PolarFire target, which gates CI on a headless Renode run. Renode ships no NUCLEO-F401RE board description, so renode/nucleo_f401re.repl derives one from the generic STM32F4 CPU platform and corrects Flash to 512 KB and SRAM to 96 KB. The generic platform is sized for the larger F407/F429 parts, and both the linker script's heap reservation and the _sbrk() bound depend on those limits being right. main.c gains seven startup self-tests that run before tx_kernel_enter(), so a failure is reported even when the scheduler never starts. They cover the _sbrk() allocate, release, underflow and over-limit paths, the invariant that the heap reservation ends at or below the ThreadX byte pool, the 84 MHz SystemCoreClock, and that TIM2 still ticks after HAL_RCC_ClockConfig() re-enters HAL_InitTick(). Test 4 is the regression guard for the heap bound fixed in eclipse-threadx#50. Requesting 32 KB fits inside the 96 KB SRAM but far exceeds the heap reservation. Reinstating the old end-of-SRAM bound was verified to fail the suite: newlib's first malloc() then took roughly 4 KB and put the break at 0x20002170, inside the ThreadX byte pool, which also broke self-tests 1 and 3. With the bound correct, _sbrk() refuses the oversized request, newlib retries smaller, and malloc(64) succeeds using 72 bytes of the 512-byte reservation - so the reservation is adequate and no heap growth is needed. scripts/test_renode.py drives nucleo_f401re_ci.resc, which advances a fixed span of virtual time and quits on its own rather than depending on wall clock. Beyond the self-tests it asserts the boot banner, that the blink thread and the 1 Hz application timer have both run (covering the LED path and the timer service), and that the mutex, queue, event-flag and semaphore counters are all non-zero. The suite was confirmed to exit 1 on a reintroduced bug and 0 on the fixed tree. The Robot Framework suite covers the same ground for renode-test, and the new test-nucleo-renode CI job mirrors test-polarfire-renode. main.c also drops a hardcoded 0x20018000 in favour of BSP_RAM_END now that board_config.h is in scope, with the 4 KB main-stack margin named.

Two problems in the pipeline, one of them mine. The NUCLEO Renode job fetched renode-latest.linux-portable.tar.gz with no version pin and no checksum, while the PolarFire job three jobs above it already pinned Renode 1.16.1 and verified its SHA256. That pin landed in #49, so it was present in this file when #51 added the NUCLEO job; the new job was modelled on an older copy of the PolarFire step rather than the current one. The result was a suite whose emulator could change under it on any Renode release, with nothing verifying what was downloaded. The NUCLEO job now uses the same pinned, checksum-verified step as PolarFire. The checksum was recomputed from the published artefact rather than copied on trust. Separately, every run re-downloaded roughly a gigabyte: the xPack RISC-V toolchain at ~414 MB and Renode at ~52 MB in each of two jobs. All three are now restored by actions/cache, keyed on the pinned version so a future bump invalidates the cache instead of silently serving the old one. This completes what #53 started for the Arm toolchain. Caching only makes sense because these are now pinned. Caching an unpinned "latest" artefact would have frozen CI on whichever build happened to be fetched first, turning a reproducibility gap into an invisible one. All four jobs now follow the same shape: cache, install only on a cache miss, then put the tool on PATH as a separate step so it runs on hit and miss alike. The PolarFire job also gains a version-reporting step, matching the Arm job, so the log records which compiler produced the ELF. Verified both constructed download URLs resolve, and that the Renode 1.16.1 checksum matches the published artefact. Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-31T15:32:01Z

Add Renode regression tests for the NUCLEO-F401RE target

Summary

The ARM target had no runtime test. Its CI job checked only that the ELF existed, so the clock configuration, the TIM2 HAL timebase, the console, and the heap bound were all unexercised. This brings it to parity with the PolarFire target, which already gates CI on a headless Renode run.

Follow-up to #50, which noted this gap under "Not addressed".

Renode platform

Renode ships no NUCLEO-F401RE board description, so renode/nucleo_f401re.repl derives one from the generic stm32f4.repl and corrects Flash to 512 KB and SRAM to 96 KB. The generic platform is sized for the larger F407/F429 parts, and both the linker script's heap reservation and the _sbrk() bound depend on those limits being accurate.

Startup self-tests

main.c gains seven self-tests that run before tx_kernel_enter(), so a failure is reported even when the scheduler never starts:

#	Self-test	Guards against
1	`_sbrk()` allocation lands inside the heap reservation	heap escaping its linker reservation
2	`_sbrk()` releases back to the heap base	broken negative-increment path
3	`_sbrk()` underflow rejected with `EINVAL`	shrinking below the heap base
4	`_sbrk()` rejects a request that fits SRAM but not the heap	bounding the heap at the end of SRAM
5	Heap reservation ends at or below the ThreadX byte pool	linker script layout regression
6	`SystemCoreClock` is 84 MHz	a silently wrong PLL configuration
7	HAL timebase (TIM2) tick advancing	`HAL_InitTick()` re-entry leaving TIM2 stopped

The regression guard, and what it revealed

Test 4 targets the heap bound fixed in #50. Requesting 32 KB fits inside the 96 KB SRAM but far exceeds the 512-byte heap reservation.

I verified the suite has teeth by reinstating the old end-of-SRAM bound and re-running it. It failed, and the failure was worse than expected: with that bound, newlib's firstmalloc() took roughly 4 KB and put the break at 0x20002170 — inside the ThreadX byte pool, which holds every thread stack and the queue buffer. That also broke self-tests 1 and 3, since the break had already escaped the reservation before they ran. The pre-#50 demo was therefore corrupting pool memory on every boot; it simply happened not to fault.

With the bound correct, _sbrk() refuses the oversized request, newlib retries smaller, and malloc(64) succeeds using 72 bytes of the 512-byte reservation. So the reservation is adequate as it stands and _Min_Heap_Size does not need raising.

Harness

scripts/test_renode.py drives nucleo_f401re_ci.resc, which advances a fixed span of virtual time and quits on its own rather than depending on wall clock. Beyond the self-tests it asserts the boot banner reached the console, that the blink thread and the 1 Hz application timer have both run (covering the LED path and the timer service), and that the mutex, queue, event-flag and semaphore counters are all non-zero.

renode/nucleo_f401re_demo.robot covers the same ground for renode-test, and nucleo_f401re_demo.resc is the interactive counterpart.

The new test-nucleo-renode CI job mirrors test-polarfire-renode, consuming the ELF artifact from build-arm-nucleo.

Verification

Locally, with Renode 1.16.1 and the CI-pinned Arm GNU Toolchain 14.2.Rel1:

All 7 self-tests pass; harness exits 0.
Reintroducing the heap-bound bug: 3 self-tests fail and the harness exits 1, so the gate genuinely gates.
Clean build, -Wall -Wshadow -Wdouble-promotion -Werror: 22068 B ROM (up from 20120 B for the self-tests), 6000 B RAM unchanged.

Also

main.c drops a hardcoded 0x20018000 in favour of BSP_RAM_END, now that board_config.h is in scope, and names the 4 KB main-stack margin. Same value, no behaviour change.

AI assistance disclosure

This work was AI-assisted by me (@fdesbiens). The self-tests live in main.c, whose header follows the project's existing MIT form; the AGENTS.md AI Disclosure headers added in #50 remain on the four BSP files that carry Codex-derived content.

The ARM target had no runtime test. Its CI job checked only that the ELF existed, so the clock configuration, the TIM2 HAL timebase, the console and the heap bound were all unexercised. This brings it to parity with the PolarFire target, which gates CI on a headless Renode run. Renode ships no NUCLEO-F401RE board description, so renode/nucleo_f401re.repl derives one from the generic STM32F4 CPU platform and corrects Flash to 512 KB and SRAM to 96 KB. The generic platform is sized for the larger F407/F429 parts, and both the linker script's heap reservation and the _sbrk() bound depend on those limits being right. main.c gains seven startup self-tests that run before tx_kernel_enter(), so a failure is reported even when the scheduler never starts. They cover the _sbrk() allocate, release, underflow and over-limit paths, the invariant that the heap reservation ends at or below the ThreadX byte pool, the 84 MHz SystemCoreClock, and that TIM2 still ticks after HAL_RCC_ClockConfig() re-enters HAL_InitTick(). Test 4 is the regression guard for the heap bound fixed in eclipse-threadx#50. Requesting 32 KB fits inside the 96 KB SRAM but far exceeds the heap reservation. Reinstating the old end-of-SRAM bound was verified to fail the suite: newlib's first malloc() then took roughly 4 KB and put the break at 0x20002170, inside the ThreadX byte pool, which also broke self-tests 1 and 3. With the bound correct, _sbrk() refuses the oversized request, newlib retries smaller, and malloc(64) succeeds using 72 bytes of the 512-byte reservation - so the reservation is adequate and no heap growth is needed. scripts/test_renode.py drives nucleo_f401re_ci.resc, which advances a fixed span of virtual time and quits on its own rather than depending on wall clock. Beyond the self-tests it asserts the boot banner, that the blink thread and the 1 Hz application timer have both run (covering the LED path and the timer service), and that the mutex, queue, event-flag and semaphore counters are all non-zero. The suite was confirmed to exit 1 on a reintroduced bug and 0 on the fixed tree. The Robot Framework suite covers the same ground for renode-test, and the new test-nucleo-renode CI job mirrors test-polarfire-renode. main.c also drops a hardcoded 0x20018000 in favour of BSP_RAM_END now that board_config.h is in scope, with the 4 KB main-stack margin named.

Two problems in the pipeline, one of them mine. The NUCLEO Renode job fetched renode-latest.linux-portable.tar.gz with no version pin and no checksum, while the PolarFire job three jobs above it already pinned Renode 1.16.1 and verified its SHA256. That pin landed in #49, so it was present in this file when #51 added the NUCLEO job; the new job was modelled on an older copy of the PolarFire step rather than the current one. The result was a suite whose emulator could change under it on any Renode release, with nothing verifying what was downloaded. The NUCLEO job now uses the same pinned, checksum-verified step as PolarFire. The checksum was recomputed from the published artefact rather than copied on trust. Separately, every run re-downloaded roughly a gigabyte: the xPack RISC-V toolchain at ~414 MB and Renode at ~52 MB in each of two jobs. All three are now restored by actions/cache, keyed on the pinned version so a future bump invalidates the cache instead of silently serving the old one. This completes what #53 started for the Arm toolchain. Caching only makes sense because these are now pinned. Caching an unpinned "latest" artefact would have frozen CI on whichever build happened to be fetched first, turning a reproducibility gap into an invisible one. All four jobs now follow the same shape: cache, install only on a cache miss, then put the tool on PATH as a separate step so it runs on hit and miss alike. The PolarFire job also gains a version-reporting step, matching the Arm job, so the log records which compiler produced the ELF. Verified both constructed download URLs resolve, and that the Renode 1.16.1 checksum matches the published artefact. Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-31T15:32:01Z

Add Renode regression tests for the NUCLEO-F401RE target

Summary

The ARM target had no runtime test. Its CI job checked only that the ELF existed, so the clock configuration, the TIM2 HAL timebase, the console, and the heap bound were all unexercised. This brings it to parity with the PolarFire target, which already gates CI on a headless Renode run.

Follow-up to #50, which noted this gap under "Not addressed".

Renode platform

Renode ships no NUCLEO-F401RE board description, so renode/nucleo_f401re.repl derives one from the generic stm32f4.repl and corrects Flash to 512 KB and SRAM to 96 KB. The generic platform is sized for the larger F407/F429 parts, and both the linker script's heap reservation and the _sbrk() bound depend on those limits being accurate.

Startup self-tests

main.c gains seven self-tests that run before tx_kernel_enter(), so a failure is reported even when the scheduler never starts:

#	Self-test	Guards against
1	`_sbrk()` allocation lands inside the heap reservation	heap escaping its linker reservation
2	`_sbrk()` releases back to the heap base	broken negative-increment path
3	`_sbrk()` underflow rejected with `EINVAL`	shrinking below the heap base
4	`_sbrk()` rejects a request that fits SRAM but not the heap	bounding the heap at the end of SRAM
5	Heap reservation ends at or below the ThreadX byte pool	linker script layout regression
6	`SystemCoreClock` is 84 MHz	a silently wrong PLL configuration
7	HAL timebase (TIM2) tick advancing	`HAL_InitTick()` re-entry leaving TIM2 stopped

The regression guard, and what it revealed

Test 4 targets the heap bound fixed in #50. Requesting 32 KB fits inside the 96 KB SRAM but far exceeds the 512-byte heap reservation.

I verified the suite has teeth by reinstating the old end-of-SRAM bound and re-running it. It failed, and the failure was worse than expected: with that bound, newlib's firstmalloc() took roughly 4 KB and put the break at 0x20002170 — inside the ThreadX byte pool, which holds every thread stack and the queue buffer. That also broke self-tests 1 and 3, since the break had already escaped the reservation before they ran. The pre-#50 demo was therefore corrupting pool memory on every boot; it simply happened not to fault.

With the bound correct, _sbrk() refuses the oversized request, newlib retries smaller, and malloc(64) succeeds using 72 bytes of the 512-byte reservation. So the reservation is adequate as it stands and _Min_Heap_Size does not need raising.

Harness

scripts/test_renode.py drives nucleo_f401re_ci.resc, which advances a fixed span of virtual time and quits on its own rather than depending on wall clock. Beyond the self-tests it asserts the boot banner reached the console, that the blink thread and the 1 Hz application timer have both run (covering the LED path and the timer service), and that the mutex, queue, event-flag and semaphore counters are all non-zero.

renode/nucleo_f401re_demo.robot covers the same ground for renode-test, and nucleo_f401re_demo.resc is the interactive counterpart.

The new test-nucleo-renode CI job mirrors test-polarfire-renode, consuming the ELF artifact from build-arm-nucleo.

Verification

Locally, with Renode 1.16.1 and the CI-pinned Arm GNU Toolchain 14.2.Rel1:

All 7 self-tests pass; harness exits 0.
Reintroducing the heap-bound bug: 3 self-tests fail and the harness exits 1, so the gate genuinely gates.
Clean build, -Wall -Wshadow -Wdouble-promotion -Werror: 22068 B ROM (up from 20120 B for the self-tests), 6000 B RAM unchanged.

Also

main.c drops a hardcoded 0x20018000 in favour of BSP_RAM_END, now that board_config.h is in scope, and names the 4 KB main-stack margin. Same value, no behaviour change.

AI assistance disclosure

This work was AI-assisted by me (@fdesbiens). The self-tests live in main.c, whose header follows the project's existing MIT form; the AGENTS.md AI Disclosure headers added in #50 remain on the four BSP files that carry Codex-derived content.

The ARM target had no runtime test. Its CI job checked only that the ELF existed, so the clock configuration, the TIM2 HAL timebase, the console and the heap bound were all unexercised. This brings it to parity with the PolarFire target, which gates CI on a headless Renode run. Renode ships no NUCLEO-F401RE board description, so renode/nucleo_f401re.repl derives one from the generic STM32F4 CPU platform and corrects Flash to 512 KB and SRAM to 96 KB. The generic platform is sized for the larger F407/F429 parts, and both the linker script's heap reservation and the _sbrk() bound depend on those limits being right. main.c gains seven startup self-tests that run before tx_kernel_enter(), so a failure is reported even when the scheduler never starts. They cover the _sbrk() allocate, release, underflow and over-limit paths, the invariant that the heap reservation ends at or below the ThreadX byte pool, the 84 MHz SystemCoreClock, and that TIM2 still ticks after HAL_RCC_ClockConfig() re-enters HAL_InitTick(). Test 4 is the regression guard for the heap bound fixed in eclipse-threadx#50. Requesting 32 KB fits inside the 96 KB SRAM but far exceeds the heap reservation. Reinstating the old end-of-SRAM bound was verified to fail the suite: newlib's first malloc() then took roughly 4 KB and put the break at 0x20002170, inside the ThreadX byte pool, which also broke self-tests 1 and 3. With the bound correct, _sbrk() refuses the oversized request, newlib retries smaller, and malloc(64) succeeds using 72 bytes of the 512-byte reservation - so the reservation is adequate and no heap growth is needed. scripts/test_renode.py drives nucleo_f401re_ci.resc, which advances a fixed span of virtual time and quits on its own rather than depending on wall clock. Beyond the self-tests it asserts the boot banner, that the blink thread and the 1 Hz application timer have both run (covering the LED path and the timer service), and that the mutex, queue, event-flag and semaphore counters are all non-zero. The suite was confirmed to exit 1 on a reintroduced bug and 0 on the fixed tree. The Robot Framework suite covers the same ground for renode-test, and the new test-nucleo-renode CI job mirrors test-polarfire-renode. main.c also drops a hardcoded 0x20018000 in favour of BSP_RAM_END now that board_config.h is in scope, with the 4 KB main-stack margin named.

Two problems in the pipeline, one of them mine. The NUCLEO Renode job fetched renode-latest.linux-portable.tar.gz with no version pin and no checksum, while the PolarFire job three jobs above it already pinned Renode 1.16.1 and verified its SHA256. That pin landed in #49, so it was present in this file when #51 added the NUCLEO job; the new job was modelled on an older copy of the PolarFire step rather than the current one. The result was a suite whose emulator could change under it on any Renode release, with nothing verifying what was downloaded. The NUCLEO job now uses the same pinned, checksum-verified step as PolarFire. The checksum was recomputed from the published artefact rather than copied on trust. Separately, every run re-downloaded roughly a gigabyte: the xPack RISC-V toolchain at ~414 MB and Renode at ~52 MB in each of two jobs. All three are now restored by actions/cache, keyed on the pinned version so a future bump invalidates the cache instead of silently serving the old one. This completes what #53 started for the Arm toolchain. Caching only makes sense because these are now pinned. Caching an unpinned "latest" artefact would have frozen CI on whichever build happened to be fetched first, turning a reproducibility gap into an invisible one. All four jobs now follow the same shape: cache, install only on a cache miss, then put the tool on PATH as a separate step so it runs on hit and miss alike. The PolarFire job also gains a version-reporting step, matching the Arm job, so the log records which compiler produced the ELF. Verified both constructed download URLs resolve, and that the Renode 1.16.1 checksum matches the published artefact. Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-08-31T15:32:01Z

Add Renode regression tests for the NUCLEO-F401RE target

Summary

The ARM target had no runtime test. Its CI job checked only that the ELF existed, so the clock configuration, the TIM2 HAL timebase, the console, and the heap bound were all unexercised. This brings it to parity with the PolarFire target, which already gates CI on a headless Renode run.

Follow-up to #50, which noted this gap under "Not addressed".

Renode platform

Renode ships no NUCLEO-F401RE board description, so renode/nucleo_f401re.repl derives one from the generic stm32f4.repl and corrects Flash to 512 KB and SRAM to 96 KB. The generic platform is sized for the larger F407/F429 parts, and both the linker script's heap reservation and the _sbrk() bound depend on those limits being accurate.

Startup self-tests

main.c gains seven self-tests that run before tx_kernel_enter(), so a failure is reported even when the scheduler never starts:

#	Self-test	Guards against
1	`_sbrk()` allocation lands inside the heap reservation	heap escaping its linker reservation
2	`_sbrk()` releases back to the heap base	broken negative-increment path
3	`_sbrk()` underflow rejected with `EINVAL`	shrinking below the heap base
4	`_sbrk()` rejects a request that fits SRAM but not the heap	bounding the heap at the end of SRAM
5	Heap reservation ends at or below the ThreadX byte pool	linker script layout regression
6	`SystemCoreClock` is 84 MHz	a silently wrong PLL configuration
7	HAL timebase (TIM2) tick advancing	`HAL_InitTick()` re-entry leaving TIM2 stopped

The regression guard, and what it revealed

Test 4 targets the heap bound fixed in #50. Requesting 32 KB fits inside the 96 KB SRAM but far exceeds the 512-byte heap reservation.

I verified the suite has teeth by reinstating the old end-of-SRAM bound and re-running it. It failed, and the failure was worse than expected: with that bound, newlib's firstmalloc() took roughly 4 KB and put the break at 0x20002170 — inside the ThreadX byte pool, which holds every thread stack and the queue buffer. That also broke self-tests 1 and 3, since the break had already escaped the reservation before they ran. The pre-#50 demo was therefore corrupting pool memory on every boot; it simply happened not to fault.

With the bound correct, _sbrk() refuses the oversized request, newlib retries smaller, and malloc(64) succeeds using 72 bytes of the 512-byte reservation. So the reservation is adequate as it stands and _Min_Heap_Size does not need raising.

Harness

scripts/test_renode.py drives nucleo_f401re_ci.resc, which advances a fixed span of virtual time and quits on its own rather than depending on wall clock. Beyond the self-tests it asserts the boot banner reached the console, that the blink thread and the 1 Hz application timer have both run (covering the LED path and the timer service), and that the mutex, queue, event-flag and semaphore counters are all non-zero.

renode/nucleo_f401re_demo.robot covers the same ground for renode-test, and nucleo_f401re_demo.resc is the interactive counterpart.

The new test-nucleo-renode CI job mirrors test-polarfire-renode, consuming the ELF artifact from build-arm-nucleo.

Verification

Locally, with Renode 1.16.1 and the CI-pinned Arm GNU Toolchain 14.2.Rel1:

All 7 self-tests pass; harness exits 0.
Reintroducing the heap-bound bug: 3 self-tests fail and the harness exits 1, so the gate genuinely gates.
Clean build, -Wall -Wshadow -Wdouble-promotion -Werror: 22068 B ROM (up from 20120 B for the self-tests), 6000 B RAM unchanged.

Also

main.c drops a hardcoded 0x20018000 in favour of BSP_RAM_END, now that board_config.h is in scope, and names the 4 KB main-stack margin. Same value, no behaviour change.

AI assistance disclosure

This work was AI-assisted by me (@fdesbiens). The self-tests live in main.c, whose header follows the project's existing MIT form; the AGENTS.md AI Disclosure headers added in #50 remain on the four BSP files that carry Codex-derived content.

The ARM target had no runtime test. Its CI job checked only that the ELF existed, so the clock configuration, the TIM2 HAL timebase, the console and the heap bound were all unexercised. This brings it to parity with the PolarFire target, which gates CI on a headless Renode run. Renode ships no NUCLEO-F401RE board description, so renode/nucleo_f401re.repl derives one from the generic STM32F4 CPU platform and corrects Flash to 512 KB and SRAM to 96 KB. The generic platform is sized for the larger F407/F429 parts, and both the linker script's heap reservation and the _sbrk() bound depend on those limits being right. main.c gains seven startup self-tests that run before tx_kernel_enter(), so a failure is reported even when the scheduler never starts. They cover the _sbrk() allocate, release, underflow and over-limit paths, the invariant that the heap reservation ends at or below the ThreadX byte pool, the 84 MHz SystemCoreClock, and that TIM2 still ticks after HAL_RCC_ClockConfig() re-enters HAL_InitTick(). Test 4 is the regression guard for the heap bound fixed in eclipse-threadx#50. Requesting 32 KB fits inside the 96 KB SRAM but far exceeds the heap reservation. Reinstating the old end-of-SRAM bound was verified to fail the suite: newlib's first malloc() then took roughly 4 KB and put the break at 0x20002170, inside the ThreadX byte pool, which also broke self-tests 1 and 3. With the bound correct, _sbrk() refuses the oversized request, newlib retries smaller, and malloc(64) succeeds using 72 bytes of the 512-byte reservation - so the reservation is adequate and no heap growth is needed. scripts/test_renode.py drives nucleo_f401re_ci.resc, which advances a fixed span of virtual time and quits on its own rather than depending on wall clock. Beyond the self-tests it asserts the boot banner, that the blink thread and the 1 Hz application timer have both run (covering the LED path and the timer service), and that the mutex, queue, event-flag and semaphore counters are all non-zero. The suite was confirmed to exit 1 on a reintroduced bug and 0 on the fixed tree. The Robot Framework suite covers the same ground for renode-test, and the new test-nucleo-renode CI job mirrors test-polarfire-renode. main.c also drops a hardcoded 0x20018000 in favour of BSP_RAM_END now that board_config.h is in scope, with the 4 KB main-stack margin named.

Two problems in the pipeline, one of them mine. The NUCLEO Renode job fetched renode-latest.linux-portable.tar.gz with no version pin and no checksum, while the PolarFire job three jobs above it already pinned Renode 1.16.1 and verified its SHA256. That pin landed in #49, so it was present in this file when #51 added the NUCLEO job; the new job was modelled on an older copy of the PolarFire step rather than the current one. The result was a suite whose emulator could change under it on any Renode release, with nothing verifying what was downloaded. The NUCLEO job now uses the same pinned, checksum-verified step as PolarFire. The checksum was recomputed from the published artefact rather than copied on trust. Separately, every run re-downloaded roughly a gigabyte: the xPack RISC-V toolchain at ~414 MB and Renode at ~52 MB in each of two jobs. All three are now restored by actions/cache, keyed on the pinned version so a future bump invalidates the cache instead of silently serving the old one. This completes what #53 started for the Arm toolchain. Caching only makes sense because these are now pinned. Caching an unpinned "latest" artefact would have frozen CI on whichever build happened to be fetched first, turning a reproducibility gap into an invisible one. All four jobs now follow the same shape: cache, install only on a cache miss, then put the tool on PATH as a separate step so it runs on hit and miss alike. The PolarFire job also gains a version-reporting step, matching the Arm job, so the log records which compiler produced the ELF. Verified both constructed download URLs resolve, and that the Renode 1.16.1 checksum matches the published artefact. Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens merged commit ef61eae into eclipse-threadx:devAug 31, 2026
5 checks passed

fdesbiens deleted the feat/nucleo-renode-tests branch August 31, 2026 15:44

This was referenced Aug 31, 2026
Correct the target template to describe how the framework actually works #52
Merged
Pin the NUCLEO Renode download and cache every toolchain fetch #55
Merged