As a Freescale Application Engineer, making this entry really pains me, however I am interested in getting the issues fixed so that this great little board can work as advertised. I dug through quite a bit of the posts here, only finding one reference to Problem #1.

Problem #1: spi.format(16,3) - does not produce 16 clocks. Note that this issue can be mitigated by making two 8-Bit writes within the chip selects, but this requires some overhead to manipulate the 16-Bit data into high and low bytes.

Problem #2: spi.format(8,1) - does not invert the SCLK polarity. I am not 100% certain that the phasing is working either.

There is actually a third issue, or wish. Provide a setting for the MOSI polarity. Many applications require MOSI to start LOW, and transition HIGH on data 1s.

Thank you.

Hi Bill,

KL25Z device supports 8bit transfers only – it should never produce 16 clocks as registers are 8bits wide

This is from spi_api.c for KL, you should use this one:

Pavel

Thank you for your reply Pavel.

I need to work with 16-bit registers, so it looks like I will have to make my own board and use CodeWarrior. I had hoped the Freedom board would support larger data groups.

Best Regards,

Bill

As you said yourself, you can just split it in two 8-bit writes. You can even make a simple 16-bit function yourself that splits it in two 8-bit writes.

It's not the fault of either the board or the mbed code. Though you should be aware that the board has got what I'd consider to be a design flaw: the blue LED is on the PTD1 pin, so that doesn't work too well for SCLK. You can use the PTC5 pin instead for SPI0's SCLK.

If you look at chapter 37 in the KL25P80M48SF0RM.pdf reference manual, you will see that the shift register is only 8 bits wide.

You can do 16-bit or wider transfers though by doing multiple 8 bit transfers.

• construct your SPI instance:

    SPI spi(PTD2, PTD3, PTC5);  //  MOSI, MISO, SCLK
    spi.format(8, 3);  // or as needed

• assert your CS pin
• do multiple 8-bit transfers
• de-assert your CS pin

Has the spi.format(8,1) issue been resolved yet? I'm interfacing with a chip that communicates with that spi mode.