SPI speed: huge difference between FX3 SDK and FX3 bootloader

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi,

   

I am wondering why the difference between the clock speed and the byte replay is that huge when I use libsdk or libbootloader.

   

I have some screenshots and initializing code append in the pdf document.

   

thanks,

   

lumpi

0 Likes
12 Replies
Anonymous
Not applicable

Hi Lumpi,

   

That is a very good observation. It is a mistake from our side.

   

The Boot API is setting to the SPI interface clock to half of the frequency specified by the user. This is why CyFx3BootSpiReceiveWords works slower. We will get this fixed in the next release. Please specify double the required frequency for now. There is no bound check in the CyFx3BootSpiSetConfig code, and it will be possible to request a higher frequency.

   

Thanks,

   

Sai Krishna.

0 Likes
Anonymous
Not applicable

 Hi Sai Krishna,

   

thank you very much for the answer that will be fine for me to set double of frequency, great! 

   

But that would not perform that faster then. The bigger issue is, that between two transfer bytes there  is a delay of about 15us in case of bootloader lib and in case of the sdk lib there is just a bit more than 1us (take a look to the pdf document I appended in my previous post). I think the "long" time (1us) of the sdk version is a result of threadx OS but in case of bootloader lib I thought there is no threadx running. So that should be way faster! I believe in case of the bootloader lib a software SPI using the GPIO api will be faster than the peripheral SPI of the bootloader lib.

   

Do you also have such a nice workaround for that? It would be awesome.

   

regards,

   

lumpi

0 Likes
Anonymous
Not applicable

Hi,

   

any updates on this?

   

thanks,

   

lumpi

0 Likes
Anonymous
Not applicable

Hi Lumpi, 

   

The delay between words on the regular API has nothing to do with ThreadX. It is just plain software delays due to the need to check for various error conditions etc. In the boot library, we have a poll loop which inserts some delay between each check of the status register. This is why there is a long latency between operations. We will fix this along with the frequency issue. We can give you a test drop of the API. 

   

Finally, we will not be able to get a faster GPIO based SPI. The maximum frequency that the CPU can toggle a pair of GPIOs at will be under 10 MHz. It is not possible to go faster than this with the FX3 GPIOs. 

   

Thanks,

   

Sai Krishna.

0 Likes
Anonymous
Not applicable

Hi Sai Krishna,

   

thank you very much for your great support. A test drop would be great, how can we exchange it?

   

 

   

>> Finally, we will not be able to get a faster GPIO based SPI. The maximum frequency

   

>> that the CPU can toggle a pair of GPIOs at will be under 10 MHz. It is not possible

   

>> to go faster than this with the FX3 GPIOs.

   

What should that tell me? I thought the SPI is a peripheral hardware interface in the FX3. Do you like to tell me, that the control of that peripheral needs the GPIO api and because of that it is limited?

   

thanks,

   

lumpi

0 Likes
Anonymous
Not applicable

Hi Lumpi,

   

I will send you an email once that fix is ready. May be then you can create a support case to get that.

   

No. I was not talking about the SPI hardware module present in the FX3. I was talking about SPI implementation using GPIOs. I was saying that if you go for GPIO bit banging implementation then we cannot have better performance numbers because the CPU can toggle a pair of GPIOs at will be under 10 MHz.

   

Thanks,

   

Sai Krishna.

0 Likes
Anonymous
Not applicable

Hi Sai Krishna,

   

I have actually opened a support case to exchange the test drop.

   

regards

   

lumpi

0 Likes
Anonymous
Not applicable

Hi,

   

Just to update you all...

   

All the issues that were listed above are solved and these changes will be part of next release of FX3 SDK.

   

Thanks,

   

Sai Krishna.

0 Likes
Anonymous
Not applicable

Hi Sai Krishna,

   

when will be the next release of FX3 SDK?

   

thanks,

   

lumpi

0 Likes
Anonymous
Not applicable

Hi Lumpi,

   

 

   

We are planning to release it in a time of 3 weeks from now. Most probably first week of next month, if everything goes as per the plan. 

   

 

   

Thanks,

   

Sai Krishna.

0 Likes
Anonymous
Not applicable

Hi Sai Krishna,

   

good to know, thank you very much.

   

regards,

   

lumpi

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi , was finaly able to get SPI to work today (after week of lot of cursing ... until i find a stupid bug on my side)

   

using CYUSB3014 (DVK board CYUSB3KIT-001)

   

recently reinstaled to FX3 SDK 1.2.3

   
- btw that w7 x64 bug on missing include path still persist but copy entire cypress folder from Program Files x86 to Program Files help
   
- USB enumeration after firmware uload  works fine now 🙂
   
- also Eclipse post build conversion from elf to img works now 🙂
   

I am new to SPI so if i am incorrect please correct me  (usualy using more paralel  interfaces but GPIF II does not suits my needs at all so SPI is the only fast enough peripherial left on CYUSB3014)

   

I tryed find the best speed possible so my final config is as this:

   

CyU3PSpiConfig_t spiConfig;
spiConfig.isLsbFirst = CyFalse;
spiConfig.cpol = CyTrue;
spiConfig.ssnPol = CyFalse;
spiConfig.cpha = CyFalse;                          // only to use zero lag time
spiConfig.leadTime = CY_U3P_SPI_SSN_LAG_LEAD_HALF_CLK;
spiConfig.lagTime = CY_U3P_SPI_SSN_LAG_LEAD_ZERO_CLK;
spiConfig.ssnCtrl = CY_U3P_SPI_SSN_CTRL_FW;
spiConfig.clock = 1000000;                         // this is only temporary for more acurate measuring on osciloscope
spiConfig.wordLen = 32;
CyU3PSpiSetConfig(&spiConfig,NULL);
 

   

after some measuring i found this (see SPI.jpg)

   

SCK runs on double frequency now (do not know if this is the case for older SDK) 2MHz instead of 1MHz

   

SPI timing :

   

SPI init time before transfere 9us

   

32bit word transfere 16us instead of 32us 

   

synchronisation gap 2us (lead + tssnh + lag time i assume) ... this confuses me a lot:

   

1.  ssnCtrl has no  effect on this,... gap is present even if SSN control is NONE !!!

   

2. if the gap is  (lead + tssnh + lag time)   then it should be 0+tssnh+0.5us. ok but how long is tssnh and how i can change it? Datasheet says only that tssnh >= 10ns and that is it all.

   

Also i find that SPI works stable on my board with seting SCK = 25 MHz  whitch actualy now runs on 50MHz !!! (datasheet limits SPI to 32MHz or 33MHz), on 30MHz setting (60MHz actualy) it works too but not stable ... sometimes do not start.

   

 

   


 

0 Likes