uartns550: receive interrupt keeps firing (locks up system) if you fail to read all bytes

[mpb27]

I've modified the uartns550 interrupt example to receive 1 less bytes than sent (and only compare the 99 bytes). Then delay a bit to let the ReceiveTimeout interrupt fire. After you do this, the driver interrupt handler keeps firing and locks up the system. See code below.

https://github.com/Xilinx/embeddedsw/blob/master/XilinxProcessorIPLib/drivers/uartns550/examples/xuartns550_intr_example.c#L284-L319

    /*
     * Start receiving data before sending it since there is a loopback,
     * ignoring the number of bytes received as the return value since we
     * know it will be zero and we are using interrupt mode.
     */
    XUartNs550_Recv(UartInstancePtr, RecvBuffer, TEST_BUFFER_SIZE-1);

    /*
     * Send the buffer using the UART and ignore the number of bytes sent
     * as the return value since we are using it in interrupt mode.
     */
    XUartNs550_Send(UartInstancePtr, SendBuffer, TEST_BUFFER_SIZE);

    /*
     * Wait for the entire buffer to be received, letting the interrupt
     * processing work in the background, this function may get locked
     * up in this loop if the interrupts are not working correctly.
     */
    while ((TotalReceivedCount != TEST_BUFFER_SIZE-1) ||
        (TotalSentCount != TEST_BUFFER_SIZE)) {
    }

    /*
     * Verify the entire receive buffer was successfully received.
     */
    for (Index = 0; Index < TEST_BUFFER_SIZE-1; Index++) {
        if (RecvBuffer[Index] != SendBuffer[Index]) {
            BadByteCount++;
        }
    }

    /*
     * Delay a bit (how long? i think the length of 4 character times,
     * so that the RecieveTimeout interrupt fires, which then gets stuck in a loop.
     */

    for(Index = 0; Index < 1000000; Index++)
    {
        __asm("or    r0, r0, r0");   /* NOP                     [1 cycle ] */
    }

    /*
     * Disable the UartNs550 interrupt.
     */
    UartNs550DisableIntrSystem(IntcInstancePtr, UartIntrId);

    xil_printf("You Will Never Get Here!");

[andrewsil1]

I believe I am seeing this behavior as well, based on debugging an application of mine and viewing the interrupt behavior with the Vivado debug core. It only occurs in a Microblaze configuration that uses the “frequency” optimization for an 8-stage pipeline. The same code and the same design using the “Performance” Microblaze 5-stage pipeline works as expected- and it definitely appears to be tied to only reading the first few bytes in the FIFO (which in my application specify how many more bytes to expect) when several more have already been received by the time the read takes place.

[williamfligor]

I believe I am seeing this behavior as well, based on debugging an application of mine and viewing the interrupt behavior with the Vivado debug core. It only occurs in a Microblaze configuration that uses the “frequency” optimization for an 8-stage pipeline. The same code and the same design using the “Performance” Microblaze 5-stage pipeline works as expected- and it definitely appears to be tied to only reading the first few bytes in the FIFO (which in my application specify how many more bytes to expect) when several more have already been received by the time the read takes place.

@andrewsil1 did you ever figure out why the 8-stage pipeline was failing? I'm encountering issues in a design that doesn't use interrupts when 8-stage pipeline crashes but 5 stage does not.

[andrewsil1]

Never solved, and Xilinx took the attitude that all of the Microblaze tools are now effectively unsupported, or at least not likely ever going to be fixed.

Andy Silverman, Principal Program Manager Azure Hardware Architecture (AHA) Group

---

From: williamfligor notifications@github.com Sent: Tuesday, December 29, 2020 1:44:45 PM To: Xilinx/embeddedsw embeddedsw@noreply.github.com Cc: Andrew Silverman andrewsi@microsoft.com; Mention mention@noreply.github.com Subject: Re: [Xilinx/embeddedsw] uartns550: receive interrupt keeps firing (locks up system) if you fail to read all bytes (#37)

I believe I am seeing this behavior as well, based on debugging an application of mine and viewing the interrupt behavior with the Vivado debug core. It only occurs in a Microblaze configuration that uses the “frequency” optimization for an 8-stage pipeline. The same code and the same design using the “Performance” Microblaze 5-stage pipeline works as expected- and it definitely appears to be tied to only reading the first few bytes in the FIFO (which in my application specify how many more bytes to expect) when several more have already been received by the time the read takes place.

@andrewsil1https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fandrewsil1&data=04%7C01%7Candrewsi%40microsoft.com%7Cdcb24c80ea8c4db75f6008d8ac42f5a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637448750881576779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GHYIpyIm3uraraY21eqxwmLW74SJigAJL52CdfMUI30%3D&reserved=0 did you ever figure out why the 8-stage pipeline was failing? I'm encountering issues in a design that doesn't use interrupts when 8-stage pipeline crashes but 5 stage does not.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FXilinx%2Fembeddedsw%2Fissues%2F37%23issuecomment-752251856&data=04%7C01%7Candrewsi%40microsoft.com%7Cdcb24c80ea8c4db75f6008d8ac42f5a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637448750881576779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RXpUc9G1wnXJ0HS85mDtq5zTmKIkOJRrK0mhSceG48g%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABQVGLKHI4VR3JQ5B7D3F53SXJEU3ANCNFSM4ENXBYSQ&data=04%7C01%7Candrewsi%40microsoft.com%7Cdcb24c80ea8c4db75f6008d8ac42f5a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637448750881586746%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6jX8f%2BAsqyb6SWFA%2FCIgduUoFi6Yi990BNQf3FgYPko%3D&reserved=0.