Part Number: TDA4AEN-Q1
The issue was identified and resolved. The problem was caused by stack space misalignment. On J722S FreeRTOS C75x port the stack has to be aligned to 8 kbytes. C75x saves an event context at the address in the TCSP control register on every interrupt taken while a task runs. The FreeRTOS port derives each task's TCSP from the task's stack buffer in TaskSupport_setupTaskStack() (source/kernel/freertos/dpl/c75/TaskSupport.c): The caller's stack buffer start is aligned up to 8 KiB (TaskSupport_stackAlignment = 0x2000); the usable size is rounded down to an 8 KiB multiple. If the alignment overhead is large (>= configMINIMAL_STACK_SIZE-derived threshold, 0x1FF0 bytes with the J722S config), the code takes this branch: tcspBase = (void *)(((uintptr_t)pxStackArrayStartAddressAligned + tskStackSize)); For a 64 KiB stack buffer that is not 8 KiB-aligned, the overhead is always 0x2000, so this branch is always taken, and: tcspBase = buffer_end - (buffer_start % 0x2000) hardware writes = [tcspBase, tcspBase + ~0x4C0) (8 KiB reserved) The hardware context dump therefore extends past the end of the caller's stack buffer by up to ~0x4C0 bytes minus the start offset. Every interrupt taken while that task is on-CPU silently overwrites those bytes. For the issue to be triggered interrupts must to land while a task with misaligned stack runs. A blocked/sleeping task is never the interrupted context and the idle task, which has a port-provided correctly aligned stack, is immune. Hammering the uncached memory are slows the task down making it more likely the interrupt will occur while the task (and not idle) is running. FYI J722S TaskP/FreeRTOS API guide and C75x examples in the SDK use __attribute__((aligned(32))) for the stack.