SPI pin mux settings and configuration

[Kewal]

Hi

Earlier some time we were trying to integrate Maxim I2C port expander with K64 processor. While we were doing that we missed configuring the pin as opendrain after a lot of struggle we were able to figure out.

However, Now when we set out to configure the SPI with Maxim SPI to RS232 converter. We are not able to communicate again with the maxim device on SPI. We have Maxim SPI to RS232 converters on the same SPI bus selected by different PCS. I am attaching the snapshot of the same. I am trying to do three different Master configurations as we did for I2C Is there anything which I am missing because of which the SPI is not working. By the way i have configured all the SPI related pins for opendrain and high strength functionality.

[jeremyzhou]

Hi Kewal,

I'd like to suggest that you can try to forbid the open drain and high strength after you configure the related pins work as the SPI pins.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[Kewal]

Hi Jeremy,

By mistake I mentioned that it is in opendrain,..while  I had to mention that it is not in opendrain mode for SPI. but however, It is set for high strength right now.

Do you think high strength would actually effect the rise time or fall time I am trying to look at every option,.. also I read in another thread that CLK pulled down can be enabled and set to pull low to avoid a possible glitch in the driver.

For some other login reasons, I had an issue viewing hte reply from you and had to create a different thread where i have posted more details of it.

Let me know if you have any more inputs for me.

SPI driver read not functioning with KSDK 1.2.0

[jeremyzhou]

Hi Kewal,

Thanks for your reply.

After have had a look through your reply, I found that you could send the signal through the MOSI pin successful now.

About receiving the none of reply from the Slave device, the weird glitch may be the cause, however it seems to like disappear according to the screen shot in the

SPI driver read not functioning with KSDK 1.2.0

I guess the discrepancy of the transfer format can cause the issue too, then it need you to compare the capture signal with slave target's datasheet to find it out.

Hope it helps.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[Kewal]

Jeremy

I have sorted out the problem partially, But I am yet to completely solve the issue.

On my board since there are three SPI slaves, I have done three SPI Master configurations. However, Only one of the slave is responding with Chip Select 2.

In the master configuration where I can tie the PCS0-5 for that particular master configuration, I am to communciate to other slaves.

Any idea as to what is wrong?

Thanks,

Kewal

[jeremyzhou]

Hi Kewal,

According to your reply, you want to communicate with three slave devices, however only slave device response well.

In the K64, the SPI module can have several peripheral chip select pins, however the K64 provides only one SPIx_CTARn register for clock and transfer attribute configuration.

So I guess the incompatible transferring format of slave devices cause some slave device works, but other devices fails.

Hope it helps.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[Kewal]

Jeremy,

"So I guess the incompatible transferring format of slave devices cause some slave device works, but other devices fails."

In my case, I have all the three slave devices of same type, that is MAX3107 IC which is an SPI to UART converter. So it should work. Essentially all CTAR is same.

My point is there is no definition of chip select pin found anywhere,

/*! @brief DSPI Peripheral Chip Select (PCS) configuration (which PCS to configure)*/

typedef enum _dspi_which_pcs_config {

    kDspiPcs0 = 1 << 0, /*!< PCS[0] @internal gui name="PCS0" */

    kDspiPcs1 = 1 << 1, /*!< PCS[1] @internal gui name="PCS1" */

    kDspiPcs2 = 1 << 2, /*!< PCS[2] @internal gui name="PCS2" */

    kDspiPcs3 = 1 << 3, /*!< PCS[3] @internal gui name="PCS3" */

    kDspiPcs4 = 1 << 4, /*!< PCS[4] @internal gui name="PCS4" */

    kDspiPcs5 = 1 << 5  /*!< PCS[5] @internal gui name="PCS5" */

} dspi_which_pcs_config_t;

I am still trying to figure out how the PCS2 works, but if you try to take a close look with multiple master configurations. There is no code which generates the details of the chip select pins.

Now we are configuring master configuration to be used individually with the different PCSx but there is no code generated with the below configuration.

finally masterdevice.whichpcs is just a bare enum shifted with some values. Its not PTDx

Hope I am able to actually convey it, According to me its a potential bug with KDS and also SPI provides a way to configure bus and and init , I guess if user stick with that it would be more easy, Configure/tuning SPI with KDS seems to be a waste of time for me.

[jeremyzhou]

Hi Kewal,

The Fig 1 illustrates that the PSC0,PSC1,PCS2 had been selected, however SPI master can't communicate with several slave devices simultaneously.

So I think the KDS will keep only one chip selection pin valid when generates the code, it may be the root cause of the issue.

                                                                                                          Fig 1

Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[Kewal · Accepted solution]

Jeremy,

Its rather strange for me because the LDD works properly and its the same setting which I have done through KDS. I went an extra length by copying(only the required, not everything) registers like MCR and SPI0_CTAR0 which was working through a setup using LDD driver. But it still did not work for me. I am not seeing any glitch on lines though,  what I did not see is any option through code warrior to do pin settings which is available through KDS. But now, I have tried with almost all pin settings.

So i consider except for SCLK where pull down should be enabled and all other pins including SCLK will be slow slew rate , low drive strength or opendrain disabled , am i correct?

Also, the attached register maps of SPIO was taken from the working thing and it was initialized in the non working setup.

(from the below registers MCR, CTR0 was considered)

(this is the not working register set where, it was initialized (only mcr and CTR0 was considered to be copied) )

Earlier in the day, I also came across a nomenclature where, in ARM processor Mode 1 is Mode 0 in non arm chips.

So i have my slave which needs CPHA and CPOL to be zero atleast thats what is seen through register settings. KDS has active high and active low which sorts of confuses anybody, but just a wiki should be enough to figure it out.

So am I missing anything under the sun to be considered. yeah, I have tried with MSB and and LSB option both but did not work. Though our chip works MSB first as per their datasheet. Its something to do with the driver but not able to figure out what exactly...... because we have the required command being sent out. Any other directions or suggestions.........

:smileysad:

Thanks,

Kewal