Mod5441x and Nano54415 SPI driver available

[dciliske]

Many of you have asked in the past about an SPI driver for the MCF5441x parts. Today we are announcing a beta version of the driver that emulates our QSPI driver for those parts. This driver will also be available in the next beta build which will hopefully be out this week/early January.

In theory it should be drop in compatible with the QSPI driver, as in: change the project from a MOD52XX platform to MOD5441X or NANO54415, adjust you pin definitions, change <qspi.h> to <dspi.h>, and you're done.
This is achieved using C++ inline functions that define QSPI* as calls to DSPI* on the DEFAULT_SPI_MODULE (normally module 1).

If instead you use the DSPI* interfaces, you will need to pass the module number (1, 2, or 3; 0 is not brought out) as the first argument. If you want to convert a project to using the native DSPI interface, find and replace "'QSPI(' -> 'DSPI( MODULE_NUMBER'" should take care of things ('s/QSPI(/DSPI( number/g' for UNIXY folks)

A word of warning about the SPI modules 2 and 3: they use the same pins as UART0 and UART1, respectively. Just something to keep in mind if you wonder why the example doesn't seem to work after changing the SPI module...

One final note is that I've been able to do the TX side using this driver at 62.5 Mbps (the processor's maximum), with a total throughput of ~1.2 MB/s; I do not have anything to run at that rate on the RX side though...

[dciliske]

Also, in case you want to add this to your system library, you'll need to modify the makefile to include the 'dspi.cpp' file in the build. Sorry if this wasn't clear from the original post.

[dciliske]

There is a new version of the driver posted. It fixes a bug where the chip selects would be deasserted prior to the last frame being transmitted.

[dciliske]

In development: DMA driven version of this driver. I'm shooting for ~5 MB/s max throughput with this one. I've already achieved ~6.2MB/s transferring/receiving a 5 MB buffer using a bare driver. So, we know now you know what kind of performance the part's capable of

[jch]

I'm trying to get all three DSPI ports running simultaneously on the MOD5441x but I'm having difficulty with DSPI2. I'm configuring the pins like this:

Code: Select all

J2[29].function(PINJ2_29_DSPI2_SCK);
J2[3].function(PINJ2_3_DSPI2_SIN);
J2[4].function(PINJ2_4_DSPI2_SOUT);

I'm using MTTY on the USB port with both DB9s diconnected and it seems like SPI data is being corrupted by what I can only assume is USB data. I understand that DSPI2 transmit and receive share pins with UART0 transmit and receive, though DSPI3 shares pins with UART1 and that works without issue. I pulled jumper JP2 (referencing MOD-DEV-70-SCH-R1p7.pdf) to make sure URXD0 (pin 3) wasn't connected to the USB port and that didn't help. I powered the board via the wall plug and disconnected the USB entirely (no MTTY) to ensure that both URXD0 (pin 3) and UTXD0 (pin 4) wouldn't interfere but that didn't help either. Am I missing something silly or is DSPI2 just not usable?

Thanks in advance.

[dciliske]

Can you walk me through your setup to explain how you arrived at this problem (as in, how are you communicating with the device, what pins are hooked up to what, wheres the data coming from for DSPI2, etc.)?

If you can post the test code, that'd also be useful.

[dciliske]

This is an issue with the devboard. What's happening is that the socket TX pins for UART0 and UART1 (and therefore DSPI2 and DSPI3) are tied directly to the RS-232 drivers, without any jumpers to break it. To workaround this issue you will need to remove the module from the devboard and manually jumper power, ground, and any other pins to their respective locations on the board. Alternatively it would be necessary to build a custom devboard.

I realize that this isn't the most satisfactory of answers, but this is the best solution for the current environment. Also, discussing the issue internally, it does not appear that we plan on adding these jumpers to the DEV-70. We will include commentary explaining this issue in the example application on using the DSPI driver.

[jch]

Sorry for the slow reply, I've been sick (isn't everybody?). My setup simply configures loopbacks on all DSPI ports by jumpering pins 27-28 (DSPI 1), 3-4 (DSPI 2), 21-22 (DSPI 3). I throw some data into separate send buffers and start the transfers. I package up data from all three DSPI ports and send it via Ethernet, which is what I'm looking at to determine that the received data does not match the transmitted data for DSPI 2. Since this configuration clobbers the UARTS, MTTY doesn't help in debugging.

I'm curious as to how DSPI 3 manages to function properly while DSPI 2 does not since both are tied directly to RS-232 drivers. Is it because UART0 is used by default whereas UART1 is not? Is there some way to temporarily disable sending data through either UART with software to prevent interference?

If I were to use an external device to transfer data to the DSPI 2 receive pin, would that work? Or maybe jumpering the send of DSPI 1 to the receive of DSPI 2 to test with this board... Is it only the transmit pins that would actually cause a problem?

If you'd still like to see my code, I can send that to you.


Thanks.

[dciliske]

Jch, sorry for the delay, I did not notice your reply. Rereading what you said originally (and the reply) clarified your issue. To be honest, given that you say DSPI 3 works even though DSPI 2 does not, I have no idea why that is on the dev board. As I said previously said though, we are unlikely to change the hardware on the Dev-70 to fix the issue.

In other news, I'm performing some benchmarks on overall performance of the DMA driven DSPI driver for both SPI throughput and remaining system performance.

So far the results are fairly promising on the SPI performance side. At high baudrates there's a 25-150% improvement in throughput, depending on the transfer size (larger transfers see a bigger boost due a greater percentage reduction in driver interrupts).

[dciliske]

So, I've got the final DSPI throughput benchmarks. These occurred while the device was being hammered with a 1400 byte flood ping.

[EDIT] I should also point out, these were done using 16 bit transfers.