Display does not work anymore

[C-Mon83]

Hello Mr. Riedel

In my project I am using your library to control an EVE display (MatrixOrbital EVE3-50G). In a first step I used the STM32H757I-EVAL board as MCU. The display shows a few lines and 3 simple images, which I load into RAM_G with the inflate command. In a further step, I integrated the implementation of the EVAL board in the original project (MCU STM32H755ZI). Everything has worked so far. I have continuously added further graphics to the project, which are loaded into the RAM_G. I continuously checked the implementation by showing the graphics on the display. I used the EAB tool to prepare the graphics according to the instructions in your forum. During development, however, it happened that the display sporadically stopped showing anything. It seemed as if the display was stuck in a certain state. I then carried out the error recovery procedure manually a few times, restarted the device several times and loaded older software versions until it suddenly started working again. After that, the display worked for a certain period of time without any problems until it stopped working again. However, I could not recognize a defined procedure to reanimate the display. Suddenly it worked again.

However, it is now the case that the display can no longer be controlled with the H755ZI hardware. At best, the display turns white when the backlight is set to the maximum value during initialization. When I connect the display to the EVAL board, the display works perfectly. To rule out a problem when loading and displaying the graphics, I have removed these calls and only write "Hello world!" in black letters on a white background. I recorded all SPI commands during initialization and control of the screen with the oscilloscope and compared the sequences between the EVAL board and the H755ZI. The SPI communication signals look practically identical. Only with the H755ZI does the MOSI or CLK remain HIGH for certain commands after the CS is reset (set to HIGH) and then slowly come down to again. It also happens that there is no longer a negative edge on the last SPI CLK when the CS is reset (set to HIGH) at the end of transmission. I wonder if this could be a problem for the display, but the data is overtaken to the positive edge. With the EVAL board, the signals always return cleanly to LOW when the CS changes back to HIGH.

I originally had the SPI speed set to 30 Mbit/s, but have reduced it to 350kBit/s so that the edges are cleaner and to avoid coupling in interference signals (the SPI lines to the display are approx. 25cm long).

I can't explain why the display no longer works with the H755ZI, even if I switch to an old SW version that used to work. On the EVAL board the display works stable with the same instructions. The display should behave the same with the same SPI signals? Or is the floating MOSI and CLK line with CS on HIGH from the H755ZI a problem after all? But this SW worked in the beginning and nothing was changed in the SPI driver.

The difficulty for me is to find out what is wrong with the display. I have also read out the error register, but there is no error there. The error recovery procedure doesn't help either.

What else can I do to find out what is wrong with the display? I have also noticed that when write commands are sent to the display, data is also sent on the MISO line. With the EVAL board, the data also exists on the MISO line. However, this data is not always the same and I wonder what kind of data the display sends. I can't find anything on this topic in the data sheet or the programming guide. However, I am of the opinion that I can ignore this data for pure write commands.

I just don't understand why the display can no longer be controlled with a SW that works once, even though the data on the SPI interface looks good.

Have you had any similar experiences or do you have any idea what the problem might be?

Many thanks for your support!

I will attach the recordings of the SPI signals, but I do not have access to the data at the moment.

Kind regards
Simon

[RudolphRiedel]

Hi,

this sounds a bit like an issue with the controller or how things are wired to the display.
Also 30MHz might be a bit much in general, depending on your hardware setup.

I just checked, there is no support for the STM32H757I in Platformio, so I can't do a quick check if it compiles out of the box.
And wow, that thing is a bit out of scope for an EVE display with a 480MHz M7 plus a 240MHz M4 and a MIPI-DSI Interface. :-)

This also reminds me that I wanted to put in more work in to support DMA with STM32 in general.

The closest I could try spontaneously was STM32H750VBT6 and at least it compiles.
The closest board I do have right now is a Nucleo-H503RB - which is not actually close. :-)
And I have STM32F407 and STM32F446.

Yes, I am not actually using STM32 for anything.

Have you modified EVE_target_STM32.h?
Which SPI and which pins are you using?
I can try to feed this to STM32CubeIDE.

In regards of the SPI traffic, I have no logic anaylzer trace for a STM32 at hand.
So I don't know what the idle levels for SCLK and MOSI are.

On MISO EVE is always sending 0x00 0x4a 0x43 and 0x42 when it is active.
When writing, this is followed by 0x00, regardless how many more bytes are send on MOSI.

[C-Mon83]

Hello Mr. Riedel

Thank you very much for the quick reply.

The response with the byte sequence on the MISO line helped to interpret the data. I could not find this information anywhere in the documentation. Should this be the case for all commands? I have no data on the MISO line for some commands.

The following sequence is from the EVAL board on which the display works:

In the sequence of the H755ZI you can see that the signals on the MOSI line are correct, but the wrong signals are transmitted on the MISO (sometimes only one peak):

I tried out various settings in the SPI configuration today. Suddenly, when I changed the baud rate prescaler to 8 (11.25MHz), the display worked. And the data on the MISO line could also be interpreted correctly. I then tried to find out whether the display also works at other SPI frequencies. Depending on the prescaler, the display sometimes worked better and sometimes worse (sometimes the data was not displayed correctly). A prescaler below 8 and above 128 no longer worked. However, I was always able to switch back to a prescaler (e.g. 8 or 32) and it still worked.

Then I wanted to check whether the SPI communication is more stable if the clock is a fraction of the PCKL of the display. After this test, the display stopped working again. Not even with the previously functioning SW version.

It again seems as if the display is in a state from which it will not recover. The only question is how and what causes this condition?

Kind Regards
Simon

[RudolphRiedel]

Hey, do not call me Mr. Riedel. :-)

Should this be the case for all commands?

Yes, at least as soon as EVE starts answering after wakeup every time the first four bytes on MISO are 0x00 0x4a 0x43 0x42.

I started to play again with STM32 and this is what a sequence looks like from the STM32F407:

This is connected to an EVE3-50G and the SPI clock is 10MHz.

The initial clock must be no higher than 11MHz, only after startup upto 30MHz are allowed.

How is your controller wired to the display exactly?
I am using one of these with the F407 Discovery: https://github.com/RudolphRiedel/EVE_display-adapter/tree/master/L-D5019-08
And I am using 13V from my bench PSU to power it, draws 70mA right now.

I do observe that the MOSI line with the STM32F4 is low when the last byte is 0x00 and high when the last byte is 0xff.
Interesting, but does not really matter.

Using STM32CubeIDE is a bit odd, usually I use PlatformIO.
But well, code generation, it might not be perfect but at least things mostly work. :-)

[C-Mon83]

Hello Rudolph

Thanks for the test. Your recorded sequence really looks very good.

To the questions in your first answer:

• I have modified the EVE_target_STM32.h accordingly to my implementation.

• On EVAL Board I use SPI4 (PE12 = CLK, PE13 = MISO, PE14 = MOSI); PE11 = CS and PE9 = PDN configured as GPIO Outputs
  

• On H755ZI I use SPI5 (K0 = CLK, J11 = MISO, J10 = MOSI); G7 = CS and E15 = PDN configured as GPIO Outputs

• SPI GPIO configuration as with the EVAL board

The wiring of the EVAL board is shown below. According to the schematic of the EVAL board, it has a 33 Ohm resistor in series in each SPI line.

The cables are soldered directly to the display pads.

To change the display between the two MCUs, there is a pin connector in the middle of the cable. During the first attempts on the EVAL board, it was noticed that the SPI communication only works if the probe from the logic analyzer is connected to the CLK line. This is the reason why a resistor (1 MOhm) was soldered to the pin connector between GND and CLK. The display is also supplied with 3.3V from an external power supply via the pin connector. The GND from the external power supply and the GND from the EVAL board are brought together on the pin connector.

For the hardware with the H755ZI, the cabling is as follows. A 68 Ohm resistor is connected in series with the SPI lines on the controller. The same display from the screenshot of the wiring of the EVAL board is connected via the pin connector.

This raises the question of what influence the long cables have? The long cables do not seem to be a problem on the EVAL board.

Further tests have shown that if the display is not working, only short pulses can be seen on the MISO line when the display is driving the MISO line with its data. The following screenshot shows the second byte when reading the REG_ID register. Instead of the expected value (4Ah), only three pulses can be seen on the line (SPI Clock 703.125kHz).

As a further test, the MISO line was disconnected on the MCU side. As a result, the correct signals were visible on the MISO line. It appears that the MCU is negatively influencing the MISO line.

I have another question regarding the implementation of the SPI driver in the EVE Library. I could not find the setting of the registers SPI_CR2_TSIZE (LL_SPI_SetTransferSize), SPI_CR1_SPE (LL_SPI_Enable) and SPI_CR1_CSTART (LL_SPI_StartMasterTransfer). In the file EVE_target_STM32.h, data is written directly in the function spi_transmit(uint8_t data) by calling LL_SPI_TransmitData8(EVE_SPI, data). Where is the SPI activated and the transfer started? Have I overlooked something?

Thank you for your support.

Regards
Simon

[RudolphRiedel]

Hi,

I got nothing, overall this looks ok, except of course that the controller really should not pull the MISO lines.
Yes, the length of the cables is an issue, this increases the load on the drivers and everything gets more rounded.
SPI is for short on-board communication.
But then, 700kHz is nothing.
Higher frequencies are mostly an issue when trying to read back, like touch-events, I observed a couple of times that reading stops working reliably long before writing mails.

Oh, something that helped with a different controller and is a bit odd, you can try to use GPIO_SPEED_FREQ_HIGH instead of GPIO_SPEED_FREQ_VERY_HIGH, there might be ringing on the lines.

On the F407 I got this:
GPIO_InitStruct.Pin = GPIO_PIN_10|GPIO_PIN_11|GPIO_PIN_12;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
GPIO_InitStruct.Alternate = GPIO_AF6_SPI3;

I have another question regarding the implementation of the SPI driver in the EVE Library.
I could not find the setting of the registers SPI_CR2_TSIZE (LL_SPI_SetTransferSize),

So far I am just going with 8 bits and the spi.c that STM32CubeIDE generated for the F407 has this:
hspi3.Instance = SPI3;
hspi3.Init.Mode = SPI_MODE_MASTER;
hspi3.Init.Direction = SPI_DIRECTION_2LINES;
hspi3.Init.DataSize = SPI_DATASIZE_8BIT;
hspi3.Init.CLKPolarity = SPI_POLARITY_LOW;
hspi3.Init.CLKPhase = SPI_PHASE_1EDGE;
hspi3.Init.NSS = SPI_NSS_SOFT;
hspi3.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_4;
hspi3.Init.FirstBit = SPI_FIRSTBIT_MSB;
hspi3.Init.TIMode = SPI_TIMODE_DISABLE;
hspi3.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
hspi3.Init.CRCPolynomial = 10;
if (HAL_SPI_Init(&hspi3) != HAL_OK)

SPI_CR1_SPE (LL_SPI_Enable) and

I just enable the SPI, there does not seem to be any reason to deactivate it again after a transfer.
The only thing this seems to be doing is to waste time.
Oh yes, the SPI unit might be drawing less power when switching it on and off, but with a TFT I really do not
worry how much current the controller is using.

In my main.c I have this:
/* Initialize all configured peripherals /
MX_GPIO_Init();
MX_SPI3_Init();
/ USER CODE BEGIN 2 */
__HAL_SPI_ENABLE(&hspi3);
TFT_init();

/* USER CODE END 2 */

SPI_CR1_CSTART (LL_SPI_StartMasterTransfer).

Not sure what this is actually good for.

In the file EVE_target_STM32.h, data is written directly in the function spi_transmit(uint8_t data)
by calling LL_SPI_TransmitData8(EVE_SPI, data). Where is the SPI activated and the transfer started? Have I overlooked something?

LL_SPI_TransmitData8() does just that, it transfers one byte.
Well yes, the H7 is a bit special, for example the flags are TXE / TXNE on everything else, TXP and TXWNE on the H7 series.

I did not have the opportunity to see this fail myself, I only made it compile. ;-)
Hmmm, maybe I just should get me a NUCLEO-H755ZI-Q.

[C-Mon83]

Hi,

The use of the low level functions instead of the HAL brought a great improvement in SPI transmission. The initial side effects have been eliminated, the CLK is now nicely symmetrical and the idle states of MOSI and CLK are now also correct at the end of the transmission.
And thanks for the explanation of your SPI initialization. I couldn't see this as I only have the EVE sources in use.

The GPIO SPEED does indeed have an influence on stability. But in our case we had to set the SPEED of CLK, MOSI and MISO to SLOW to achieve an improvement. It seems that the display has a problem with a too fast rise time of the edge. It seems as if you have to find the optimum setting between cable lengths, transmission speed and GPIO speed. But in my opinion it should be more robust and not so sensitive to all these parameters.

My guess is that there is still a problem with the electrical wiring. There is still a behavior that is quite strange. The display can work reliably for a certain time. And suddenly, after the start screen, only a black screen appears. Now I have found out that the display works reliably again as soon as I connect the probe from the scope to the CLK line. This tiny capacitance seems to have a positive influence on the behavior of the circuitry.

We have already tried different constellations of SPI wiring. For example, using different resistors in series of the SPI lines (no resistance, 33 Ohm and 68 Ohm). In addition, our original hardware has a low-pass filter (TPD6F002) before the signals go to the connector. However, this should only operate at much higher frequencies (100MHz). However, this has been removed on a trial basis. So far, the variant without resistors in series and without the low-pass filter seemed to be the most stable. But with all variants there is still this strange behavior with the CLK line.

Another interesting discovery I made is that faulty transmissions often occur when the MISO line should change to HIGH at the first negative CLK and the MOSI line also changes to HIGH at the same time. The MISO line then either remains LOW or only a short peak is visible on the MISO line. It seems as if the slave wants to drive the MISO line but is unable to do so. Below are some examples that show this behavior:

In the examples above, the first two bytes in the response telegram on the MISO line (0x00 0x4A) are correct, after which the sequence is no longer correct.

I wanted to ask whether the sequence "0x00 0x4A 0x43 0x42" which is returned on successful transmission is documented anywhere? And are there any other sequences that are reported back by the display? For example, if the display has not understood the command from the MCU.

I wonder whether the errors are due to the display not understanding the signals from the MCU or whether the display is unable to send its response properly to the line.

To make the transmission more robust, we are working on an implementation that retransmits the data if the expected sequence (0x00 0x4A 0x43 0x42) is not returned.

Regards
Simon

[RudolphRiedel]

When I designed my first ARM board for use with EVE chips a while ago, it was also the first 3.3V board I used with a FFC 20pin header directly on the board and so I removed the voltage translator and drove the pins directly from the controller.
This did not work so well, I could only reach of few MHz before it stopped working.
I did place a series resistor and a capacitor on each line for a low-pass filter, but I could not find a combination of values that worked.
Eventually I found that the IO pins were just too weak to drive the lines at the desired clock speeds.
It was possible on this controller to route the same SPI to two different sets of pins at the same time and when I drove SCLK and MOSI from two pins each I could use higher clock speeds.

This is why I am using buffers now on my display adapter boards:
https://github.com/RudolphRiedel/EVE_display-adapter/tree/master/L-D5019-08

Yes, these do work as voltage translators, but more importantly the +/- 24mA output drive capability at VCC=3.0V exceeds anything I have seen so far in a 3.3V micro-controller.

Ok, this was not a STM32.
But checking the datasheet of the STM32H755, the output driving current is not that high either, at least not when you want the pins to actually operate at the supply levels.

And I can not exactly explain this as I do not trust my measuring equipment to be acurate enough.
Plus measuring the currents on the lines would be something else entirely.

The only adjustment to my boards so far was when I used the Teensy 4.x and found that it needed a 56R series resistor for the default IO pin configuration to work properly.
This was when I also removed the filter capacitor.
On my ARM boards I do drive CS and PD directly now with a 56R series resistor.
But MOSI and SCK go thru a 74LVC2G17 and MISO thru a 74VHC1GT125 with no resistors on the controller side.

The D5019-08-03 is what I will be using with the NUCLEO-H755ZI-Q I ordered.
And a D5019-08-02 is what I currently am using between the EVE3-50G and the STM32F407 discovery and what I used with a varity of different boards from different manufacturers.

[C-Mon83]

Hello

That sounds like the same problem we are struggling with. We have now found a setting that works reasonably stable, even with the low-pass filter (TPD6F002). Only one piece of hardware does not work reliably with a certain display. This still indicates that it is still very dependent on the individual characteristics of the connected hardware. Have you also experienced that not every display works equally reliably?

Thanks for the link to the adapter boards you are using. We will check whether we can improve our wiring in this respect.

To increase the reliability we would like to do a CRC check of the image data which we load into the graphic ram. Unfortunately, the read CRC (with CMD_MEMCRC) does not match the value that the controller calculates from the raw data. While searching how the CRC is calculated on the display, I came across the following post of yours (http://www.brtcommunity.com/index.php?topic=221.0). It is assumed that it is the polynomial 0x04C11DB7 (also known as 0x104C11DB7) with initial value = 0xFFFFFFFF. In the meantime, have you been able to find out more about CRC calculation on the display and has this polynomial been confirmed?

I have checked our implementation of the CRC calculation with an online CRC calculator and the said polynomial and the result is the same. I have calculated the CRC using the data from the *.rawh file, which is created by the EVE Asset Builder. Is my assumption correct that exactly this data is available in the graphic ram after unpacking?

As a check, I tried to read back the first 100 bytes from the address of the graphic from the graphic ram. All bytes read back had the value 0xFF?!

Regards
Simon

[RudolphRiedel]

even with the low-pass filter (TPD6F002).

That is interesting, but I wonder if it is a bit much after my experience with not suficient driving strength.
But then again, I can theorize and I can experiment, but getting accurate measurements if out of my reach.

Have you also experienced that not every display works equally reliably?

I am not using enough units of any display to even add a weak datapoint.
So far I got all of them to work and the only issues I usually have are with the software for a new controller.

To increase the reliability we would like to do a CRC check of the image data which we load into the graphic ram.

I also found that CMD_INFLATE does not work with corrupt data.

I came across the following post of yours (http://www.brtcommunity.com/index.php?topic=221.0).

I did not even remember this one.
It must have been the only time that I actually used CMD_MEMCRC and unfortunately there was no post from BRT, not even to confirm the polynomial and the starting value.
I asked for a confirmation.

I have calculated the CRC using the data from the *.rawh file, which is created by the EVE Asset Builder.

I am not using this file, I am not even sure why it is generated with the BIN2C in EAB tool offering a much better output.
But it should be the same, yes.

As a check, I tried to read back the first 100 bytes from the address of the graphic from the graphic ram.
All bytes read back had the value 0xFF?!

Other than with an all white image, this should not happen, not even with mangled values read on MISO.

On H755ZI I use SPI5 (K0 = CLK, J11 = MISO, J10 = MOSI); G7 = CS and E15 = PDN configured as GPIO Outputs

I received the NUCLEO-H755ZI-Q and it "only" has the 144 pin package while it looks like you are using the 176 pin package.
So I can not use the same pins.
I also was not aware that it is possible for a SPI to be on two different ports so my EVE_init_spi() function in EVE_target.c is "only" using a single macro EVE_SPI_PORT_NUM now.

Well, it looks like it is using too many macros already:

And the DMA macros are not even included, yet.

I still need to find a SPI to use on the Nucleo board.
According to the silkscreen PA5, PA6 and PA7 are routed to CN7, but the user manual shows that PB5 is at the header instead of PA7.
So no MOSI from SPI1.

[RudolphRiedel]

Hmm, I went with SPI4 on PE2/PE5/PE6, PD=PE3 and CS=PE4.
But although it compiles fine and the software is uploaded to the board, not even PF8 works which I configured as additional output pins for time measurements.
PF8 does not work with either the M7 or the M4.
Looks like I am missing something in STM32CubeIDE and the controller is not running.
The Clock Configuration also has no issues.
This is strange, the F407 just worked.

Edit: it starts to work, not the SPI, but at least the I/Os, I never actually built the M4 software and downloaded it but it looks like something must be running on the M4 for the M7 to work

Edit: ok, LL_SPI_StartMasterTransfer(EVE_SPI); must be used after LL_SPI_TransmitData8(EVE_SPI, data);
I find this to be rather annoying.
And instead of BSY I am using the EOT flag now, but it does not seem to work.

Getting there, but really wonder why the H7 does not work like the other families.

[RudolphRiedel]

I have the STM32H755 up and running and it works stable in my setup, had it running for hours by now.
But it really was a fight so far.
The STM32H755 is one of the fastest controllers I worked with so far and yet the SPI unit is one of the slowest I have seen so far.
In terms of clock-cycles, it takes practically forever for the flags to set, polling TXP, RXP and TXC is slow as heck.
Doing this "correctly" results in 522µs for the display refresh and 51µs for the touch part in my demo code - at 10MHz SPI clock.
I am running this on the M7 with 320MHz clock right now but it really is the peripheral.
That is about the same speed I get from an Arduino UNO running at 16MHz with 8MHz SPI.

Using this to send two bytes:

static inline void spi_transmit(uint8_t data)
{
    LL_SPI_TransmitData8(EVE_SPI, data);
    while (!LL_SPI_IsActiveFlag_TXP(EVE_SPI)) {}
    while (!LL_SPI_IsActiveFlag_RXP(EVE_SPI)) {}
    (void) EVE_SPI->RXDR; /* dummy read to flush RX FIFO */
}

Results in this:

The 1.64µs gap between the transfers is the result of the RXP flag to clear loooong after the transfer is done.
Even TXP takes forever, it clears when the transfer is about half done.
And TXC, yeah, same thing, does not clear when the transfer is done, but some time afterwards.

With some tweaking I got this down to 257µs / 39µs.
But this does not feel right, that this works might depend on configuration parameters.

This is a trace file for the startup plus two refresh cycles for the Saelea Logic2 software:
Startup_STM32H755.zip

Channel 5 is just an IO I setup to measure the timings

The STM32H407 is significantly faster, running at lower core clock and running the SPI also at 10MHz.

What I am trying now is to get DMA to work with the STM32H755.
But of course the DMA engine for the STM32H7 is also different.

[RudolphRiedel]

Something is still very wrong, but at least some bytes are transmitted by DMA now:

For some reason though the STM32H755 does not exactly transfer what is in the given buffer:

It should transfer 0xb0 0x25 0x78 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x02 0x07 0x00 0x00 0x26 and so on.
But there is 0xb0 0x25 0x78 0x00 0xff 0xff 0xff 0xff 0x00 0x00 0xff 0x00 0xff 0xff 0xc0 0x03 on the SPI.

I checked the buffer with the debugger, the data is correct.

[RudolphRiedel]

Another day, new ideas.

I got the non-DMA transfers down to 171µs/27µs with less trickery.
What I changed is to initialize the SPI with SPI_DIRECTION_2LINES_TXONLY and only switch for spi_receive() to SPI_DIRECTION_2LINES.

This gives a nice continous stream even when just polling TXP:

Oh yes, I also noticed that for some reason the optimization was set to -O0 while I am certain that I set it to -O2 before.
With -O0 it also works and I do get 245µs / 47µs now, so slightly faster on the write-only, slightly slower on the read/write than before.
-Os: 170 / 26

The DMA is getting stuck again after just two bytes though:

[C-Mon83]

Hello Rudolph,

Thank you for the feedback and the detailed function tests. Your findings with the settings to optimize the SPI transmission are very informative and helpful.
I am a bit surprised that the SPI unit of this controller is so slow. However, due to time constraints, we have not made any further effort to optimize the SPI stream. There are still pauses between the individual byte blocks and we are not using DMA.
Instead, we have implemented a retransmit functionality that retransmits the data if the expected byte sequence is not returned from the display. With the current implementation, such retransmits occur only rarely. Interestingly, it is often the CMD_DLSTART (0xffffffff00) which cannot be transmitted, even with the maximum number of retransmits (10 with 10ms delay). It seems to me that the display is not ready to start a new display list in this case. However, the error register does not contain an error.

I have found two solutions with which there are no retransmits in the current implementation.

Solution 1: As soon as the probe from the oscilloscope or logic analyzer is connected to the SPI CLK, the retransmits no longer occur. We have the same effect if we use a 10kOhm pull-down resistor on the SPI CLK. We have not yet been able to find out why this hardware hack has a positive effect on the transmission. In order to continue working on the implementation of the display screens, we will use this hack for the time being.

Solution 2: In your demo project I saw that you read the REG_CMD_DL for debugging purposes. So I also read this register after creating a new display list. In the good case, it contains 624 with the current implementation. If retransmits occur, this value is increased by 624 each time after the unsuccessful retransmits until the maximum value of this register is reached. This makes sense, as this value is set to 0 again by the CMD_DLSTART, which does not happen if the transmission does not work.
But it gets interesting when I read this register before creating a new display list. By reading out this register, there are no more retransmits with the subsequent CMD_DLSTART. It seems as if the display is ready to start a new display list by reading out this register. But even here it is still unclear why reading out this register has a positive effect on the transmission of the following display list. The register value read out is also 624, with a short update interval (e.g. every second). With a longer update interval (e.g. every 5 seconds), the value read out is 0. The reset should only be carried out with CMD_DLSTART according to programming guide. So why is it allready 0 at this time?

From time to time it happens that a graphic could not be transferred cleanly to the RAM_G. As a result, it is not displayed correctly. To avoid this, we will try again to implement the CRC check.

For the final product it is still unclear whether we will use the EVE display. Do you also have experience with other displays or is there a display that you can recommend to us in combination with the MCU used?

Regards
Simon

[RudolphRiedel]

Well now, except for DMA I have the STM32H755 working just fine here, it works for hours without an issue and I am not retransmitting anything,
When only writing the STM32H755 shows no pauses in my last iteration of my code due to the four bytes FIFO it has.
Writing and Reading is rather slow, yes, at least byte-for-byte.
But reading is usually not an issue since it is rarely required to read single 8, 16 or 32 bit values.

So, this is an issue with your hardware somehow.
Why a 10k pulldown resistor even makes a difference on a push-pull output is beyond me. Reflections perhaps.
But all I am using are really 56R series resistors and buffers with like 10cm of jumper wires between the STM32 boards to my display adapter and 10cm ffc cable to the display.

I am now using the STM32F407 again and it sits here at 170µs/17µs for the transfers.
But on the STM32F407 I got DMA to work.
And although I see with the logic analyzer that the time spend for the display update increases from 170µs to 185µs as I am using HAL_SPI_Transmit_DMA(), the time the controller core spends on the display update drops down to 10µs.

Here is a snapshot of what I did so far.
Today I decided to split things up for clarity and added EVE_target_STM32H7.h as well as adding a new section in EVE_target.c.

Edit: I just got back to using the H755 and I broke the code when I switched over to the F407, specifically EVE_target.c.
The archive is updated.
EmbeddedVideoEngine_STM32.zip

Still a lot more to do, including testing it on the STM32C031 for example.

And what I have not tried so far is to run the display code on the M4 of the STM32H755, I was only using the M7.
The issue with DMA might be related to the caches of the M7.

[C-Mon83]

Hello Rudolph

Thanks for the update on your progress with the STM32 boards.

Over the last two weeks we have been able to move forward and complete the implementation of the display screens.

Occasionally it still happens that the display suddenly freezes. In this state, the display still communicates normally with the controller, but no longer updates the image. Only after reinitialization does the display show the correct screen again. We are still working on finding out how this error occurs and why the display still communicates normally but no longer updates the screen.

In the meantime we were able to implement the CRC check of the loaded images in RAM_G. I can confirm that the CMD_MEMCRC function calculates the CRC with the polynomial you assume:

• Polynomial: 0x4C11DB7
• Initial Value: 0xFFFFFFFFFF
• Final Xor Value: 0xFFFFFFFFFF
• Input reflected: yes
• Result reflected: yes

We have precalculated the CRC of the raw data (*.rawh) of all images and compare the CRC value after the Inflate command. If the CRC is incorrect, we transfer the image again. We did the pre-calculation with the online calculater sunshine2k (http://www.sunshine2k.de/coding/javascript/crc/crc_js.html):

This allows us to ensure that the images are displayed reliably (without faulty fragments).

I would like to take this opportunity to thank you once again for your support. You helped us a lot and always responded quickly. Such support is difficult to find these days. Thank you very much!

Kind Regards
Simon

[RudolphRrr]

Hello,

Occasionally it still happens that the display suddenly freezes.
In this state, the display still communicates normally with the controller, but no longer updates the image.

Yeah, the kind of esoteric issue that we all love.
Have you checked the return value of EVE_get_and_reset_fault_state()?

We did the pre-calculation with the online calculater sunshine2k

Yup, that is the one I am using occasionally as well.

I would like to take this opportunity to thank you once again for your support.
You helped us a lot and always responded quickly. Such support is difficult to find these days. Thank you very much!

I am just having fun over here. :-)
Especially I like the challenge to work with all the different controllers.

Well, STM32H7 and DMA did not work and I still do not know what the issue could be.
Oh yes, I also used the M4 core, made no difference.

So I updated the repository to what I had.

Then I ordered more STM32 eval boards, only to find out then that the two new ones I chose also use the newer DMA engine.
Well, this is kind off where I left things and took a break.