General Category > Test and Review Area

BRT_AN_025 Beta - Portable MCU library for EVE

<< < (3/5) > >>

korstiaan:
Hi,

I 'm currently testing the library with a large display-list and now and then display gets stuck.
After further investigation it seems to block inside the EVE_LIB_AwaitCoProEmpty() -> HAL_WaitCmdFifoEmpty() function.

This is code where it gets stuck forever:


--- Code: ---uint8_t HAL_WaitCmdFifoEmpty(void) {
    uint32_t readCmdPointer;

    // Wait until the two registers match
    do {
        // Read the graphics processor read pointer
        readCmdPointer = HAL_MemRead32(EVE_REG_CMD_READ);
    } while ((writeCmdPointer != readCmdPointer) && (readCmdPointer != 0xFFF));

    if (readCmdPointer == 0xFFF) {
        // Return 0xFF if an error occurred
        return 0xFF;
    } else {
        // Return 0 if pointers became equal successfully
        return 0;
    }
}

--- End code ---

More specific, it gets stuck inside the do-while loop.

I'm sending very large display-lists (displaying QR-codes) and they take a while.

But any idea why it hangs there forever?
What is the good way to solve this?

For the moment I solved it like this:


--- Code: ---uint8_t HAL_WaitCmdFifoEmpty(void) {
    uint32_t readCmdPointer;
    uint8_t retry = 0;

    // Wait until the two registers match
    do {
        // Read the graphics processor read pointer
        readCmdPointer = HAL_MemRead32(EVE_REG_CMD_READ);
        retry++;

    } while ((writeCmdPointer != readCmdPointer) && (readCmdPointer != 0xFFF) && (retry < 250));

    if (retry == 250) {
        printf("retry HAL_WaitCmdFifoEmpty");
    }

    if (readCmdPointer == 0xFFF) {
        // Return 0xFF if an error occurred
        return 0xFF;
    } else {
        // Return 0 if pointers became equal successfully
        return 0;
    }
}
--- End code ---

I exit the loop if it takes to long.

Rudolph:
You can not send more then 4k in one go and even if you send less than 4k you still need to keep
an eye on the resulting size of the display list itself.

BRT Community:
Hello,

Rudolph is correct.

You should not edit the WaitCmdFifoEmpty() function to timeout as its intended purpose is to wait until the read and write pointers are equal, quitting out of this function early may result in unpredictable behaviour.

It is likely that there are issues with your Display List, you should ensure there is no Display List overrun in your code.
Best Regards,
BRT Community

korstiaan:
Hi,

Yes it is long (> 1000x EVE_VERTEX2F for drawing points) but is static, no changes.
At the end I always use EVE_LIB_AwaitCoProEmpty
It runs 4 times/sec. during sometimes more than 1hour ( > 14400 times) without any problem and then out of the blue it gets stuck inside this function?

What should I add and where to avoid this then?

Rudolph:
Right now it looks like you are running into the problem that you are putting too much into the command-FIFO.

You have this:

EVE_LIB_BeginCoProList();
EVE_CMD_DLSTART();

all commands

EVE_DISPLAY();
EVE_CMD_SWAP();
EVE_LIB_EndCoProList();
EVE_LIB_AwaitCoProEmpty();

Try this:

EVE_LIB_BeginCoProList();
EVE_CMD_DLSTART();

first portion of commands

EVE_LIB_EndCoProList();
EVE_LIB_AwaitCoProEmpty();

EVE_LIB_BeginCoProList();

second portion of commands

EVE_DISPLAY();
EVE_CMD_SWAP();
EVE_LIB_EndCoProList();
EVE_LIB_AwaitCoProEmpty();

I am not actively using the MCU library from BRT_AN_025 but my own.
But I just tried this with the test programm I made a while back and it works,
it splits the display-list generation in two parts.

You still need to check the size of the display list that the command co-processor created from what is send to the command-FIFO.

Before you start a new list, read out REG_CMD_DL and then print this out somewhere in the new display list.
This is the size of the previously generated list.
If you are getting close to 8k, you have a problem.

Navigation

[0] Message Index

[#] Next page

[*] Previous page