• Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 657 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Bad SSI0Fss Deassert between 545 kHz and 1.25 MHz

Chris Gage
Prodigy 60 points
Other Parts Discussed in Thread: EK-TM4C123GXL, TM4C123GH6ZRB, TM4C123GH6PM

Hello,

I am using two EK-TM4C123GXL Launch Pads, each attached to a GPIO Breakout BoosterPack.  The SSI0 pins are connected via the screw terminals with wires not more than 2 inches long.  The grounds are also connected between the devices.  I have attached my scope to the pins on the SSI master Launch Pad: J1.1, J2.8, J2.9, and J2.10.  The slave Launch Pad can be on or off, the error still occurs.  I am using an 80 MHz System Clock  See below for SSI configuration.

The error is this: when the SSI Master is set to a frequency between 545 kHz and 1.25 MHz, the deassertion of the SSI0Fss signal in-between successive bytes is too short for the Slave module to pick up, and thus results in the Slave module not being able to receive all or part of an SSI transmission.  I am using a simple loop with SSIDataPut() to send data.

Constant Config Regs:

SSI_CR1: 0x02

SSI_CPSR: 0x02

SSI_IM: 0x00

SSI_DMACTL: 0x00

SSI_CC: 0x00

SSI_CR0: 0xXX07

Clock rates that result in too short pulses (note the 0x07 stays constant, only the two most significant digits increment):

SSI_CR0: 0x1F07 - 0x4807

This isn't a show stopper for me, I just noticed it while doing some testing and was kind-of curious as to the cause.

Thanks,

Chris

  • TI__Guru**** 244400 points
    Hello Chris

    So for the CR0.SCR value of 0x1F to 0x48 the FSS pulse is shortened. Right? If that is the case can you let us know what is the minimum time expected by the Slave for the FSS to be deasserted?

    Regards
    Amit
  • in reply to Amit Ashara
    Prodigy 60 points
    Hi Amit,

    Thanks for the quick response. I'm not sure what the minimum time is, the TI data sheet doesn't say. Empirically it seems to be about 50-100 ns.
  • in reply to Chris Gage
    TI__Guru**** 244400 points
    Hello Chris,

    Which SSI Slave device from TI is this (part number so that I can check as well)

    Regards
    Amit
  • in reply to Amit Ashara
    Prodigy 60 points
    Its the exact same launch pad and breakout board as the master. One is configured as a master, the other as a slave.
  • in reply to Chris Gage
    TI__Guru**** 244400 points
    Hello Chris

    Sorry. I did not realize that you had mentioned it in the post already

    1. You had mentioned that the Slave device can be ON or OFF and the error still occurs, but the next statment is contradictory
    Chris Gage said:
    the deassertion of the SSI0Fss signal in-between successive bytes is too short for the Slave module to pick up, and thus results in the Slave module not being able to receive all or part of an SSI transmission.


    2. Did you try the same with the scope not connected to the FSS signal as the line may be loaded and/or increasing the driver strength on the FSS or introducing Slew Rate control on the Clock Line.

    Regards
    Amit
  • in reply to Amit Ashara
    Prodigy 60 points
    Hi Amit,

    1. What I meant by that combination of statements is that the slave device can be on or off, and the output of the FSS line is the same ( a pulse that is too short for the slave device to use when it is on ).

    2. I do not think this is the case as I can get a perfectly good FSS signal at 2+ MHz, and the clock and data signals work just fine at all frequencies when they are hooked up to similar probes on the same scope.
  • in reply to Chris Gage
    TI__Guru**** 244400 points
    Hello Chris

    Thanks for the clarification on point #1.

    As for the second point, I have run a dual device SSI test with TM4C123GH6ZRB with one as master and another as slave from 100K to System_Clock/12 and not seen a window of such a failure.

    If you can send in your master and slave simplified code, I can retry with a TM4C123GH6PM device (it will take time though).

    Regards
    Amit