BRT Community
General Category => Discussion - EVE => Topic started by: mallok05 on February 14, 2020, 04:07:56 PM
-
Hi everyone,
I can´t get my FT810 in QSPI Mode running. In single mode it´s perfectly working but as soon as I change to qspi nothing works.
I checked the entire data stream with an logic analyzer. For me it seams, that in quad, the ft810 never starts to send any data back.
The SPI_WIDTH register is correct addressed with the needed paramter (0x2 for qspi 1 dummy, 0x6 for qspi 2 dummy), thats what I still can see with the LA becuase it´s in single mode.
The register I´m trying to read it REG_ID because for my unterstandig this should be a good reference to verify if qspi reads proper results.
It´s approx 7us from the last address byte to the receive procedure of my MCU, but I can´t see any usefull data comming form the ft810.
Does some have have FT810 or BT816 running in QSPI?
Im using a EVE4.5 GUI with the corresponding EVE Framework.
Thanks for any help you guys can provide!
Cheers!
-
Hello,
Can you let me know what your initialization sequence is and at which point you are setting the REG_SPI_WIDTH register?
Our main 'Sample App' at the following link can be configured to use Quad SPI via the 'platform.h' file, it supports our USB to SPI solutions (FT42222 or MPSSE) and our FT9xx series of MCUs:
https://www.ftdichip.com/Support/SoftwareExamples/FT800_Projects.htm (https://www.ftdichip.com/Support/SoftwareExamples/FT800_Projects.htm)
Best Regards,
BRT Community
-
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
-
Hello,
The logic analyser captures would be useful if you could provide these.
Do they include the CS# line?
Best Regards,
BRT Community
-
Hi,
sorry for my late response!
Enclose you´ll find the QSPI caputre of reading REG_ID.
Unfortunately its not possible to put everything to one screen so I splitted it in the interessting parts.
- SS till 1st CLK 70ns
- Dummy sequence between falling edge of last 12,78us
- Clocking out GPU response 3,15us
- Last falling edge of GPU response Clks till SS unassert 12,5us
- complete QSPI RED_ID sequence 31,94us
-
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,
I just wanted to ask, if theres some feedback regarding the qspi issue?
Thanks + greetings!
-
Hello,
I had passed this on to the development team to have look at but I haven't had a reply yet.
I will chase them up for you.
Best Regards,
BRT Community
-
Hi,
thanks for your effort!
greetings!
-
What microcontroller are you using? What's the SPI clock speed? I have been successful with a PIC32 but it took a while to figure it out.
ate