Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[rmand]

I've noticed that in some situations (perhaps if there are EVE_LIB_EndCoProList() commands without a EVE_LIB_BeginCoProList()), EVE can hang and produce an error.

For example:

read pointer: 0xfff
ERROR: illegal font or bitmap handle in cmd_toggle()

The documentation says we should:

When the host MCU encounters the fault condition, it can recover as follows:
1. Read REG_COPRO_PATCH_PTR into a local variable “patch_address”.
2. Set REG_CPURESET to 1, to hold the coprocessor engine in the reset condition
3. Set REG_CMD_READ , REG_CMD_WRITE , REG_CMD_DL to zero
4. Set REG_CPURESET to 0, to restart the coprocessor engine
5. Write the variable “patch_address” of step 1 to REG_COPRO_PATCH_PTR.
6. To enable coprocessor access flash content, send commands “CMD_FLASHATTACH” following
“CMD_FLASHFAST”. It will make sure flash enters full speed mode.
7. Restore REG_PCLK to the original value if the error string is ‘display list must be empty’
because REG_PCLK is set to zero when that specific error takes place.

So in the EVE LIB, it seems to be the following:

Code: [Select]

uint32_t Patch_Add = HAL_MemRead32(EVE_REG_COPRO_PATCH_PTR + EVE_RAM_REG);
HAL_MemWrite8(EVE_REG_CPURESET + EVE_RAM_REG, 1);
HAL_MemWrite8(EVE_REG_CMD_READ + EVE_RAM_REG, 0);
HAL_MemWrite8(EVE_REG_CMD_WRITE + EVE_RAM_REG, 0);
HAL_MemWrite8(EVE_REG_CMD_DL + EVE_RAM_REG, 0);
HAL_MemWrite8(EVE_REG_CPURESET + EVE_RAM_REG, 0);
HAL_MemWrite32(EVE_REG_COPRO_PATCH_PTR + EVE_RAM_REG, Patch_Add);


However, the above code does not seem to reset BT817 or the error and it remains stuck untill a hardware reset.

What's the correct way of doing this?

[BRT Community]

Hello,

The recovery procedure you are using is only applicable to the fault condition of the coprocessor in EVE.

read pointer: 0xfff
ERROR: illegal font or bitmap handle in cmd_toggle()

In the above case, the error happens due to the illegal font/bitmap handle, which means the coprocessor cannot understand the font metrics table associated with the specified font handle.
However, the font metrics table is a predefined data structure and may be in RAM_G for custom font, or in ROM for built-in font.
If the error persists after the coprocessor resets, it could mean that the font metrics table in RAM_G is still in a corrupt state. 

Can you please provide more information on how this issue is triggered?

Best regards BRT Community

[rmand]

Can you please provide more information on how this issue is triggered?

I believe this happens if/when  EVE_LIB_EndCoProList() does not match a EVE_LIB_BeginCoProList().  In other words you have something like:


EVE_LIB_BeginCoProList()
...
EVE_LIB_EndCoProList()
...
EVE_LIB_EndCoProList()

The Error itself does not seem to be related much to the current list being executed in the FIFO.  As the "screen" will render fine if EVE_LIB_EndCoProList() is not encountered out of turn. 

Font Handle Error when no BMP Font is used and 256 byte Format Buffer Overflow when the OPT_FORMAT string and the arguments are only a few bytes long.

It feels like the CoPro jumps to a random location and starts executing random code and eventually sees something it doesn't like. 

[BRT Community]

Thank you for providing more detail.

When the command 'EVE_LIB_EndCoProList()' does not match an 'EVE_LIB_BeginCoProList()', it will not necessarily cause an error every time however, it can cause unexpected outcomes depending on the circumstance which can lead to an error. For example, it may depend on what is written/sent when the list should have stopped. This could give the outcome you described where the CoPro appears to jump and execute random code. Try to ensure that your Begin and End commands match to avoid this issue.

One possible method to recover the device is to toggle the PD_N pin to perform a hardware reset. This can be done if you have connected the PD_N pin of the EVE IC to your MCUs GPIO. By doing so you reset everything except the sticky settings done by SPI command PIN_PD_STATE.

Another method is to use the 'RST_PULSE' command. This will reset the digital core including graphics, touch and audio engine. It will not change settings done by the SPI host command (clock source selection, clock freq selection, pin drive strength etc).

Best regards BRT Community