TMS320F28069 GPIO Mux Question

Hi Johnw,

I don't use STE pin at all, as I keep my slave always enabled. You can surely use it as a GPIO etc. The only care you'll have to take is configuring accordingly in "F2806x_Spi.c" file. You'll have to comment the SPISTEA line in that file.

Also according to the doc:

F28069 Technical Reference said:

The GPIO19 (SPISTE) pin is used as a chip-select for the serial SPI EEPROM or flash

Regards,

Gautam

Hi Gautam,

You should re-think not using SPISTE pin.  This pin is critical for keeping SPI communication in sync between the master and slave.  If you got a little noise glitch on SPICLK that made the slave think it had gotten another clock pulse, you'd have no way to re-sync.  The slave would be off by one bit forever.  De-asserting and re-asserting SPISTE re-starts the slave reception at the first bit of the transaction.

Regards,

David

Gautam,

Thanks for mentioning this - I am using internal Flash for booting but you made a good point.  In fact, I had forgotten
to put the boot-mode switch in my schematic for GPIO_34 and TDO - that is fixed now.

I know David addressed the last remark to you - what I have done in my designs on multiple peripherals on the SPI bus is to assign respective GPIO's as chip selects - that is another way to solve that problem.

It is interesting the '069 has 'TRIWIRE' mode - SPISTEx is still used.  (section 12.1.7 of Tech Ref)

Point of my question was if it was possible to set the GPIO Mux to use pins that are otherwise unused in a 
peripheral - SPI was a good example - looks like the answer is yes.  

Thanks,
johnw

Hi David,

Thanks for the pointer. Yup as John mentioned I used GPIOs for Chip select function and kept them always enabled until any faults occurred.

Will keep your suggestion in mind, but till now have never faced such an issue.

Regards,

Gautam

John,

A few added notes:
1) SPISTE is always needed if the device is being used as a slave.  (I think this is understood just making sure)
2) The answer to your main question is yes.  In general, you are able to flexibly use the GPIO mux.  One example might be choosing not to send across SPISTE when the C28x is configured as a master.   As David mentions there are some negatives to doing this for SPISTE in particular, but it is allowed (similar story for PWMxB, etc).  The GPIO mux can really be thought of as a mux.
3) The SPI module's documented TRIWIRE mode is a way of sharing the SIMO and SOMI data line so that you have three wires: Data, Clock, and Enable.  This is really a tradeoff of throughput and wire.  Similar to above, you could choose to use a 2-wire version of this (with only data and clock) with similar negatives.


Thank you,
Brett

Brett,

That was the crux of the question - I think the 'giveaway' so to speak is in the '069 PDF looking at GPIO3 and GPIO5
(p143) for SPIA assignments - there is no 'adjacent' grouping so to speak for the SPI CLK there.

I had another question that has remained unanswered - I asked about the max freq HRCAP can handle in this 
part - I think it was around 17MHz - I'll have to find that thread - maybe I will give it a 'bump' - appreciate it if you could
answer that too.

It is good that the GPIO Mux is truly that - and also - for external IRQ's - they can only be mapped to GPIO0-GPIO31 
- correct?

Thanks!
johnw

John,

johnw said:

for external IRQ's - they can only be mapped to GPIO0-GPIO31 - correct?