Covered the byte allocate trace update on both of its paths

2026-09-20T17:10:46Z

The byte allocate keeps the same trace update in place the block allocate does, in the same two regions, and it was uncovered for the same reason: no test had run the service with tracing enabled, so the entry pointer checks stood at one of two and the time stamp comparisons at zero of two. A new test drives it with the three passes the block pool test uses. One configuration reaches less of it than the others and that is a property of the port rather than of the test: under TX_MISRA_ENABLE the trace time source is a routine whose body returns a constant, so every entry carries the same time stamp and the comparison reads equal whatever has been written over the entry. The overwritten round drives the same arm as the intact one there, and the arm that declines to update is reached in the plain trace configuration alone. Seven of the eight outcomes and all seven lines. The remaining one is the false arm of the immediate path's comparison. 129/129 in each of eight configurations with retries disabled. Assisted-by: Claude Code (Opus 5)

threadx.git/test/smp/regression/threadx_byte_pool_trace_update_test.c, branch v6.4.1_cert

Covered the byte allocate trace update on both of its paths