Issue with sometimes display works, other times, just the backlight

[kumaichi]

I'm stuck in an extremely painful situation where sometimes everything displays correctly when my device powers up and other times, actually most of the time, only the backlight seems to work.  I'm using Rudolph's library as well as the EVE library as a reference and can't seem to figure out what I'm missing.  I'm using qspi which I don't think is an issue because sometimes it works fine.

I have attached my init method, can anyone possibly see what could cause it to display intermittently?

Kindest regards.

Code Select Expand


void TFT_qspi_init()
{
    HAL_GPIO_WritePin(MCU_DISP_RST_GPIO_Port, MCU_DISP_RST_Pin, GPIO_PIN_RESET);
    HAL_Delay(21); /* minimum time for power-down is 5ms */
    HAL_GPIO_WritePin(MCU_DISP_RST_GPIO_Port, MCU_DISP_RST_Pin, GPIO_PIN_SET);
    HAL_Delay(21); /* minimum time to allow from rising PD_N to first access is 20ms */

    //Reset the device
    TFT_sendCmd(EVE_RST_PULSE, 0x00);
    HAL_Delay(21);

    //External Crystal
    TFT_sendCmd(CMD_CLKEXT, 0x00);
    HAL_Delay(100);
    /* set clock to 72 MHz */
    TFT_sendCmd(CMD_CLKSEL, 0x46);
    /* start EVE */
    TFT_sendCmd(CMD_ACTIVE, 0x00);
    /* give EVE time to power up */
    HAL_Delay(40);

    /* read the ID */
    uint8_t regId = TFT_readId(REG_ID);
    while(regId != 0x7c)
    regId = TFT_readId(REG_ID);

    /* ensure CPUreset register reads 0 signaling it's ready */
    uint8_t cpuState = TFT_read8(REG_CPURESET);
    while ( cpuState != 0x00)
cpuState = TFT_read8(REG_CPURESET);

    /* switch to QSPI */
    TFT_write8(REG_SPI_WIDTH, 0x02);
    if(TFT_qspi_read8(REG_SPI_WIDTH) != 0x02)
        Error_Handler();

    /* tell EVE that we changed the frequency to 72MHz */
    TFT_qspi_write32(REG_FREQUENCY, 72000000);
    /* read the frequency to verify */
    if(TFT_qspi_read32(REG_FREQUENCY) != 72000000)
    Error_Handler();

    TFT_qspi_write8(REG_TRIM, 25);
    TFT_qspi_write16(REG_HSIZE, DispWidth); /*   800 */
    TFT_qspi_write16(REG_VSIZE, DispHeight); /*   480 */
    TFT_qspi_write16(REG_HCYCLE, DispHCycle); /*   816 */
    TFT_qspi_write16(REG_HOFFSET, DispHOffset); /*     8 */
    TFT_qspi_write16(REG_HSYNC0, DispHSync0); /*     0 */
    TFT_qspi_write16(REG_HSYNC1, DispHSync1); /*     4 */
    TFT_qspi_write16(REG_VCYCLE, DispVCycle); /*   496 */
    TFT_qspi_write16(REG_VOFFSET, DispVOffset); /*     8 */
    TFT_qspi_write16(REG_VSYNC0, DispVSync0); /*     0 */
    TFT_qspi_write16(REG_VSYNC1, DispVSync1); /*     4 */
    TFT_qspi_write8(REG_PCLK, DispPCLK); /*     1 */
    TFT_qspi_write8(REG_SWIZZLE, DispSwizzle); /*     0 */
    TFT_qspi_write8(REG_PCLK_POL, DispPCLKPol); /*     1 */
    TFT_qspi_write16(REG_CSPREAD, DispCSpread); /*     0 */
    TFT_qspi_write16(REG_DITHER, DispDither); /*     0 */
    TFT_qspi_write16(REG_PCLK_FREQ, DispPLCLKFREQ); /* 0xD14 */
    TFT_qspi_write8(REG_PCLK_2X, DispPCLK2x); /*     0 */

    TFT_qspi_write16(REG_PWM_HZ, 4000);
    TFT_qspi_write8(REG_PWM_DUTY, 128);

    TFT_qspi_write16(REG_GPIOX_DIR, 0xFFFF);
    TFT_qspi_write16(REG_GPIOX, 0xFFFF);

    /* turn off back light */
    TFT_qspi_write8(REG_PWM_DUTY, 0);

    while(TFT_busy()){};

    TFT_qspi_cmd(REG_CMDB_WRITE, CMD_SETROTATE, 1);

    /* If the status of the flash is 0 (INIT) Attach it */
    if (TFT_qspi_read8(REG_FLASH_STATUS) == 0x00) {
        uint32_t flashAttachCommand[] = {CMD_FLASHATTACH};

TFT_qspi_display(flashAttachCommand, 1);
    }

    /* Initialize the onboard flash and put in FAST mode
* Need to check the return value and not proceed if
* there is an error.
    */
    if(TFT_init_flash() != E_OK)
Error_Handler();

    /* turn on backlight pwm to 25% for any other module */
    TFT_qspi_write8(REG_PWM_DUTY, 0x25);
    uint32_t commands[] = {
CMD_DLSTART, /* start the display list */
DL_CLEAR_COLOR_RGB | 0x00000000, /* set the default clear color to white */
DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG, /* clear the screen - this and the previous prevent artifacts between lists, Attributes are the color, stencil and tag buffers */
DL_BEGIN | EVE_BITMAPS,
COLOR_RGB(255, 255, 255),
VERTEX2II(DispWidth / 2 , (DispHeight / 2) - 31, 31, 'T'), // ASCII T in font 31
VERTEX2II((DispWidth / 2 ) + 26, (DispHeight / 2) - 31, 31, 'E'), // ASCII E in font 31
VERTEX2II((DispWidth / 2 ) + 50, (DispHeight / 2) - 31, 31, 'X'), // ASCII X in font 31
VERTEX2II((DispWidth / 2 ) + 76, (DispHeight / 2) - 31, 31, 'T'),
DL_END,
COLOR_RGB(160, 22, 22), // change color to red
POINT_SIZE(520), // set point size to 20 pixels in radius
DL_BEGIN | EVE_POINTS, // start drawing points
VERTEX2II((DispWidth / 2 ) - 40, (DispHeight / 2) - 10, 0, 0), // red point
DL_END,
DL_DISPLAY,
CMD_SWAP// display the image
};

TFT_qspi_display(commands, sizeof(commands) / sizeof(commands[0]));

/* turn on backlight pwm to 25% for any other module */
TFT_qspi_write8(REG_PWM_DUTY, 0x25);

HAL_Delay(2000);
}


[BRT Community]

Hello,

Thank you for your question.

I cannot see any issues initially with your initialization routine.

Can I ask if you are seeing any co-processor errors reported when the screen fails to display?
See section 5.7 of the BT81x Programmers Guide.

Have you done any testing in single SPI mode? is the behaviour consistent with what you are seeing in Quad SPI?

Best Regards,
BRT Community

[kumaichi]

Hello,

Thanks for your response.

I haven't tried using SPI thus far, I'll have to dig out a board and give it a try.  While trying to debug this situation the only thing I've found so far is that sometimes the flash initialization fails:

Code Select Expand


if(TFT_init_flash() != E_OK)
Error_Handler();


To check for possible co-processor errors, I added this code placing a breakpoint at the bottom:

Code Select Expand


if(TFT_qspi_read16(REG_CMD_READ) == 0xFFF){
uint8_t Offset = 0;
uint8_t ErrChar;
uint8_t result[128 + 1]; // Buffer to hold the full string (including null terminator)
int result_index = 0;
do
{
// Get the error character and display it
ErrChar = TFT_qspi_read8(EVE_RAM_ERR_REPORT + Offset);
// Only append valid characters (non-null)
if (ErrChar != 0 && result_index < 128) {
result[result_index++] = ErrChar;
}

Offset++;
}while ( (ErrChar != 0) && (Offset < 128) ); // when the last stuffed character was null, we are done

// Null-terminate the string
result[result_index] = '\0';

// Now the full string is in 'result', which you can use or print
printf("Captured string: %s\n", result); //Line with breakpoint
}


It never hits the breakpoint, even when the screen just has the backlight, no graphics at all.

Thanks for the link to the latest programmer's guide, I was using an older version and didn't initially see the EVE_RAM_ERR_REPORT, this has since come in quite handy while trying to get custom fonts working via QSPI.

If I can do anything to help facilitate a solution, please let me know.

Kindest regards.

[BRT Community]

Hello,

Thank you for the update.

Can if there is any correlation between the instances of the flash attach error and display issue, i.e. do these both happen at the same time and does they always happen together?

Could I also ask what is contained within the TFT_init_flash() function? and whether the CMD_FLASHATTACH or presumably the CMD_FLASHFAST command is failing? if it is the latter what is the error code returned?

Thank you also for update regarding co-processor error checking, it is interesting that there is no error reported back from the co-processor, can I ask if the REG_CMD_WRITE and REG_CMD_READ pointers become equal when you observe the issue with the display?

Best Regards,
BRT Community

[kumaichi]

Hello,

Thank you for your response and suggestions.

It's definitely an issue with the flash, might be a timing issue because when I have the logic analyzer connected, it seems to work more consistently.  Not exactly sure why that is.  If I debug stepping through the code, it also works more consistently.  However, when it fails while debugging, it's always in the TFT_init_flash(), which makes sense because it's a hard fault at that point.

I update the flash code to be like this:

Code Select Expand


/* If the status of the flash is 0 (INIT) Attach it */
while (EVE_FLASH_STATUS_DETACHED == TFT_qspi_read8(REG_FLASH_STATUS))
{
    uint32_t flashAttachCommand[] = {CMD_FLASHATTACH};
    TFT_qspi_display(flashAttachCommand, 1);
}

if(TFT_init_flash() != E_OK)
Error_Handler();


My TFT_init_flash() method is borrowed from the EVE library or Rudolph's library, with the addition of the QSPI methods I created:

Code Select Expand


uint8_t TFT_init_flash()
{
    uint8_t timeout = 0U;
    uint8_t status;
    uint8_t ret_val = E_NOT_OK;

    status = TFT_qspi_read8(REG_FLASH_STATUS); /* should be 0x02 - FLASH_STATUS_BASIC, power-up is done and the attached flash is detected */

     /* we are somehow still in init, give it a litte more time, this should never happen */
    while (EVE_FLASH_STATUS_INIT == status)
    {
        status = TFT_qspi_read8(REG_FLASH_STATUS);
        DELAY_MS(1U);
        timeout++;
        if (timeout > 100U) /* 100ms and still in init, lets call quits now and exit with an error */
        {
            ret_val = EVE_FAIL_FLASH_STATUS_INIT;
            break;
        }
    }

/* no flash was found during init, no flash present or the detection failed, give it another try */
if (EVE_FLASH_STATUS_DETACHED == status) {
TFT_qspi_write32(REG_CMDB_WRITE, CMD_FLASHATTACH);
//EVE_execute_cmd();
status = TFT_qspi_read8(REG_FLASH_STATUS);
if (status != 2U) /* still not in FLASH_STATUS_BASIC, time to give up */
{
ret_val = EVE_FAIL_FLASH_STATUS_DETACHED;
}
}

    /* flash detected and ready for action, move it up to FLASH_STATUS_FULL */
    if (EVE_FLASH_STATUS_BASIC == status)
    {
        uint32_t result;

        //result = EVE_cmd_flashfast();
        uint16_t cmdoffset;

        TFT_qspi_cmd(REG_CMDB_WRITE, CMD_FLASHFAST, 0);
        status = TFT_qspi_read8(REG_FLASH_STATUS);

        //while (TFT_busy() != E_OK){};
        //TFT_qspi_WaitCmdfifo_empty();

        cmdoffset = TFT_qspi_read16(REG_CMD_READ);
    cmdoffset = TFT_qspi_read16(REG_CMD_WRITE); /* read the coprocessor write pointer */
    cmdoffset -= 4U;
    cmdoffset &= 0x0fffU;
    result = TFT_qspi_read32(EVE_RAM_CMD + cmdoffset);

        switch (result)
        {
            case 0x0000UL:
                ret_val = E_OK;
            break;

            case 0xE001UL:
                ret_val = EVE_FAIL_FLASHFAST_NOT_SUPPORTED;
            break;

            case 0xE002UL:
                ret_val = EVE_FAIL_FLASHFAST_NO_HEADER_DETECTED;
            break;

            case 0xE003UL:
                ret_val = EVE_FAIL_FLASHFAST_SECTOR0_FAILED;
            break;

            case 0xE004UL:
                ret_val = EVE_FAIL_FLASHFAST_BLOB_MISMATCH;
            break;

            case 0xE005UL:
                ret_val = EVE_FAIL_FLASHFAST_SPEED_TEST;
            break;

            default: /* we have an unknown error, so just return failure */
                ret_val = E_NOT_OK;
            break;
        }
    }

    if (EVE_FLASH_STATUS_FULL == status) /* we are already there, why has this function been called? */
    {
        ret_val = E_OK;
    }

    return (ret_val);
}


I'm certain the flash is the reason why it's failing because I was just stopping all processing.  However, with the above changes, it's more consistently working, maybe 1 out of 5 I still get just the backlight when turning it on/off.  Is the above code the best way to manage initializing the flash?  Any optimizations I can make?

I also have a Riverdi IPS_70 that I tried, using the IPS_70 settings and it turns on/off every time, but custom fonts don't work even though I flashed the same .bin file I'm using on the Riverdi IPS_50.  None of this is making any sense at all .

Thanks again for your assistance.

Kindest regards.

[BRT Community]

Hello,

Thank you for the details, it appears as if you have indeed based this function on Rudolph's implementation, I wouldn't expect any issues in this case as his library is quite robust and fairly well optimized.

I would note that it is interesting that the failure rate decreases when a logic analyser is attached to the lines, this may point to a signal integrity issue on the QSPI bus.
Are you using particularly long jumper wires in your configuration from your QSPI host to the Riverdi display? are you able to adjust the driver strength and slew rates on the QSPI master?
It may be worth attaching a oscilloscope to the QSPI bus to double check the integrity of the signals, similarly if you could test with a single SPI connection to verify the failure rate in this mode this may also provide to be insightful.


Best Regards,
BRT Community

[kumaichi]

Hello,

Thank you for your response.  After more research, I think the issue is in the set rotate command, nothing to do with reading from the flash.  I went through and put this line of code after pretty much everything, so I could see how much space was available:

Code Select Expand


uint16_t space;
space = TFT_qspi_read16(REG_CMDB_SPACE);


The rotate command always returns 4084 when the display doesn't work because it gets into the infinite loop, checking if REG_CMD_READ == REG_CMD_WRITE or if I use the TFT_Busy, it always returns EVE_FIFO_HALF_EMPTY.

Is there a reason why rotating the screen would have the REG_CMD_SPACE equal to 4084?  Every other call to TFT_qspi_read16(REG_CMDB_SPACE) always returns 4092. 

Code Select Expand


space = TFT_qspi_read16(REG_CMDB_SPACE); //Always 4092
TFT_qspi_cmd_rotate(1);
space = TFT_qspi_read16(REG_CMDB_SPACE); //When it fails, always 4084


Code Select Expand


void TFT_qspi_cmd_rotate(uint32_t rotation)
{
QSPI_CommandTypeDef numberCommand = {0};

// Set up the command structure
numberCommand.InstructionMode   = QSPI_INSTRUCTION_4_LINES;    // Instruction sent over 1 line
numberCommand.Instruction       = 0xB0; //Get the first byte, should 0xB0 (0x10) to write
numberCommand.AddressMode       = QSPI_ADDRESS_4_LINES;        // Address sent over 1 line
numberCommand.AddressSize       = QSPI_ADDRESS_16_BITS;        // Try using 16-bit address
numberCommand.Address           = 0x2578;            // Mask off the first byte and keep the last two bytes
numberCommand.DataMode          = QSPI_DATA_4_LINES;            // Data mode for receiving ID
numberCommand.NbData    = 8;                          // Expecting to receive 4 bytes
numberCommand.DummyCycles       = 0;                          // No dummy cycles
numberCommand.DdrMode           = QSPI_DDR_MODE_DISABLE;      // Disable DDR mode
numberCommand.SIOOMode          = QSPI_SIOO_INST_EVERY_CMD;    // Send instruction every command

uint8_t cmdArray[8] = {
(uint8_t)(CMD_SETROTATE & 0x000000ff),
(uint8_t)(CMD_SETROTATE >> 8),
(uint8_t)(CMD_SETROTATE >> 16),
(uint8_t)(CMD_SETROTATE >> 24),
/* Rotation */
(uint8_t)(rotation & 0x000000ff),
(uint8_t)(rotation >> 8),
(uint8_t)(rotation >> 16),
(uint8_t)(rotation >> 24)
};

if (HAL_QSPI_Command(&hqspi, &numberCommand, HAL_QSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
Error_Handler();

if (HAL_QSPI_Transmit(&hqspi, cmdArray, HAL_QSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
Error_Handler();

return;
}


Any suggestions would be greatly appreciated.

Kindest regards.

[BRT Community]

Hello,

Thank you for the update.

Can I clarify if you are trying to use CMD_ROTATE or CMD_SETROTATE? the function name provided below implies the former, but the definition for the later appears to have been utilised.

There is no reason that the CMD_ROTATE or CMD_SETROTATE command would cause the co-processor to hang (REG_CMD_READ =/= REG_CMD_WRITE) in normal operation. but it would help to understand when you are trying to call this command and what you are trying to achieve by calling it. i.e. are you trying to rotate an image and inadvertently using SETROTATE or are you intending on rotating the full screen?

In any case a a co-processor hang can also be caused by a poorly formed SPI transaction being received by EVE, in this case it may still be worth checking the integrity of the QSPI signals to the BT81x. Could also confirm if you are still seeing intermittent rendering fails, and if these are mitigated by removing the call to TFT_qspi_cmd_rotate?

Best Regards,
BRT Community

[Rudolph]

I do not see in your code to which address the command is written to.

numberCommand.Instruction = 0xB0; // Get the first byte, should 0xB0 (0x10) to write

And the rest?
The intended target is probably REG_CMDB_WRITE?
I never used HAL_QSPI_Command() or HAL_QSPI_Transmit().
CS likely is hardware controlled?

What does this look like on the logic analyzer? The whole sequence for this function and perhaps some bits and pieces before and after.

And then I would not be immediately concerned about this:
TFT_qspi_cmd_rotate(1);
space = TFT_qspi_read16(REG_CMDB_SPACE); //When it fails, always 4084

Yes ok, I get that it hangs for you it it does that but some commands just need a few cycles to complete and immediately reading back REG_CMDB_SPACE might be just too fast in this case.
My EVE_cmd_setrotate() function is setup as a standalone function and waits for the command to complete, so reading REG_CMDB_SPACE untill it returns 0xffcU.

What STM32 are you even using? Some STM32H7xx?

[kumaichi]

Hello,

Thank you for your response and patience.

I was trying to rotate the entire screen, my function was incorrectly named, thank you for pointing that out.  It has since been fixed.

This has been very frustrating to pinpoint the issue, and your suggestions have been very helpful.  Reading your responses, I started changing the slew rate.  The original setting in STM32CubeMX was set to "Very High".  I switched them all to "High" and haven't encountered any blank screens since.  I'm really hoping this was the issue.  I'll report back if I'm still encountering issues.

Again, thank you for your assistance and patience helping me work through interacting with the BT817Q via QSPI, it is greatly appreciated.

Kindest regards.

[BRT Community]

Hello,

Glad to hear you have managed to mitigate the issue, please let us know if it happens again or you run into any more issues.

Best Regards,
BRT Community

[kumaichi]

This is my first time using QSPI which was partly the cause of my confusion.  I couldn't figure out if it was something with my custom hardware or my firmware that was causing me so much trouble.  I'm using a STM32WB55REV for my two custom boards, one is the sender, and one is the receiver, the receiver is the one connected to a Riverdi display with the BT817Q.

I do not see in your code to which address the command is written to.

numberCommand.Instruction = 0xB0; // Get the first byte, should 0xB0 (0x10) to write

And the rest?

If I understand correctly, the QSPI is broken into Command and Address (excuse the variable names, I've been copy/pasting and have to come back to refactor everything, just trying to get something working initially):

Code Select Expand


numberCommand.Instruction = 0xB0; // Get the first byte, should 0xB0 (0x10) to write
numberCommand.Address     = 0x2578;


Those two lines are equivalent to these lines in your library:

Code Select Expand


spi_transmit((uint8_t) 0xB0U); /* high-byte of REG_CMDB_WRITE + MEM_WRITE */
spi_transmit((uint8_t) 0x25U); /* middle-byte of REG_CMDB_WRITE */
spi_transmit((uint8_t) 0x78U); /* low-byte of REG_CMDB_WRITE */


Then it sets up the EVE command and the value:

Code Select Expand


uint8_t cmdArray[8] = {
(uint8_t)(CMD_SETROTATE & 0x000000ff),
(uint8_t)(CMD_SETROTATE >> 8),
(uint8_t)(CMD_SETROTATE >> 16),
(uint8_t)(CMD_SETROTATE >> 24),
/* Rotation */
(uint8_t)(rotation & 0x000000ff),
(uint8_t)(rotation >> 8),
(uint8_t)(rotation >> 16),
(uint8_t)(rotation >> 24)
};


CS likely is hardware controlled?

Correct, the CS is completely out of my hands which is making it difficult to create the same kind of flow of your library where you setup the _burst commands because I haven't figured out how to keep the CS line pulled low while transmitting the rest of the EVE commands. 

What does this look like on the logic analyzer? The whole sequence for this function and perhaps some bits and pieces before and after.

I've captured waveforms with my Digilent AD 3 and Waveforms software, but they don't really have a QSPI decoder, so I had no idea what I was looking at.  As per the suggestion from BRT, I connected an oscilloscope to the QSPI lines and they didn't look well-formed which is what prompted me to change the skew rate, again suggested by BRT.  This has seemed to resolve the issue for me.

Kindest regards.

[Rudolph]

This is my first time using QSPI which was partly the cause of my confusion.  I couldn't figure out if it was something with my custom hardware or my firmware that was causing me so much trouble.  I'm using a STM32WB55REV for my two custom boards, one is the sender, and one is the receiver, the receiver is the one connected to a Riverdi display with the BT817Q.

Oh, yes, I still do not have a Nucleo with the STM32WB55.
I am not so invested in STM32 lately since I played with the STM32H7 and could not figure out how to use DMA for the SPI.
And I have seen that other newer devices lik H503 also started using the new DMA unit, not a fan so far.

I do not see in your code to which address the command is written to.
numberCommand.Instruction = 0xB0; // Get the first byte, should 0xB0 (0x10) to write
And the rest?

If I understand correctly, the QSPI is broken into Command and Address (excuse the variable names, I've been copy/pasting and have to come back to refactor everything, just trying to get something working initially):

Code Select Expand


numberCommand.Instruction = 0xB0; // Get the first byte, should 0xB0 (0x10) to write
numberCommand.Address     = 0x2578;


Yes, as expected, did not see that. :-)

CS likely is hardware controlled?

Correct, the CS is completely out of my hands which is making it difficult to create the same kind of flow of your library where you setup the _burst commands because I haven't figured out how to keep the CS line pulled low while transmitting the rest of the EVE commands. 

I do not know about the QSPI controller but for the other SPIs I am using
eve_spi_handle.Init.NSS = SPI_NSS_SOFT;

I have too many controllers in support for which hardware controlled CS either is not supported or does not work correctly.

What does this look like on the logic analyzer? The whole sequence for this function and perhaps some bits and pieces before and after.

I've captured waveforms with my Digilent AD 3 and Waveforms software, but they don't really have a QSPI decoder, so I had no idea what I was looking at.  As per the suggestion from BRT, I connected an oscilloscope to the QSPI lines and they didn't look well-formed which is what prompted me to change the skew rate, again suggested by BRT.  This has seemed to resolve the issue for me.

That is sound advice, for STM32 I am also setting GPIO_SPEED_FREQ_HIGH as maximum.
But then, after I ran into issues some years ago with a Teensy 4.1, I am also using series resistors on my evalboard adapter PCBs, 56R in all lines.
I used to have 10R in series and 22pF to GND as a low impact low-pass filter to smoothen the edges a little bit, but this did not work with the Teensy.

I do not have an oscilloscope available that could accurately measure what is actually going on the SPI, especially without adding load.
My theory is that too agressive switching is leading to refelections on the lines and this is why dampening with a series resistor helps.
Voodoo.