port FatFS to TMS570LS04x HALCoGen API

Thank you for posting on the Hercules forum. One of our engineers will be on the problem shortly. 

I haven't done that per se, but, I've used the SPI library (SPI0 in compat mode, not MibSPI mode) for writing an LCD display driver for the Hercules LP.  One goofy thing I noticed is the buffer you give to the spiTransmitData et al functions is an array of 16-bit types, not a typical 8-bit buffer array.  So you have to re-copy any buffers you're using into an array of 16-bit integers, or write your library to seamlessly work with uint16_t arrays natively instead of typical uint8_t or char-arrays.

Also, if you intend to send a bunch of data, note that spiTransmitData ignores the CS_HOLD (chip select hold across transfers) setting if you're sending less than 2 bytes/words in a transfer.  This can be difficult if you're doing a transfer involving a single "command byte" followed by an arbitrary buffer write or similar.  You have to include the command byte in the buffer you're writing.  You should be able to drive the CS pins as general-purpose I/O though, if you configure it right in HALCoGen.  That or, you can inspect HALCoGen's source and implement the SPI transfer with the direct register manipulation yourself.

Yes, I have seen both observations too. I switched from MIBSPI to SPI to see if I can make it work in that mode.

It wasn't fully clear to me what to expect with the api expecting 16 bits buffer when the SPI format is configurable to other sizes. I raised a separate question for that on this forum and investigated behaviour with a testbed.

I also experienced that I can't keep the CS active during the full SDcard initialization cycle when using the SPI API. So your approach of driving it as a GIO sounds as a good plan, or I can use one of the GIO pins as CS.

My code is in a state that I have the SD initialisation procedure developed, but it doesn't yet result in the card reporting it's ready.