Facing stack corruption in LPC55S28

[rahulshah]

Hi NXP,

We are using hashscrypt driver from SDK-2.10.1. In that in function hashcrypt_get_data we are seeing first 8 bytes of digest variable  are corrupted. Below is the code snippet.

/*!
 * @brief Read OUTDATA registers.
 *
 * This function copies OUTDATA to output buffer.
 *
 * @Param base Hachcrypt peripheral base address.
 * @Param[out] output Output buffer.
 * @Param Number of bytes to copy.
 */
static void hashcrypt_get_data(HASHCRYPT_Type *base, uint32_t *output, size_t outputSize)
{
    uint32_t digest[8];

    while (0U == (base->STATUS & HASHCRYPT_STATUS_DIGEST_MASK))
    {
    }

    for (int i = 0; i < 8; i++)
    {
        digest[i] = swap_bytes(base->DIGEST0[i]);
    }

    if (outputSize > sizeof(digest))
    {
        outputSize = sizeof(digest);
    }
    (void)hashcrypt_memcpy(output, digest, outputSize);
}

Digest have proper value in DIGEST0 HW register, but after swapping somehow digest have not proper value. 

If we Disable global interrupt before copying to digest variable  digest[i] = swap_bytes(base->DIGEST0[i]);, then issue is not happen and if i initialize local digest variable to 0  uint32_t digest[8] = {0}; then also issue not happens. It indicates somehow stack is corrupted.

Is there any way to observe Stack corruption in LPC55S28. Also MTB & ETM is not supported in LPC55S28 ,so i cannot enable trace debugging to identify who is modifying digest variable. 

Please suggest good way to debug this issue.

Regards,

Rahul Shah

[rahulshah]

Hi,

No still issue is not resolved. Also as you mentioned about breakpoint where there is read /write. That is called Watchpoint, But that is only applicable for Global variables. In my case digest[] is local variable which is corrupted.

Still no clue how to debug.

Regards,

Rahul Shah

[frank_m]

> But that is only applicable for Global variables. In my case digest[] is local variable which is corrupted.

In my experience this depends on the toolchain (and the debugger). Usually, data watchpoints are basically related to addresses. 

Perhaps your issues are triggered by an interrupt handler, or another communication-based handler.

I had debugged such a problem last year, and it turned out the main (RT-OS) thread had passed a buffer on the stack to communication handler. This buffer address was (re-)used much later in the next OS cycle when the response from the remote device was processed, corrupting the stack.

Perhaps the values on the stack itself can give you a clue. They are either addresses or data values, which might help you identify the offender.

When you disable interrupts for the runtime of the routine, does the stack corruption still happen ?

As mentioned, I have no experience with LPC55S devices. And I'm no NXP employee, for all intents and purposes.

[rahulshah]

Yes, if i disable interrupts then everything works ok and not seen any corruption. But may be issue happens at other places later on . So i am searching exact root cause like who is corrupting the stack.

[frank_m]

Unless you have an immediate idea what causes it, I would disable individual interrupts one by one now and try again. Thus single out the handler that triggers the stack corruption.

[rahulshah]

So after all exercise if i disable SPI & UART interrupt then issue not happen. But if i keep them enabled then interrupt routine for SPI & UART not called at all during and around this issue.

[frank_m]

> But if i keep them enabled then interrupt routine for SPI & UART not called at all during and around this issue.

Not sure what you mean by that.

But interrupts are not called, they are asynchronous events caused by external sources, especially in the case of UART. A character reception or a "FIFO full" event usually trigger an interrupt.

In case of SPI (and if your MCU is the master), this happens more or less synchronously to a transmission. 

Check how you deal with received character(s), and closely guard buffer indices used inside this handlers. By the way, this includes ALL callback functions called from within interrupt context.

[frank_m]

I have no experience with the LPC55xx as such, only other LPC MCUs, and those of other vendors.

First, many toolchains support a watermarking, and many RTOSs support a runtime stack check. Watermarking is pre-filling the stack with specific values to detect it's usage (watermark) afterwards. Famous watermarking values are 0xDDDDDDDD, or 0xDEADBEEF. 

Both methods seem not very promising in your case, though.

The second option are data breakpoints. All proper toolchains (debugger) support such data breakpoints, which do not stop execution based on PC value, but on a reference (read) or change (write) to a certain data location.