• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 896 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.

TMS320F28384S: Need help determining why SPI not working with C2000Ware and processor migration

Wesley C
Intellectual 925 points

Part Number: TMS320F28384S
Other Parts Discussed in Thread: C2000WARE

We are migrating from the 28374S to the 28384S which required an update to our C2000Ware library (1.06 to 4.0).

Now that we have made the migration, I can step through our logic and see that most of the actions occur as expected but when checking the external line I don't see the SPI Clock sending out any signals after placing data in the TX_BUF for SPI B. The logic is currently polling. The SPI peripheral is enabled. I checked the SPI module registers and don't see anything off.

Is there anything that changed in relation with the SPI driver between the 2 processors or C2000Ware library update that may be related? Any suggestions on where to look would be helpful. Thanks!

  • 0
    TI__Mastermind 32695 points

    Hi,

    The SPI module and the drivers remains the same between these 2 devices. There could be differences in the GPIO pins and interrupt numbers.

    Are you using driverlib functions or bitfield structs?

    Regards,

    Veena

  • 0 in reply to Veena Kamath
    Intellectual 925 points

    Hi Veena,

    We're using driverlib functions.

    We use the following GPIOs and related configurations for the Clock, SIMO, and SOMI in our latest design.

    /*
 * SPI-B configuration
 */
#define SPI_B_CLOCK_PIN GPIO26
#define SPI_B_CLOCK_PIN_CFG GPIO_26_SPIB_CLK
#define SPI_B_SIMO_PIN GPIO24
#define SPI_B_SIMO_PIN_CFG GPIO_24_SPIB_SIMO
#define SPI_B_SOMI_PIN GPIO25
#define SPI_B_SOMI_PIN_CFG GPIO_25_SPIB_SOMI

    The logic for setting the pins hasn't changed between our designs though there are now 2 devices instead of 1 device on the line. Each has its own chip select, hold, and write enable pins.

    The SPI is set as SPI_MODE_MASTER.

    We set each pin to GPIO_CORE_CPU1, GPIO_QUAL_ASYNC, and GPIO_PIN_TYPE_PULLUP.

    I am able to see data being pushed into SPITXBUF and see the RXFFST bit in the SPIFFRX being set and then cleared on read but I see 0V on our test points for the CLK or SIMO pins and 3.3V consistently on our SOMI test point. The chip selects are set as expected with the line going low for active device when a message transaction should be occurring and the write enables and hold pins are showing 3.3V as expected for those devices.

    Regards,

    -Wes

  • 0 in reply to Wesley C
    TI__Mastermind 32695 points

    Just to ensure it is not a hardware issue, can you try out the F2838x SPI examples from C2000ware? It might be using a different set of pins. You can change them accordingly.

    Regards,

    Veena

  • 0 in reply to Veena Kamath
    Intellectual 925 points

    That makes sense. Once I have tested it, I will update this thread. Thanks!

    -Wes

  • 0 in reply to Wesley C
    Intellectual 925 points

    Hi Veena.

    I utilized the F2838x SPI examples and was able to determine part of my issue which was apparently related to ensuring the pin configuration occurs prior to any other pin setting. I'm not sure if this is a 2838x difference or a C2000Ware version difference as this wasn't necessary in the 2837x processor with an older version of C2000Ware.

    That said, now my only issue is the SPI devices aren't responding as I expect them to respond. i.e. no response. At this point, I expect that to be an issue with our design as the pins are muxed correctly as SPI B SOMI/SIMO/CLK pins as I can see via the internal registers. My chip select signals are occurring as expected (high for off, low for on) and I see CLK and SIMO signals so there is likely an issue somewhere else.

    Thanks for your help.

    -Wes

  • 0 in reply to Wesley C
    TI__Mastermind 32695 points

    Hi Wes,

    Do you mean to say you had to make SPI pin configuration before configuring all other module pins to make it work? I am not aware of any such restrictions in F2838x.

    Do you use driverlib functions or direct register accesses?

    Regards,

    Veena

  • 0 in reply to Veena Kamath
    Intellectual 925 points

    Hi Veena, with the 2837x processor and C2000Ware 1.06, the following C2000Ware GPIO module function call sequence worked when applying pin settings:

    GPIO_setMasterCore

    GPIO_setPadConfig

    GPIO_setPinConfig

    GPIO_setQualificationMode

    GPIO_setDirectionMode

    But with the 2838x processor and C2000Ware 4.00, we now had to do the following for the SPI pins:

    GPIO_setPinConfig

    GPIO_setPadConfig

    GPIO_setMasterCore

    GPIO_setQualificationMode

    GPIO_setDirectionMode

    The pin config had to be set first. I noticed that in the 2838x datasheet there is a 'Configuring Device Pins' section in the SPI indicating

    "The GPIO mux registers must be configured to connect this peripheral to the device pins. To avoid glitches on the pins, the GPyGMUX bits must be configured first (while keeping the corresponding GPyMUX bits at the default of zero), followed by writing the GPyMUX register to the desired value."

    which I believe is related to this. I have set all the SPI related pins to follow this sequence of setup now and I see the CLK and SIMO signals occurring as expected. Unfortunately, I am having issues with SOMI (device responses) but my team needs to look further at the hardware to ensure that there isn't an issue there.

  • 0 in reply to Wesley C
    TI__Mastermind 32695 points

    Thank you for the details.

    Regards,

    Veena