Updating system libraries to support custom SFIO (on MOD54415)

[AlokD]

Hello,

Apologies in advance if this question has already been answered elsewhere. I think this is a similar question, but it is for MODM7AE70 (ARM) instead of MOD5XXX (Coldfire): viewtopic.php?p=12395&hilit=pin#p12395

I have a MOD54415, and I am looking to reconfigure the pin muxing in the Coldfire’s registers so I can assign another function to 3 pins that are SFIO at the moment. I have the latest NNDK 3.5.4.

Context: I have a daughterboard for MOD54415 for which only 6 SFIO pins on the J2 connector are exposed. The 6 pins are:
3, 4 (default: UART0)
21, 22 (default: UART1)
39, 42 (default: I2C0)

I would like to set some of these 6 pins to the SPI special function. I am wondering if that is possible without bit-banging?

From looking at the data sheet for MOD5441X, I saw that the pins 3-4 and 21-22 can be set in SFIO for SPI2/SPI3 MISO and MOSI. However, if I want to use one of these as an SPI, I would additionally need the Chip-Select and Clock lines for either of them to be exposed, and they are not amongst the above pins.

After looking at the data sheet for MCF5441X, on page 14, it seems that those are only available on Pins 24 and 29.
https://www.nxp.com/docs/en/data-sheet/MCF54418.pdf
So it would seem that SPI is not possible without bit banging. Is that correct?

TLDR: I would just like confirmation that SFIO is not possible when there is no function available in the Pin assignment table of the microcontroller.

Note: I can make a support ticket if my question is too unique. But please let me know if that is the case.

Thank you.

[AlokD]

I ended up receiving support after opening up a ticket, since my scenario is unique.

Here are some take-aways from the discussion:

1. The only pure firmware-based solution to the above problem is bit-banging

Bit-banging is the only firmware-based solution

1.png (187.97 KiB) Viewed 33246 times

2. Bit-banging is much slower - it depends on the baud rate of the master

Bit-banging depends on rate of master

2.png (284.18 KiB) Viewed 33246 times

3. A much better hardware workaround is to jumper the SFIO pins that are inaccessible to GPIO pins that are accessible.

Better workaround is jumping

3.png (119.83 KiB) Viewed 33246 times

This ticket can be closed, as further discussion is unique to my scenario and will be continued in the support ticket.