Display turns blank after CircuitPython soft reboot

[xyx0826]

I use the brteve CircuitPython library at commit 5faba01 with the following hardware:

• Raspberry Pi Pico
• CFAF800480E1-050SC-A2 800x480 display with BT817, by Crystalfontz
  • Crystalfontz has an Arduino demo for this LCD

My code initializes the display as following:

eve_host = BrtEveRP2040()
eve = BrtEve(eve_host)

eve.init(resolution="800x480", touch="goodix")

So far I've been playing with the examples in this repo, helloworld-code.py and bubble-code.py. I would pair the example code with my initialization code and add required imports.

On cold boots and power cycles, the examples work great! However when I rerun the code or hit Ctrl-D in the serial console to soft reboot the MCU, EVE would initialize and turn on the backlight, but the LCD remains black. I wonder if it's a code logic or hardware configuration issue, and how should I debug it?

[xyx0826]

Further testing shows that I need to insert a delay of at least ~30ms somewhere in this block:

https://github.com/BRTSG-FOSS/pico-brteve/blob/5faba01334f5bfc0d8ae0248a481c69a8c2bdbc6/circuitPython/lib/brteve/brt_eve_module.py#L84-L90

That is, after the REG_ID check and before standard_startup(). With this delay, the code works across soft reboots.

Section 2.4 of the programming guide mentions waiting REG_CPURESET to read zero, which this library lacks, but that phase only took less than 1ms on my setup. I'm unsure if it's an issue with the EVE or the downstream LCD controller.

[brtchip-tuannguyen]

In C implement we wait for REG_CPURESET to reach 0, so can implement the same with CircuitPython.

[xyx0826]

I've tried adding the wait:

time_start = time.monotonic()
while self.rd32(self.eve.REG_CPURESET) != 0:
    assert(time.monotonic() - time_start) < 1.0, "EVE engines failed to reset"

time_took = time.monotonic() - time_start
print(f"Reset took {time_took} seconds")

I get the output: Reset took 0.0010376 seconds

While it's nice to have this check, it doesn't solve my issue. I still need to use a 30ms wait to work around the issue.

[brtchip-tuannguyen]

@xyx0826 Please try to reset the co-processor engine like the below, in init() function:

# reset the co-processor engine
self.wr32(self.eve.REG_CPURESET, 1)
self.wr32(self.eve.REG_CMD_READ, 0)
self.wr32(self.eve.REG_CMD_WRITE, 0)
self.wr32(self.eve.REG_CMD_DL, 0)
self.wr32(self.eve.REG_CPURESET, 0)

self.standard_startup()

[xyx0826]

Thank you for the snippet. Unfortunately it didn't work on my setup.

I looked into Crystalfontz's implementation and they have this delay here:

  // Start FTxx
  EVE_Command_Write(EVE_ACTIVE,0);

  // From Rudolf, ref: https://github.com/RudolphRiedel/FT800-FT813
  // BRT AN033 BT81X_Series_Programming_Guide V1.2 had a small change to
  // chapter 2.4 "Initialization Sequence during Boot Up"
  // Send Host command “ACTIVE” and wait for at least 300 milliseconds.
  // Ensure that there is no SPI access during this time.
  // I asked Bridgetek for clarification why this has been made stricter.
  // From observation with quite a few of different displays I do not
  // agree that either the 300ms are necessary or that *reading* the
  // SPI while EVE inits itself is causing any issues.
  // But since BT815 at 72MHz need 42ms anyways before they start to
  // answer, here is my compromise, a fixed 40ms delay to provide at
  // least a short moment of silence for EVE   
  delay(40);

  //Poll EVE_REG_ID until the 0x7C vector comes back

The programming guide is now at V2.3 and this is probably no longer relevant, but I did succeed with a 70ms delay right after self.coldstart(), and before the REG_ID check. Maybe we can just put a delay in the init routine and call it a day? 🤷‍♂️

[brtchip-tuannguyen]

@xyx0826 the delay is only mentioned in the Datasheet, can check it here: https://brtchip.com/wp-content/uploads/sites/3/2021/07/DS_BT817_8.pdf, at 4.9.4 it says need to delay 300ms after EVE_ACTIVE.

[xyx0826]

Thank you for the pointer. Created #25 based on the missing REG_CPURESET check. Since the delay workaround solves this issue, I'm going to go ahead and close this for now. Feel free to reopen if you would like to implement a better fix.