AnsweredAssumed Answered

BF534 spurious stack overflow.

Question asked by Peter847 on Mar 13, 2018
Latest reply on Mar 16, 2018 by Peter847



We are having problems with a BF534 running a VDK-based C++ application. Basically, at (fairly rare) random intervals it crashes, locking up with a stack overflow. The system stack is currently 16k, and I have tried both 8k and 32k, and the frequency of crashes is the same. Individual thread stacks are 4000 or 8000 words and using the stack APIs, thread stack use is nevermore than 800 words.


We recently defined EX_INTERRUPT_HANDLER and this speeds up the application significantly but now have this crashing problem. The screen shot shows three nested interrupts with a call to __adi_stack_overflow during the highest-priority interrupt. If I let the code run on it goes to KernelPanic with the value 0xdeadbeef supplied for all three parameters, which looks to me like some sort of error code. KernelPanic then recursively calls itself repeatedly with differing parameters until it calls with the kStackCheckFailure parameter. KernelPanic never executes its own code and just calls itself recursively. The crash always happens with these three interrupts. I am using VisualDSP 5.0 with Update 10.1 and an ICE100B emulator, (it crashes just the same running a Release build direct from memory).



Note that the handlers called by the interrupt appear to have called themselves recursively, even though the code does not allow this. This makes me think some sort of stack corruption has occurred. I have experimented by forcing EVT_IVG9 to be non-re-entrant (see code snippet below). The code has now run almost 24 hours without a crash, which doesn't make much sense - as the highest priority interrupt it shouldn't be interrupted anyway.

            //#ifdef VDK_REENTRANT_ISR


I suspect a NULL or corrupt pointer somewhere or else an inappropriate call to a VDK function from an ISR, but I can't find one, in spite of several days searching. I use a timer on IVG12 (lowest priority) to provide the system interrupt for the scheduler.


Would making the high-priority interrupt non-re-entrant be expected to have this effect, or is the change just masking a more basic problem such as a corrupt pointer etc?