Logger: ISR context detection fails, needs deferred logging

[cptkoolbeenz]

Bug

LogMessage() claims to be ISR-safe via LogIsInISR() check (MIPS Status register EXL/ERL bits), but it fails to detect ISR context when called from the USB interrupt handler chain:

USB_Handler (ISR)
  → DRV_USBHS_InterruptHandler
    → DRV_USBHS_Tasks_ISR
      → F_USB_DEVICE_EventHandler
        → UsbCdc_EventHandler
          → LOG_D() → LogMessage() → xQueueSemaphoreTake → configASSERT failure

The MIPS EXL/ERL bits appear to get cleared deeper in the Harmony USB driver call chain, so LogIsInISR() returns false even though we're still in interrupt context. The mutex take then triggers a FreeRTOS assert in vTaskEnterCritical.

Workaround: Don't use LOG_D/LOG_I/LOG_E in USB event handlers. USB log level reverted to LOG_LEVEL_ERROR.

Proposed Fix: Deferred ISR Logging

Implement a deferred logging mechanism similar to how we already use FreeRTOS deferred interrupts (e.g., AD7609_DeferredInterruptTask, MC12bADC_EosInterruptTask):

1. ISR-safe queue: Use xQueueSendFromISR() with a small ring buffer of log entries
2. Deferred task: A low-priority task that drains the ISR log queue into the main log buffer (which uses the mutex)
3. API: Either fix LogIsInISR() detection, or add an explicit LOG_FROM_ISR() macro that callers in known ISR contexts can use

Option 3 (explicit macro) is simpler and avoids the unreliable MIPS status register check. The ISR macro would use xQueueSendFromISR directly, bypassing the mutex entirely.

References

• Logger ISR check: firmware/src/Util/Logger.c:257 (LogIsInISR)
• USB event handler: firmware/src/services/UsbCdc/UsbCdc.c:216 (UsbCdc_EventHandler)
• Existing deferred interrupt pattern: firmware/src/HAL/ADC/AD7609.c

Priority

Low — workaround in place (no logging from USB ISR). Only needed if USB event debugging is required in the future.

[cptkoolbeenz]

Additional Design Constraints

Memory management:

• The deferred ISR log queue must have a fixed, bounded size (e.g., 8-16 entries) to limit RAM usage
• When the queue is full, new ISR log entries should be silently dropped (not block) — use xQueueSendFromISR which returns immediately if full
• Consider a dropped-message counter that the deferred task can report (e.g., "N ISR log entries dropped") so we know if the queue is undersized
• Each queue entry should be a compact fixed-size struct (truncated message + source info), not a variable-length allocation

Rationale: ISR logging is inherently bursty (e.g., USB enumeration fires multiple events rapidly). The queue must never block the ISR, and memory usage must be predictable at compile time.