MSPM0C1104: SPI- Microwire example code

As I recall, Microwire is a subset of SPI. What particular Microwire feature(s) are you looking for?

The SPI examples are here:

https://dev.ti.com/tirex/explore/node?node=A__AJwOQBR.oN.JLxoLVOhUdg__MSPM0-SDK__a3PaaoK__LATEST

As far as I know, the MSPM0 SPI has no provision for 3-wire (shared MISO/MOSI) SPI.

Hi Bruce,

MSPM0 supports Microwire frame by hardware, and it has register field for this, Datasheet says it is supporting Microwire.

but no example in SDK. and no frame format in TRM. could you add?

My customer wants to build Microwire Slave,  8bit ADDR and 16bit Data. only read function. 

Regards,

Ted

I was kind of hoping that someone (from TI) who knows the answer would speak up by now, but I'm beginning to suspect this feature isn't supported.

In addition to the items you mentioned, I notice that:

4) Neither TI-Drivers (frameFormat[]) nor DriverLib (enum DL_SPI_FRAME_FORMAT) recognizes this feature.

5) The CMSIS definition in hw_spi.h is named "SPI_CTL0_FRF_MIRCOWIRE", a misspelling I expect would have been noticed if anyone had used it.

I haven't tried this feature, so I don't know what it might provide; the implementations I've found vary quite a bit.

-----------------------

That said, I have some doubts about whether the proposed software Slave would work well:

a) The MSPM0 SPI doesn't have a provision for differing Tx and Rx frame sizes. (You might be able to do something with framesize=4.)

b) The uWire protocol only provides a single SCK time for the Slave (software) to decode the request and supply the result, which is very tight timing unless you can convince the Master side to pause at the appropriate time.

[Edit: Slave Frame Size is minimum 7 per TRM (SLAU893A) Sec 12.2.2.2]

Observed behavior from the controller (Master) side:

1) The Request (controller Tx) is assumed to be 8 bits

2) The Response (controller Rx) is sized according to the set Frame Size (DSS setting)

3) PICO (MOSI) is driven low (=0) during the "idle" SCK period ((8+1) total Tx bits) before it goes Hi-Z for the Rx.

4) The SCK was continuous (no visible pauses).

5) Chip select (CS1) is active Low.

I haven't tried the peripheral (Slave) side, but I expect these assumptions hold there too.

Test case: I started with example spi_controller_multibyte_fifo_poll and added this after the SYSCFG_DL_init call:

    DL_SPI_disable(SPI_0_INST);
    DL_SPI_setFrameFormat(SPI_0_INST, SPI_CTL0_FRF_MIRCOWIRE ); // MicroWire [sic]
    DL_SPI_enable(SPI_0_INST);

For the scope: I also set the internal pullup for PICO and set the frame size to 16 (using sysconfig).

[Edit: I did this on an MSPM0G3507, but I believe that the SPI unit is the same as that on the C series.]

[Edit: Note about /CS.]

Thank you for your effort Bruce!

I did a similar experiment with 2x C1104 Launchpads, one running spi_controller_multibyte_fifo_poll and the other spi_peripheral_multibyte_fifo_poll. [Note: for the latter the README.md didn't match the .syscfg.] Each had the code change above, and the Frame Size (DSS) set to =16. The data was sent/received correctly.

1) The peripheral (slave) appears to have the same assumptions -- the Request is 8 bits, and the Response is according to the Frame Size (DSS).

2) The peripheral Tx bytes are drawn from the Tx FIFO only for the Response slots, so the SPI "send a byte frame/receive a byte frame" convention holds, even though the bits aren't transferred simultaneously.

3) The controller (master) side has no evident mechanism for pausing between the Tx and Rx phases to give the peripheral time to decode the Request.

[Edit: Minor wording fix.]

This is the timing chart that is applied to MSPM0

Thanks. Where did you find this? (I didn't see it in any of the MSPM0 TRMs or AppNotes.)

TI will update this timing chart in the next version TRM.