BRT Community

With some further testing I can check off a few questions:

*The offset of REG_SPI_WIDTH is 0x188 (the programming manual (v2.1) incorrectly states it is 0x180)
*You can write to the register using just 8 bits despite the manual indicating it's a 32 bit register
*This does appear to take effect once CS is released

So I really only have one outstanding question which is whether or not the SPI mode can be switched from normal to dual/quad at any time or if there is only a certain window during which this can take place.

I'm having trouble getting dual SPI mode to work. I've got some test code stood up that first reads REG_SPI_WIDTH which returns 0 as expected. I then try to set bit 0 to 1 using a write command, but this does not seem to take. I've verified this two ways:

* Read REG_SPI_WIDTH again to see if the new setting is in effect (this always returns 0) reading in both normal and dual SPI modes
* Read chip ID to see if it can be read back. No matter what I get the correct ID reading it in normal mode which suggests the setting has not taken effect

When exactly does the change take effect? I assume after CS is released? Does this register need to be handled as 32 bits or 8 bits? What is the correct offset for REG_SPI_WIDTH? 0x188?

The following code example is for the ESP-IDF.


#define REG_SPI_WIDTH        0x00302188
#define MEM_WRITE 0x80

static const uint8_t rxBits = 32;
trans.addr = REG_SPI_WIDTH;
trans.length = 0;
trans.rxlength = rxBits + dummyBits; //default to same as length
trans.tx_buffer = NULL;
trans.rx_buffer = rxBuf;
ret = spi_device_polling_transmit(EVE_spi_device, &trans);
assert(ret==ESP_OK);

uint32_t regSPI = 0;
memcpy(&regSPI, rxBuf+1, 4);
printf("%x\n", regSPI);

// write new register value, I've considered MSB and LSB encoding for these with no observed differences
trans.tx_data[0] = 0x1;
trans.tx_data[1] = 0x0;
trans.tx_data[2] = 0x0;
trans.tx_data[3] = 0x0;

trans.addr = REG_SPI_WIDTH | (MEM_WRITE << 16);
trans.length = rxBits;
trans.rxlength = 0;
trans.tx_buffer = NULL;
trans.rx_buffer = NULL;
trans.flags = SPI_TRANS_USE_TXDATA;
ret = spi_device_polling_transmit(EVE_spi_device, &trans);
assert(ret==ESP_OK);

trans.addr = REG_SPI_WIDTH;
trans.length = 0;
trans.rxlength = rxBits + dummyBits;
trans.tx_buffer = NULL;
trans.rx_buffer = rxBuf;
trans.flags = 0;
//trans.flags = SPI_TRANS_MODE_DIO;
ret = spi_device_polling_transmit(EVE_spi_device, &trans);
assert(ret==ESP_OK);

memcpy(&regSPI, rxBuf+1, 4);
printf("%x\n", regSPI);


This is occurring after initialization and after fast flash has been enabled.

Edit: I did another test where I switched to dual SPI shortly after the check of REG_CPU_RESET during initialization and this seems to have worked. Is it not possible to switch SPI modes at some point?

That's interesting that yours doesn't freeze up, despite seeming to exhibit similar behavior. I think when I get a chance I need to go through what has changed in your library since we branched from it and see if there's anything different in how everything is handled. I haven't had much time to observe it, but I do feel like migrating our images from RAM_G and the ARGB4 format to Flash and ASTC had a positive effect.

Using a hyphen and newline is working. The only unfortunate part is I had to reduce the font size on another page so they could share the same strings and come out looking ok.

Long term I think the way to go is to write some code as you suggested that performs this check automatically. We have talked about trying to determine the width of characters before to do things like this, but haven't had a pressing need to cross that bridge yet. If you have some examples I am certainly interested to see them.

We are using the Roboto font from Google: https://fonts.google.com/specimen/Roboto

Using a BT816 and I've come across an interesting problem. By and large word wrap works as expected, but that dastardly German language has reared its head and proving that nothing is ever simple. I've got some German words that are just ludicrously long. For instance, "Druckregelungsmagnetschalter". Nearly every other language I can get to fit on our screen, but thanks to the German tendency to turn a short phrase into a single word I've got text scrolling off either end of the visible screen.

Are there any options within the EVE engine to handle automatic hyphenation and word-wrap for situations like this? I've tried adding a hyphen at a good point within that word, but the Fill option doesn't handle or observe it. I hate to make our text even smaller because it's already on the margin of hard to read. Otherwise the only other option I have is to perhaps insert a line return into the string.

That is a heck of a coincidence! So for now I'm going to have to shelve this issue. I did just get done migrating all of our images to flash which has freed up RAM_G so I'm back to the observation stage. Otherwise there's some bigger fires to take care of now, unfortunately. Thanks for all the help!

Quote from: Rudolph on December 13, 2023, 07:01:57 PM
Interesting, I sent this through the "Disassembler" in EAB and put it after a little editing into EVE Screen Editor now. :-)

So, evidently you are using a 800x480 panel in portrait mode.

Correct.

Quote
A couple of image in ARGB that are located in RAM_G - these would need 1/8 of memory in ASTC 8x8 and probably less time to transfer depending on if you are using CMD_INFLATE and what compression ratio can achieved with the images.

I'm actually currently working on migrating the majority of our images over to flash as we had managed to nearly fill RAM_G. This also greatly reduces our boot time since we're not using CMD_INFLATE at initialization for all the graphics.

Quote
You are using a font that is stored in FLASH.
Have you tried using a ROM based font to see if that makes a difference?

Yeah, we're using the Roboto font to align with a corporate style guide. I hadn't considered using one of the ROM fonts, good idea.

Quote
The first thing that is drawn is a rectangle across almost the entire screen - why?
Next you draw a second rectangle, setting the line-width again and using BEGIN(RECTS) again is not necessary.

Style guide once again. We're supposed to have a thin (5 pixel) border around the screen, but in reality it's barely visible and the large rectangle could be eliminated. The second rectangle is drawing a header across the top of the screen. This is all really old code for the project and before I really knew how the display list worked; hence the unnecessary begin-rects and redefinition of the line width. I've attached a screenshot.

Quote
Speaking of BEGIN(), there is only a single END() at the very bottom - and I believe it has no effect down there at all.
While it might not be necessary to set an END() for every BEGIN(), it is recommended to do so in the programming guide.

I'll make sure to address that, thanks!

Quote
Then you draw 12 grey points.
Draw four rectangles and set the line-width and BEGIN() only once.
Draw four images over the rectangles and probably used EVE_cmd_setbitmap() to do so as this is happening a tad bit inefficient.
Next the color is set twice to white - for good measure? :-)
A larger image is placed, a row of text printed to the bottom.
One of the 12 grey points on the top is overwritten with a green point of the same size.
Two small images are placed, a green rectangle is drawn in the bottom right, an image is place on top of the rectangle.
A small bitmap is transformed and placed.

There's a series of navigation dots drawn across the top to indicate which page a user is on. We also have four user-defined buttons across the top of the screen which those four rectangles and icons define the function of. Perhaps wrongly so, the code is written such that the placement, width, etc can all by dynamically defined so there's some weirdness in how and when certain objects are defined. The button icons are also used elsewhere on some pages so it didn't make much sense to create an image that could duplicate what the icon and rectangle could accomplish. Some of this is defined as part of the static background so SPI communication wise it's actually not as bad as it looks.

The code is also structured such that different elements are drawn within different functions and/or objects so I'm not too surprised we really hammered that we wanted the color white.

The grey dots and green dot are handled differently in code. The grey dots are drawn as part of a static display and stored in RAM_G to be recalled when the main display list is defined while the green dot is drawn dynamically with every screen refresh to indicate which page the user is on, hence one gets overdrawn.

Quote
A slightly longer text is written in three rows - have you tried to split this into three separate CMD_TEXT?

So this is an interesting one. I was relying on the newline character to help with text wrapping and reduce how many commands we needed to send, but now that the vertical height of the font has changed since I've added more characters for language support there's too much space between lines and I will be splitting this into three CMD_TEXT. Since this element seems to be what's causing the display list to crash (I'm not certain of this) I suspect the change may indirectly resolve our problem.

Quote
I would say that this can be tweaked to be more efficient but then it looks like this is not what you are actually using,
this looks like a slightly reduced version as there are no touch tags set for example.

We don't utilize a touch screen so what you see is the full display list. As I hinted at earlier there are some elements stored to RAM_G as a static display list so while the list itself looks pretty cluttered, in terms of SPI communication overhead it's not as bad as it looks.

Quote
Oh, years you say? 
I changed quite a lot in the last, well, years, including the coprocessor fault recovery.

We're probably overdue for some updating. In all honesty everything had been working pretty darn well up until recently.

(On a side note, is every single post seriously limited by moderator approval or is there just a probationary period?)

Quote from: Rudolph on December 10, 2023, 04:07:51 PM

Quote
We're using a modified version of your library and the ESP-IDF.

Modified how, anything that I should consider as well?

This that and the other thing (helpful, I know!). We first started the project in earnest a couple years ago and branched from yours back then. I'll have to do a review and see what all we've changed over the years. Nothing major, but if I see anything useful I'll try and get back to you on this subject.

Quote
This morning I started a test using the PlatformIO project for ESP32 using ESP-IDF.

I modified the SPI clock in EVE_target.c for the display-update transfers with DMA to:
devcfg.clock_speed_hz = 26U * 1000U * 1000U;

I left the the SPI clock for single transfers at 10MHz as this is used to initially configure the EVE chip and
I observed that reading starts to fail at lower clock speeds than writing.

The display-refresh is at 50Hz.

In TFT_display() I added this:

Code Select Expand


static uint16_t fault_counter = 0;
static uint16_t reg_dlswap_faults = 0;
...
if(EVE_FAULT_RECOVERED == EVE_get_and_reset_fault_state())
{
  fault_counter++;
}

if(0 != EVE_memRead8(REG_DLSWAP))
{
  reg_dlswap_faults++;
  return;
}
...
EVE_color_rgb_burst(BLACK);

EVE_cmd_fillwidth(130);
EVE_cmd_text(10, 150, 28, 0, "First line\nSecond line\nThird line\nFourth line\nyet another line\nand one for good measure");

uint32_t arguments[2];
arguments[0] = (uint32_t) fault_counter;
arguments[1] = (uint32_t) reg_dlswap_faults;
EVE_cmd_text_var(10, 100, 28, EVE_OPT_FORMAT, "Faults: %d %d", 2, arguments);


We have 16:50 now and this is running since 9:45.
It still displays "Faults: 0 0".

So at least a longer line of text with a couple of line-breaks does not show an issue.

I suspect I have some EMI at play because I had a lot of trouble getting my issue to replicate when I tested at home over the weekend, but had it occur several times the following Monday when I was back in the office. That said, based of the DL list dump I don't see an errant data there so I really have my doubts. I have observed while doing an OTA flash that the screen would reset or even certain elements of the display would disappear for a frame. So there's definitely something odd going on and I'm fairly certain it's in my code. I need to roll back our code to something from a couple months ago and see if this is something we introduced at some point.

Quote
As you can see in the attached image, I am using an ESP32 board that looks like an Arduino UNO.
The jumper wires to my adapter board are about 10cm long.
The FFC from the adapter board to the display also is 10cm long.
The adapter is one of these: https://github.com/RudolphRiedel/EVE_display-adapter/tree/master/L-D5019-08/L-D5019-08-02.
The supply is from a bench PSU that I set to 9V.
As the controller and the display both use 3.3V for the signals, the logic buffers on the adapter are not actually needed.
But what helps with performance across several development boards are the 56R series resistors.

We do have some 22 ohm series resistors on the SPI bus.

I'll be away from work for the holidays for the rest of the month so I'll be able to pick this back up early January.

Now that I'm back in the office I managed to have it occur twice now this morning. I programmed it to dump RAM_DL until it comes to the display() command. I really want to blame EMI, but the dump from both occurences this morning are identical to each other.


02e3e0d9
26000007
03000000
27000000
1f000009
0e000030
04f5f5f5
40028041
40ed831b
1f000009
0e000030
04ffffff
40000000
40ed804b
1f000002
04d9d9d9
0d000050
404f0041
40568041
405e0041
40658041
406d0041
40748041
407c0041
40838041
408b0041
40928041
409a0041
40a18041
1f000009
0e0000a0
04e5e5e5
40090000
40280028
40488000
40678028
40880000
40a70028
40c78000
40e70028
044c4c4c
1f000001
0103df34
29000000
08005028
28000000
0730a028
400e8005
010459b4
29000000
08005028
28000000
0730a028
404e8005
010519dc
29000000
08005028
28000000
0730a028
408e8005
0104d50c
29000000
08005028
28000000
0730a028
40ce8005
04ffffff
04ffffff
1f000001
01000004
29000000
08037070
28000000
0736e070
400a0064
044c4c4c
22000000
27000002
06000000
0500000b
1f000001
0180257c
40a00b90
018023a0
40dc0b90
01802704
411a0b90
01802838
41500b90
01802774
41680b90
01801fe8
419c0b90
018021c4
41b40b90
018021fc
41ec0b90
0180226c
42240b90
018021fc
425c0b90
018021fc
42940b90
018021a8
42cc0b90
018021a8
43040b90
23000000
1f000002
0478cb3c
0d000050
40a18041
1f000001
0400b3ff
010a9354
29000000
08003c14
28000000
07307814
40370037
010a9804
29000000
08003c14
28000000
07307814
40aa0037
1f000009
0e000050
0478cb3c
400802e0
40200310
04ffffff
1f000001
01069ce4
29000000
08005028
28000000
0730a028
400a02e4
04ffffff
22000000
010f3850
0730741d
08024522
1f000001
1a000000
19020ccc
18020000
17000000
16020000
15020ccc
402f81ae
23000000
044c4c4c
22000000
27000002
06000000
0500000b
1f000001
0180257c
401403c0
0180288c
405003c0
01802790
408a03c0
01802918
40ae03c0
0180296c
40ce03c0
01802704
411a03c0
018028e0
415003c0
01802774
417203c0
01801fe8
41a603c0
018025d0
41be03c0
01802774
41fe03c0
018028e0
423203c0
018028fc
425403c0
018027e4
428803c0
0180288c
42a003c0
01802870
42da03c0
018021a8
401404a0
01802170
404c04a0
01802218
406604a0
01802170
409e04a0
018021a8
40b804a0
01802154
40f004a0
0180273c
410c04a0
01802170
414004a0
018021c4
415a04a0
01801fe8
419204a0
01802704
41aa04a0
0180273c
41e004a0
01802234
421404a0
0180226c
424c04a0
018021a8
428404a0
01802758
42bc04a0
01802758
42f404a0
018021e0
40140580
018021a8
404c0580
018021e0
40840580
018021fc
40bc0580
01802154
40f40580
018021c4
41100580
018021e0
41480580
01802154
41800580
018021c4
419c0580
018021c4
41d40580
01801fe8
420c0580
018021c4
42240580
018021a8
425c0580
018022c0
42940580
018021fc
42ac0580
018021e0
42e40580
018022c0
431c0580
018021e0
43340580
018021c4
436c0580
23000000
21000000
00000000

Edit: I reviewed the display list and compared it to our code. Everything seems to match up.

I just wanted to give an update and say I am still working on this. Getting the bug to replicate has been a real pain in the butt with it running for almost 30 hours without a problem. Then I flashed back to an earlier build and had the bug happen twice within the first hour, but had an error in my debugging code that didn't let it print out all of RAM_DL. With that fixed it's been another 24 hours and still no bug. I swear it's a classic Observe Effect except the code I added to dump RAM_DL only kicks in after the fault happens.

I don't have any jump/call functions so we can fairly safely rule that out.

Let's say there is no DISPLAY instruction and that's causing the bug (I think this is fairly likely); is it possible to recover by manually resetting REG_CMD_DL back to 0 and rebuilding RAM_DL?

Edit: Following the display list below, I did check the current value of REG_CMD_DL which reported 1064. That appears to be correct for a 266 word display list?

Quote from: Rudolph on December 05, 2023, 05:50:45 PM
What EVE chip with which library on which controller, connected how, at what SPI clock?
Have you tried a different software, a different hardware, lowered the SPI clock?

BT816Q with an ESP32-WROOM-32E connected over VSPI at a 26 MHz clock. We're using a modified version of your library and the ESP-IDF. I haven't tried this on different hardware yet and I have considered the lowering the clock. Occasionally I do see co-processor fault warnings that suggest the data bits aren't always correct and we're getting some corruption in that regard; the SPI bus is a bit long and when looking at it on a scope the rise and fall time of data is not great for the speed we're running. It's definitely a good idea to consider lowering the rate.

Quote
Why are you reading REG_DLSWAP in the first place?
In order to update as fast as possible?

Update rate is locked in at 20 Hz using an RTOS task. When doing static discharge testing we observed we could get the screen to freeze due to data corruption of the SPI communication leading to co-processor faults so some fault checking was added to the code that is performed before the DL list is reconstructed and swapped. In all we check:

-REG_ID for detecting if the EVE IC is communicating over SPI
-REG_DLSWAP to check for the graphics engine hanging
-REG_CMD_READ to check for any co-processor faults

Depending on what happens we generally perform a hard reset of the EVE IC to get the display working again. The downside is this creates a visible blackout of the screen as the EVE IC is reinitialized and images are decompressed into RAM_G.

Quote
What is reading from REG_CMD_READ return when REG_DLSWAP "hangs"?

I'm glad you mentioned this because I realized that we're checking the state of REG_DLSWAP before checking REG_CMD_READ. The code is written such that if REG_DLSWAP isn't 0 it handles and returns before REG_CMD_READ. So in all reality I may have been getting co-processor faults this whole time without realizing it. I'm currently running a test to check this and plan to change the order of operations in the code to resolve this oversight.

Edit: I finally got the bug to recreate with a bug fixed build. I still managed to get a graphics engine freeze, at the time REG_CMD_READ reported a value of 0x560 and the co-processor fault detection did not get triggered. At different times during this test I did get one random co-processor error (overflow in cmd_append()) so there is probably still some data corruption going on with the SPI communication.

Quote
If you a using a BT81x, what is stored in RAM_ERR_REPORT when such an event occurs?

Refer to above.

Quote
I never encountered this - or at least I did not notice. :-)
But then I am never reading REG_DLSWAP and only indirectly have it written to by using CMD_SWAP.

When anything goes wrong when using a new display module, the first thing I do is to get a SPI trace with the logic analyzer.

More than likely I've been getting co-processor faults and not realizing it because of the bug in our error checking. I do need to invest in a good logic analyzer as it's too difficult to pick out the data using our scope even though it does have a decode function; doesn't help that we also have two CAN controllers on the same SPI bus as the display so there's a fair bit of traffic going around.

So ultimately I need to wait for the issue to pop up again, but I'm pretty certain I'm getting a co-processor fault and that has been masked by how my error/fault checking is performed. Long term I probably just need to reduce the clock rate to improve reliability and we're also working towards moving the majority of our images to the display flash so the initialization time won't be as long.

Quote from: BRT Community on December 07, 2023, 10:54:45 AM
Hello,

Would you be able to provide the display list for the page that this occurs on?

Best Regards,
BRT Community

What format would you like that to be in? So you just want some pseudo code or would I be better served dumping the raw data of the actual display list? Although based on the conversation above I'm pretty sure there's nothing amiss in the display list.

I have a somewhat random problem where the graphics engine appears to be freezing. Before generating and swapping a new display list I'm checking REG_DLSWAP, REG_ID and REG_CMD_READ to monitor for errors and reset as needed. Something I'm getting pretty often at this point is that REG_DLSWAP is getting stuck with a value of 2 on a particular page in my UI. When this happens the display goes black or blank.

This page isn't terribly special with this particular behavior appearing to revolve around a command to draw a string of text of 55 characters with a few line returns. Nothing too crazy, but I have seemingly narrowed the behavior down to this particular string.

Anyway, per the documentation I'm giving the display some time to recover and polling REG_DLSWAP, but after about a half second I've got it programmed to time out and just do a hard reset of the EVE IC (pulling down PD to reset and then running all the same code that is ran at boot). At no time am I getting a Co-Processor fault and I've checked REG_CMD_READ and REG_CMD_WRITE to verify their positions are equal when this occurs.

Unfortunately this is a real bear to replicate as it can go a few minutes between failures and sometimes as much as half an hour. I half wonder if I'm getting some errant data on the SPI bus, but  I would expect to see some co-processor faults if that were the case.

What should I be looking for to delve into this further? Is there a more graceful way to recover from this than resetting the whole EVE IC?