Hi,

thanks for your effort!

greetings!

I took some more captures. I noticed that the delay between the addressing bytes is in single mode ~260ns besides ~1us in quad mode. Could this already cause trouble, that the chip isnt recognizing the addressing sequence at all?

Enclosed some more captures.

• QSPI Reg Id complete transfer sequence 32us
• SSPI REG_SPIWIDTH changing to QSPI and two dummy bytes
• SSPI delay between adressing bytes 260ns
• QSPI delay between adressing bytes 1us

Thanks for your help and best regards

Hi.
Thanks for your reply and the advise about the SampleApp, I checked it already but the involved routines are identicial the the ones I´m using. I forgot to mention that I´m using an Infineon XMC4500 MCU.

The reconfiguration of the REG_SPI_WIDTH is done twice during Eve_BootupConfig().

Enclosed the code of my boot sequence.

I can also provide some pictures from the logic analyzer, if this helps.
The LA shows, that the adressing is send out correct in QSPI and after some delay where the bus isnt driven from MCU or GPU the MCU sends 0xFF to provide the GPU with a clock to send out data.
For the REG_ID it performs Ft_Gpu_Hal_Rd8() where I read (host->spinumdummy + 1) from the GPU and om QSPI 2DUMMY my MCU sends 3 time 0xFF. The sequenz is SEND(0xFF) READ(QSPI) therefore I think the IOs are not blocked for the GPU and if the GPU would send data while the MCU sends 0xFF I could identify it trough missmatching signal levels on the IO lines.


Thanks for your help!


Ft_Gpu_Hal_Powercycle(s_Host, FT_TRUE);
Ft_Gpu_Hal_SetSPI(s_Host, FT_GPU_SPI_SINGLE_CHANNEL, FT_GPU_SPI_ONEDUMMY);

Ft_Gpu_HostCommand(s_Host, FT_GPU_EXTERNAL_OSC);
Ft_Gpu_Hal_Sleep(300);
Ft_Gpu_HostCommand(s_Host, FT_GPU_ACTIVE_M);
Ft_Gpu_Hal_Sleep(300);

ft_uint8_t chipid;
chipid = Ft_Gpu_Hal_Rd8(s_Host, REG_ID); //This REG_ID in Single SPI is read correct


/*Display Setup */
Ft_Gpu_Hal_Wr16(s_Host, REG_HCYCLE, FT_DispHCycle);
Ft_Gpu_Hal_Wr16(s_Host, REG_HOFFSET, FT_DispHOffset);
Ft_Gpu_Hal_Wr16(s_Host, REG_HSYNC0, FT_DispHSync0);
Ft_Gpu_Hal_Wr16(s_Host, REG_HSYNC1, FT_DispHSync1);
Ft_Gpu_Hal_Wr16(s_Host, REG_VCYCLE, FT_DispVCycle);
Ft_Gpu_Hal_Wr16(s_Host, REG_VOFFSET, FT_DispVOffset);
Ft_Gpu_Hal_Wr16(s_Host, REG_VSYNC0, FT_DispVSync0);
Ft_Gpu_Hal_Wr16(s_Host, REG_VSYNC1, FT_DispVSync1);
Ft_Gpu_Hal_Wr8(s_Host, REG_SWIZZLE, FT_DispSwizzle);
Ft_Gpu_Hal_Wr8(s_Host, REG_PCLK_POL, FT_DispPCLKPol);
Ft_Gpu_Hal_Wr16(s_Host, REG_HSIZE, FT_DispWidth);
Ft_Gpu_Hal_Wr16(s_Host, REG_VSIZE, FT_DispHeight);
Ft_Gpu_Hal_Wr16(s_Host, REG_CSPREAD, FT_DispCSpread);
Ft_Gpu_Hal_Wr16(s_Host, REG_DITHER, FT_DispDither);

/* Touch configuration */
Ft_Gpu_Hal_Wr16(s_Host, REG_TOUCH_RZTHRESH, RESISTANCE_THRESHOLD);


/*IO Setup*/
Ft_Gpu_Hal_Wr16(s_Host, REG_GPIOX_DIR, 0xffff);
Ft_Gpu_Hal_Wr16(s_Host, REG_GPIOX, 0xffff);

/*Init Screen*/
Ft_Gpu_Hal_WrMem(s_Host, RAM_DL, (ft_uint8_t *)FT_DLCODE_BOOTUP, sizeof(FT_DLCODE_BOOTUP));
Ft_Gpu_Hal_Wr8(s_Host, REG_DLSWAP, DLSWAP_FRAME);

Ft_Gpu_Hal_Wr8(s_Host, REG_PCLK, FT_DispPCLK);//after this display is visible on the LCD

Ft_Gpu_Hal_SetSPI(s_Host, FT_GPU_SPI_QUAD_CHANNEL, FT_GPU_SPI_TWODUMMY);
//Here I change my MCU to Quad SPI
ft_uint8_t u8ChipidQSPI
ft_uint8_t u32ChipidQSPI
u8ChipidQSPI = Ft_Gpu_Hal_Rd8(s_Host, REG_ID); //This REG_ID in QSPI only read
u8ChipidQSPI = Ft_Gpu_Hal_Rd32(s_Host, REG_ID); //This REG_ID in QSPI only read



Hi Rudolph,

thanks for your feedback and the good summary about interrupt handling and its pitfalls/design consideration.
I will check your library and see if I can gain more insight for my project.

I forgot to mention, that my system runs an OS and the Gui has the lower priority for the scheduling. Thats actually why I considered an interrupts approach first because I think it´s better to implement than adapting the entire timing for the scheduling. But I´m at the very beginning of the interrupt implementation.

I´ll keep this thread updated with my progress maybe some might be interested in it too and also leave some lessons learned to posterity

Cheers!