• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 1351 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.

AM3517 SPI chip select at reset

James Brady
Prodigy 50 points

Other Parts Discussed in Thread: AM3517

Hello,

On the AM3517 I am using SPI port 1 as a master, and am using chip select 0.  On power up, CS0 is initially high, as expected, but during boot when the driver's init() loads and configures the pin-mux, CS0 immediately goes low (active state).  This is not expected.  Later, when I use the port to communicate, it works fine and leaves CS0 in high state as expected.  My issue is that my SPI periheral is selected active between boot up and the first time it's used.

I noticed in the AM35x TRM, Table 16-1, it says that the spim_csx reset state is low, which may explain what I am seeing.  But "low" is surprising because that is the active state - I don't understand why an SPI port would reset to chip-select-active.  Am I reading the TRM wrong ? is there a workaround to this ?

Thanks for help,

Jim

  • 0
    TI__Guru**** 393215 points
    Hi Jim,
     
    Table 16-1 has a footnote (1), which states that "After reset, the SPI modules are in slave mode by default". Perhaps the pinmux for the chip select signal should be configured after you have switched the spi module to master.
  • 0 in reply to Biser Gatchev-XID
    Prodigy 50 points

    Biser,

    Actually, prior to setting pinmux, I am setting the SPI module to master.  Basically the sequence is,

    Power up

    Chip select is high (pulled up)

    Reset SPI controller, wait for done.

    Set SPI port 1 to master:  

       MODULCRTL = 0x00000000;

    Set pinmux for port 1:

       #define MCSPI1_PADS \
       PAD_ENTRY(MCSPI1_CS0, INPUT_DISABLED | PULL_RESISTOR_DISABLED | MUXMODE(0)) \
       PAD_ENTRY(MCSPI1_SOMI, INPUT_ENABLED | PULL_RESISTOR_DISABLED | MUXMODE(0)) \
       PAD_ENTRY(MCSPI1_SIMO,INPUT_DISABLED | PULL_RESISTOR_DISABLED | MUXMODE(0)) \
       PAD_ENTRY(MCSPI1_CLK, INPUT_ENABLED | PULL_RESISTOR_DISABLED | MUXMODE(0))

    This is when chip select goes low.

    Set SPI port 1 configuration baud rate, word length, EPOL, SPI mode, etc

       MCSPI_CH0CONF = 0x000103DC; 

    Chip select stays low

    Later I read / write data, which works fine, and chip select goes high after

    Jim

  • 0 in reply to James Brady
    TI__Guru* 95931 points

    Jim, what if you configure CS0 as INPUT_ENABLED and PULL_RESISTOR_HIGH?  I think when you are configuring your pin mux, the CS0 has nothing keep it high until you start using the module.

    Regards,

    James

  • 0 in reply to JJD
    Prodigy 50 points

    James,

    Thanks, I just tried your suggestion, but got same result.  When setting the pinmux,  chip select pin went low.  I think what is happening is that the SPI module chip select line is a "driven output" that is low, so input enable and pull up does not help.  Maybe I need to do more prior to setting the pinmux.  Like similar to what I do to send an actual message.  Nothing will come out on the pins because the pinmux is not set yet.  I know that after sending a message chip select is high.

    Basically what I do to send a message is enable the channel using CHCTRL reg, write the data using TX reg, then disable the channel.

    But I am still puzzled at table 16-1, like why would a person want the reset state of SPI chip select output to be low.

    Jim

  • 0 in reply to James Brady
    TI__Guru* 95931 points

    Hi Jim,

    I'm not sure i can explain that behavior.  A couple of things to check:

    -Do you have SPI in your boot sequence?  It is possible that the ROM is configuring the SPI to try to boot from it, and leaving it in a configured state that you are not expecting. Check the pinmux immediately after power up. 

    -I think you are on the right track that you should initialize the SPI module before enabling its pins in the pin mux.  You may need to do some additional configuration like:

    a)  perform a module reset with SOFTRESET

    b) initialize the MCSPI_SYST register with the desired settings.  This register sets the behavior of the I/Os

    c) set MCSPI_MODULECTRL for master mode as you have done,

    d) set EPOL bit for proper polarity of CS signals

    You may have to do some or all of the above to get your desired results.

    Regards,

    James

  • 0 in reply to JJD
    Prodigy 50 points

    I checked ROM bootloader sequence as you suggested and am OK there.  It is NAND -> Eth -> USB -> MMC

    Anyway, I added some further SPI port configuration prior to setting pinmux, and that solved the problem.  Basically I am now setting up the chip select polarity, putting it into force (single channel mode) since I am only using one chip select, setting that polarity, asserting chip select, deasserting chip select, then finally set the pinmux.  With that, chip select output is glitch free - it stays high all the way from power up to when I send a message.

    Thanks,

    Jim