This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SSI Clock speed issues

Other Parts Discussed in Thread: TLC5940

Hello again!


I am once again having problems using the SSI interface on the launchpad.

I initialize the SSI intrface with the following code:

	// Run on 80Mhz
	SysCtlClockSet(SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN | SYSCTL_USE_PLL | SYSCTL_SYSDIV_2_5);

	SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI0);
	SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);

	GPIOPinConfigure(GPIO_PA2_SSI0CLK);
	GPIOPinConfigure(GPIO_PA4_SSI0RX);
	GPIOPinConfigure(GPIO_PA5_SSI0TX);

	GPIOPinTypeSSI(GPIO_PORTA_BASE, GPIO_PIN_2 | GPIO_PIN_4 | GPIO_PIN_5);


    GPIOPinTypeGPIOOutput(GPIO_PORTA_BASE, GPIO_PIN_3);

	// Set clock source and speed
    SSIClockSourceSet(SSI0_BASE, SSI_CLOCK_SYSTEM);	// Set clock source
	SSIConfigSetExpClk(SSI0_BASE, 80000000, SSI_FRF_MOTO_MODE_0, SSI_MODE_MASTER, 20000000, 8);		// Configure as SPI master with a speed of 20MHz

	// Enable the SSI module
	SSIEnable(SSI0_BASE);


When sending data over SPI the clock looks like there are some issues with the rising/falling edges of the clock:

When going to higher speeds (10MHz):

Even higher speeds are no longer usable!

What is the problem here? I need to run on at least 20MHz, is this even possible?. 

I have tried on several launchpads all with the same result. There is no hardware connected to the pin (except for the measurement probe),just the launchpad straight from the box.

Any hints? am i just being silly in trying to do something that can't be done?

Fransisco

  • Hi Fransisco,

    This is normal, at this speed you need a higher current drive because of the capacitance. You would need a amplifying circuit if you wanted to use that kind of SSI speed with long wires due to increassing capacitance.

    I also first used the osciloscope to check the SSI CLK and was afraid of being a problem even at short distances, but checked it with a logic analizer and it's perfect for TTL and CMOS 3.3V.

    I have my launchpad with a 30Mhz SSI CLK and it works fine, it can reach 60Mhz but at that speed you alredy can see one erro here and there. I have the TM4C1294XL launchpad so it can reach those frequencies.

  • Hello Luis,


    Thank you for your answer, but i am almost certain that i used a same launchpad to interface with an SD card at 20MHz before which as far as i can remember worked fine (~2 Mbps transfer speed). I will try using a buffer tomorrow and report back the results.


    Fransisco

  • Hi Fransisco,

    I never said it wouldn't work fine, i'm talking about some long wires, like 30cm or more.

    As i said, i use this at 30Mhz just fine with the tm4c1294, and it was controling 2 TLC5940 with 10cm wires, and in a breadboard. 60Mhz clk i haven't realy tested it

    Have you tried witht he actual IC or module you want to interface and failed or you just checked the signal in the osciloscope?

  • Hello Fransisco,

    Even though you have not connected anything to the launchpad: The Scope probe is still there. This would act as a load to the device. By default the drive strength of the pad may not be sufficient (I have seen this with a few scope probes) and hence it would be required to increase the drive strength of the pad.

    You can try to use 4mA or 8mA to improve the rise/fall characteristic of the IO.

    Regards

    Amit

  • Hello Amit,

    I had already tried increasing the drive strength with no result.

    	GPIOPadConfigSet(GPIO_PORTA_BASE, GPIO_PIN_2, GPIO_STRENGTH_8MA, GPIO_PIN_TYPE_STD);

    Fransisco

  • Hello Fransisco,

    I ran the SSI Example Code on the TM4C123 LaunchPad with only the scope probe connected to the SSICLK Pin on PA2 with the default 2mA drive. As you can see it is a nice and clean 40MHz SSI Clock on the pin. FYI: I am using Agilent Scope with 500MHz Bandwidth Probes.

    Regards

    Amit

  • Hello Luis and Amit,


    Thank you for both of your responses. The problem was as both of you said, not the controller itself but something else. As Amit said the probe was causing the problems.

    In the end it was just me being a crappy engineer ;)