boot: zephyr: call LOG_PANIC before jumping to app to flush in flight logs

[JayToltTech]

Problem

Pending log messages were lost when mcuboot jumped to the app.
ZEPHYR_BOOT_LOG_STOP() drains the software log buffers, but log
backends may still have data in flight that is discarded when the
app reinitializes the hardware.

Discovered because SWO logs were lost during the transition from
bootloader to app.

Solution

Call LOG_PANIC() after ZEPHYR_BOOT_LOG_STOP(). This gives each
log backend the opportunity to finish transmitting before the jump.

SWO log fixes depend on zephyrproject-rtos/zephyr#104432 which adds
hardware drain logic to the SWO backend's panic handler.

Test plan

• Build with CONFIG_LOG_BACKEND_SWO=y — verify all MCUboot log
  output is captured before app starts
• Tested on nRF5340 with J-Link SWO viewer

[Copilot]

Pull request overview

This pull request addresses lost or truncated log output when using Serial Wire Output (SWO) for logging in MCUboot. The issue occurs because the application reinitializes the ITM hardware on startup, discarding any data still being transmitted by the TPIU. The PR adds logic to wait for the ITM and TPIU hardware to finish transmitting before jumping to the application.

Changes:

• Modified ZEPHYR_BOOT_LOG_STOP macro to preserve logging for non-UART backends (SWO, RTT) that don't conflict with serial recovery
• Changed logging thread to start immediately with K_NO_WAIT instead of delaying by BOOT_LOG_PROCESSING_INTERVAL
• Added k_wakeup call to ensure logging thread drains final messages promptly
• Added SWO-specific drain logic that waits for ITM busy flag and adds 1ms delay for TPIU transmission

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[nordicjm]

this seems to be too driver specific in my mind, logging should be enabled in minimal footprint mode, which means things are output immediately without a separate thread, so that should also apply over SWO (there might be a driver Kconfig which controls buffering)

[JayToltTech]

That makes sense @nordicjm . So after reviewing your feedback, I think the right approach is:

• fix Zephyr's log_backend_swo_panic() so it performs this TPIU drain (does not today)
• Add a call to LOG_PANIC() here instead, which will trigger the flushing logic and call log_backend_swo_panic()

This seems like a general fix, and it may fix other unfound issues if people combine MCUBoot with deferred logging and other backends that also need a call to flush.

If you agree, I'll move forward with modifying this PR to call LOG_PANIC and a separate PR in the Zephyr tree to fix log_backend_swo_panic(). I'll confirm that this pair of fixes solves the problem I was seeing.

Note: in the case of SWO, I think this problem of draining TPIU will occur whether using immediate or buffered logs, because according to Zephyr, the data was 'transmitted' via ITM_SendChar() but there's still a secondary FIFO buffer flush wait that should occur before processor restart. I didn't test this specifically, but I think this is likely the case.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[nordicjm]

Seems build is failing on a device

[JayToltTech]

@nordicjm Fixed the build error by moving the LOG_PANIC into ZEPHYR_BOOT_LOG_STOP which is frankly a more appropriate location for the call in any case. This properly only calls LOG_PANIC if logging is enabled now.

Also fixed an issue with log_ctrl.h not being included in some log configurations that I caught along the way.

Rebased onto main.