FT813_Riverdi Display 7 inch

[Overkooked-fff]

Hello RudolphRiedel,

I recently bought this LCD : https://riverdi.com/product/rvt70aqffwc00/

And Riverdi click adapter : https://www.mikroe.com/riverdi-click

MCU: NXPS32K148

I want to get works the display with NXPS32K148 mcu . But it does not work yet.

I would like to use your library but, I have some questions before all. Is my HW ok for getting work this display? Which one of your library could be more adapted to my mcu target?

Thank you in advance for your help.
Best Regard,
Milad

[RudolphRrr]

Hello,

the RVT70 is supported, in fact I have one running here one desk over for a week now as HMI for a control unit under test.
But I am not sure regarding the riverdi click.
This is just a passive adapter in a specialised form factor.
If this works would depend on how fast you are driving the SPI and if your controller is capable of providing enough power to drive the SPI at the desired frequency.
And then there might be an issue with providing enough current for both the 3.3V logic-supply and the 5V supply for the backlight.

My adapter boards ( https://github.com/RudolphRiedel/EVE_display-adapter ) are all active and have at least a 3.3V step-down regulator.

I do not have hands on experience with the S32K series (yet) but I do have an eval board with a S32K144.
Right now I do not even know what I would need to build software for it, apart from GCC, obviously, I have not tried it, yet.

What needs to be changed is in EVE_target.h.
I hope the different targets in there provide a good example of what needs to be done, mostly these are hardware specific one-line functions.
In a second step EVE_target.c would be the file in which DMA support is added.

[Overkooked-fff]

Hello,

Thank you for your explanation.

I will try a software for my S32K148 MCU and come back to you.

First of all, I have another question, what is the role of the PD pin? Is it necessary to operate the display? because I don't have a PD pin on the riverdi click adapter.

BR,
Milad

[RudolphRrr]

PD is used by EVE_init() in EVE_commands.c to send the display thru a power-cycle in order to make sure that all registers are resetted to their default values.

At the beginning of EVE_init() there is one line commented out:
/* EVE_cmdWrite(EVE_CORERST,0); / / reset, only required for warm-start if PowerDown line is not used */

[RudolphRrr]

I just found the thread on the FTDI community forum and their assesment that the adapter does not match the display is wrong.
I am not sure what pin 9 "MODE" is supposed to be but this is not connected on the display side.
The Riverdi Click is missing pin 10 for Audio out.
Other than that the adapter is a match for the display.

And pin 8 on the Riverdi Click is labeled "RST", this pin is the PD pin on the display, this connects to pin 12 on the EVE chip:
"PN_N Chip power down mode control input, active low. Connect to MCU GPIO for power management or hardware reset function,"

[Overkooked-fff]

Thank you for your update,

• I checked with Riverdi about Click board, they confirmed me that both display and Riverdi click use same Ribus interface so they do match.

• They said that I should have 5v for backlight and 3.3V for VCC. Shall I connect both power supply to display? or one is enough?

• Another question is that , Shall I use a GPIO pin for CS# ?or shall I use the CS# of SPI ?

[RudolphRrr]

You need both the logic supply and the backlight supply.
Be aware that the display draws up to 130mA from the 3.3V supply and 550mA (at 5V) from the backlight supply, depending of course on the level the backlight is set to and the ratio of active to not-active pixels.

A smaller display like the EVE3-50 from Matrix Orbital could be used with only 3.3V.
And on the other side I am using a RVT101HVBNWC00-B with two step-down regulators and have the one for backlight set to 8.2V since the RVT101 supports a hight backlight voltage and a higher voltage brings down the current.

I am using a GPIO for CS in my library as I am supporting a wide range of controllers of which at least half do not have hardware support for the SPI CS line.
And then there are controllers that do have hardware support for SPI CS line but only for single byte transfers.

[RudolphRiedel]

I am trying to make use of the S32K144EVB I have but so far this only provided the worst experience I have ever had with a new eval board.
I had to use a NXP account to download this "free" software with "unlimited" use and had to use an activation code that
I received by mail in order to install it. And this "unlimited" and free license expires in four years.
The "Get Started" page for the S32K144EVB is way outdated.
The S32 Design Studio for ARM V2.2 from 2020 installs a FreeMaster 2.0 software from 2015 which can not connect to my board.
The FreeMaster 3.1.2.4 which I downloaded additionally with an extra activation code can not connect to my board either.
Downloading software from PEmicro also requires a login. And the supplied driver states in the debug settings "Please register your software to remove this message."
The PEmicro page offers version 12.4 of the driver from 2017 while the driver supplied with S32 Design Studio is 12.7 from 2020.
Unbelieveable.
Ok, I am installing S32DS 3.4 now with not much hope for this one either.

[Overkooked-fff]

It's good that you have started using the S32K144EVB. I'm sure you will find a solution.
It's weird this difficulty to install SWs, I never had any difficulty to install SWs.
First you should create an account on NXP website, then you try to install the SW like this:
Design--> All swftware --> S32 design studio for Arm --> Download --> select the latest version and click download. You will then get the activation key to install the software, too. S32 design studio and PEmicro will install on your pc normally.
If you need help to install the software, don't hesitate.

On my side I tried to integrate your library in S32 design studio but I have an error with EVE_commands.c. It could not be saved, I don't know why...

[RudolphRiedel]

Well, I already had an account with NXP and S32DS 3.4 kind of works now.
Kind of, since I can compile an example and put in on the board with "Debug" but just flashing it to the target with "Run" does not work.
I really do not like eclipse and S32DS does nothing to change my mind.

At least I can try to make it compile now.

[RudolphRiedel]

Now that it compiles I started to expand the "hello_world_s32k144" example.
The first thing to do is to add code for the target controller which is done mostly in EVE_target.h and partly in EVE_target.c.

In order to do so you need to either find defines for the target controller that are already set in the development enviroment or add defines.
Now we know that the compiler used for S32K is GCC so the new target goes into the section within
#if defined (GNUC) / #endif
The build settings for the "hello_world_s32k144" example show defined symbols in the preprocessor section:
CPU_S32K144HFT0VLLT
And going thru the includes in the dependency tree we find "device_registers.h" which has this line:
#if (defined(CPU_S32K148) || defined(CPU_S32K146) || defined(CPU_S32K144HFT0VLLT) || defined(CPU_S32K144LFT0MLLT) || defined(CPU_S32K142) || defined(CPU_S32K142W) || defined(CPU_S32K144W))

So I added a new target in EVE_target.h like this:

/----------------------------------------------------------------------------------------------------------------/
/----------------------------------------------------------------------------------------------------------------/

#if defined (CPU_S32K148) || (CPU_S32K144HFT0VLLT)

#include "pins_driver.h"
#include <stdint.h>

#define EVE_CS_PORT PTD
#define EVE_CS 15
#define EVE_PDN_PORT PTD
#define EVE_PDN 16
...

It does not do anything usefull so far but it compiles just fine.
The SPI is not initialised, the SPI functions in EVE_target.h are all empty and the pins selected for CS and PDN are the ones from the build-in LEDs on the eval board.
But it calls TFT_init() in main() and compiles fine so far.

Now I have to check the board documentation to find out which pins could be actually used for CS, PDN and the SPI.

src.zip

[RudolphRiedel]

I checked the pinout for the S32K148EVB.
S32K144EVB S32K148EVB
J2.11 PTB2 J2.16 PTB2 SCK
J2.9 PTB3 J2.13 PTB3 SIN
J2.7 PTB4 J2.10 PB1 SOUT
J2.5 PTB5/CS1 PTB0/CS0
J2.3 PTD14 PTA30 EVE_PDN

So yeah, they put a different pin for SOUT on the header and a different chip-select pin.

[Overkooked-fff]

Yeah , they are different :-(

Thank you for the pinout selection 👍

[RudolphRiedel]

Hmm, I hooked up the S32K144EVB to one of my adapter boards and to a display.
And it kind of works, I can see the traffic on the SPI from the display and it looks okay.
But somehow a co-processor fault is detected in EVE_busy() although the data on the SPI does not support this and consequently EVE is send into a software-reset.
Reading from the SPI does not seem to be working properly.

[RudolphRiedel]

And it is up and running for the first time now. :-)

This is so not ready for release yet, more proof of concept.
The last issue was that my SPI functions read the receive FIFO before the transfer was actually finished and therefore there was a shift by one byte.

SPI_s32k144.zip

The main.c is a joke and I am not sure what to do with the EVE_init_spi() - probably remove it.
And I consider the NXP SPI driver to be completely unuseable for this type of operation as it is way too slow.

The display in the picture is a RVT50UQQBNWC01 which is the closest one to the RVT70AQ I have here.
I also tried an EVE3-50G and it worked as well.

Next is DMA support.
I am not yet sure if this works with DMA yet since I read somewhere that there is a limit of 5xx bytes for DMA and there might be an issue with the 3 + x * 4 bytes needed to be send as in this is always an odd number.
I hope the 5xx vytes were a limitation of the example code I saw.

[RudolphRiedel]

This is interesting:
https://source.codeaurora.org/external/s32support/s32k144_cookbook/tree/

These examples from NXP do not use their peripheral drivers.

[RudolphRiedel]

This is a cleaned up version:
SPI_s32k144.zip

I removed the odd SPI driver from NXP after reworking the EVE_init_spi() with inspiration from example code from NXP.
I left in the pin configuration code from NXP since this one does not seem to have any dependencies.
After removing the SPI driver from NXP I could remove the unused RTOS functions as well which made it possible again to use the ARM systick timer in my main.c although I am still surprised that NXP is not providing proper CMSIS headers.

And I removed the now unnecessary defines for the pins in EVE_target.h.

Two things are a bit alarming, one is the still rather low clock speed of the SPI.
I have set it up to about 2MHz now.
Usually I would go with 8MHz but for one I find the clock settings rather strange and then I get issues like the touch no longer
working at higher clock speeds.
The other thing is that I need this for SPI transfers now:

static inline void spi_transmit(uint8_t data)
{
EVE_SPI->SR |= LPSPI_SR_RDF_MASK; /* clear Receive Data Flag /
EVE_SPI->TDR = data; / transmit data /
while((EVE_SPI->SR & LPSPI_SR_RDF_MASK) == 0);
(void) EVE_SPI->RDR; / dummy read-access to clear Receive Data Flag */
}

So far I have not found a way to ignore the received data for transmit-only operations.
This is a concern since transferring buffers of up to 4k for a display refresh in DMA mode is ideally a write-only operation.

[RudolphRiedel]

To answer myself, I found RXMSK in the TCR register now which, when set, disables the SPI receiver.

As a pre-cursor to DMA this version is running like it is supporting DMA but the EVE_start_dma_transfer() function
is actually sending the DMA buffer in write-only blocking mode.

SPI_s32k144.zip

The first shot is an overview of one TFT_touch() call followed by one TFT_display() call.
The second one is a normal transfer with activated read and the third picture shows the difference when switching over to write-only.

Does this make a whole lot of a difference?
No, not really, sending the 223 bytes of the demo code takes 1.69786 ms in write/read mode and 1.56232 ms in write only mode.
But I found this was interesting enough to share, the pause between the SPI transfers is not really caused alone by the core of the controller running the loop but the the state-machine in the SPI unit is contributing significantly to it.

I also reduced TCR/PRESCALE now from 2 to 1 and then 0.
And the pause between transfers in write/read mode got shorter.
From 1.6µs to 1.1µs to 0.8µs.
In the write only tranfers the pause also got shorter.
From 540 ns to 260ns to 120 ns.

Running the SPI at ~8MHz now reduces the time needed to transfer the buffer to 391µs.

[RudolphRiedel]

Damn, I am stuck with this DMA engine.

As a next step this one should transfer the buffer with DMA and wait for completion.
It kind of works, the transfer is started alright and after completion the program continues.

I am only getting one byte of the DMA though.

SPI_s32k144.zip

The SPI is setup for byte transfers and so I configured the DMA to use bytes as well.
The DMA engine works with a two loop systems, minor loops and major loops.
The minor loop is setup to a transfer size of "1" now and the amount of major loops
is setup to the size of the buffer in bytes.
But somehow it stops after just one minor loop.

When I increase the amount of bytes per minor loop more bytes get transferred on the SPI.
But only a fraction of the amount setup and the bytes that are send are not what is in the buffer.
I just setup 122 bytes and the result is 11 bytes on the SPI.
1 -> 1
2 -> 2
3 -> 3
4 -> 4
5 -> 4
6 -> 4
7 -> 5
8 -> 5
9 -> 5
10->5
11->5
12->5
13->5
14->5
15->5
16->5
20->5
22->5
23->5
24->6
30->6

What is this DMA engine doing and why?

[RudolphRiedel]

I got some help from NXP or rather they pointed me in the direction of annother SPI/DMA example I was not aware of so far.

And this is the first version that transfers the buffer for the screen update with DMA:
EVE_Test_S32K144.zip

It still does busy-wait for the DMA to complete, to finish this I still need to add the DMA-done interrupt.

[RudolphRiedel]

Now this was easier than I thought it might be.

This one is using an DMA-done interrupt:
EVE_Test_S32K144.zip

Edit, I merged the changes and released new versions of EVE_target.c and EVE_target.h.

[Overkooked-fff]

Thank you for your updates and great job.
I was traveling and couldn't follow you.

[RudolphRiedel]

This was an interesting opportunity to actually do something with the S32K144 I bought a couple of years ago and at the same time I know we currently have a project in my department at work with a S32K14x (that I not really was involved in, yet).
If I am asked this is annother family I played with. :-)