TMS320F28379D: SPI 40MHz

Hi Vince,

I will get back to you with a response on this thread tomorrow.

Best Regards,

Delaney

Hi Vince,

Apologies for the delay. Is the CPU writing the data to transmit consecutively in the code? It seems odd that it wouldn't write it fast enough - what SYSCLK frequency do you have configured? It may help if I could see your code logic as well.

Best Regards,

Delaney

Hello  Delaney,

Thank you for coming back to me.

Assuming that Tabuint16_TabSPITest does contain bytes that I need to transmitt with SPI, the way I trigger a transmission is:

This code is written in an ISR, for the test. So, there is not any other ISR that interrupts the fillong of the SPI buffer.

This code does work as expected at 10Mhz.

I already checked the SPI frequency.

To set it:

- I set the prescale for the LSPCLK at 1 in Device_init() function, which is called at the beginning of the CPU1 programm

- I also set the DEVICE_LSPCLK_FREQ symbol in device.h, because the SPI driverlib function will use this for the configuration of the SPI module

- In SysConfig, I declare the same configuration. This allows SysConfig to check options I choose

At 40MHz, it needs only 200ns to send a byte, 

Using DriverLib in emulation mode, I think it is not that odd that I need 40 instructions to transfer a byte into the SPI buffer:

What do you think ?

Hi Vince,

Thank you for your reply, I will look into this and get back to you in 1-2 days.

Best Regards,

Delaney

Hi Vince,

Apologies again for the delay on this. Are you still seeing the issue?

If it only takes 40 instructions to write each byte of data to the TX buffer, that should be around 50ns (assuming two clock cycles per instructions which could vary). Even then, it is far less than the time it would take to transmit that byte - 200ns. You can also check the exact number of cycles using the Clock feature in CCS if you would like: Counting Cycles.

I don't know of a way to block the transmit after the TX FIFO is written, it will start shifting the data out automatically.

Thanks,

Delaney

Hi Vince,

Another note, on this device, the maximum GPIO switching frequency for most GPIOs is 25MHz. In order to reach a SPI frequency of 40MHz, you'll need to configure the high-speed mode in the module and use one of the high-speed GPIOs. Is this what you are doing?

Best Regards,

Delaney

Hello Delaney,

Yes, I ve been actually seeing this issue.

You're right, 50ns would be enough to fill the buffer, but the programm manages many interrupts. The solution was to forbid the interrupts while filling the buffer, but I am always afraid that I miss one interrupt doing that (I opened an other thread about that issue)

Your tip about the cycles counter will be very useful, thank you.

Your answer about the non blocking transmitt is clear, that's what I wanted to know.

By the way, yes, I configured the High speed mode as specified.

Could I ask an other question before to close this thread?

I want to manage the CS pin (PTE) manually (on my own). But Sysconfig does not allow me to free this pin. I mean, to do that I had

1) to choose a pin which is not used in my application (GPIO23)

2) to declare a GPIO, which was initially the SPI_PTE

This way to do has many drawbacks:

- A GPIO, reachable by the SPI module, has to be free in the application

- These GPIO are rare if we need to use the High Speed Mode: in my example, in have to declare the GPIO66 as PTE (23 is not reachable)

Is there a way to not declare any pin for PTE with Susconfig, just as we can do with PWM modules, with the Custom Pin use functionnality:

Thank you Delaney

I feel dummy :) I swear I looked at this option !!!

Thank you Delaney. Speak you soon