#include "stm32f103c8t6.h"
#include "mbed.h"

DigitalOut  myled(LED1);
SPI         mySPI(PB_15, NC, PB_13);
DigitalOut  cs(PB_12);

void send_words ()
{
    int i;

    for (i = 0; i < 5; i++)
        mySPI.write(0xffff);
}

int main() {
    confSysClock();         /* Configure system clock (72MHz HSE clock, 48MHz USB clock) */

    cs = 1;
    mySPI.format(16, 3);
    mySPI.frequency(1000000);
    cs = 0;

    while(1) {
        send_words();
        myled = !myled;
        wait(1);
    }
}

Hi all. I've previously posted this as a question, so my hope is that by posting it here it gets treated as a bug report for the NUCLEO-STM32F103RB board and alike. I am using the online compiler targeting the "NUCLEO-F103RB" board and importing the [[https://developer.mbed.org/users/hudakz/code/mbed-STM32F103C8T6/|mbed-STM32F103C8T6]] library. Here's the test program I am using to test 16-bit SPI transfer on the STM32F103C8T6 board covered [[https://developer.mbed.org/users/hudakz/code/STM32F103C8T6_Hello/|here]]: <<code title=include the mbed and mbed-STM32F103C8T6 libraries with this snippet>> #include "stm32f103c8t6.h" #include "mbed.h" DigitalOut myled(LED1); SPI mySPI(PB_15, NC, PB_13); DigitalOut cs(PB_12); void send_words () { int i; for (i = 0; i < 5; i++) mySPI.write(0xffff); } int main() { confSysClock(); /* Configure system clock (72MHz HSE clock, 48MHz USB clock) */ cs = 1; mySPI.format(16, 3); mySPI.frequency(1000000); cs = 0; while(1) { send_words(); myled = !myled; wait(1); } } <</code>> Here's a capture of the resulting signal: {{/media/uploads/luigidifraia/logic_spi_01.png}} Zooming in: {{/media/uploads/luigidifraia/logic_spi_01_zoom.png}} What is odd is that after each expected 16-bit transfer of the word 0xffff there's a second unexpected 16-bit transfer of the word 0x0000. So in total 10 words are transferred, instead of 5, every second. For comparison, here's what happens if I use 8-bit SPI transfer: {{/media/uploads/luigidifraia/logic_spi_02.png}} The latter is the expected behaviour. [[https://developer.mbed.org/users/hudakz/|Zoltan]] has confirmed that the bug occurs with the official NUCLEO-STM32F103RB board too when replying to [[https://developer.mbed.org/questions/76234/SPI-interface-for-STM32F103C8T6-behaving|this question]]. Thank you. Cheers, Luigi

Were you ever able to find a solution to this? I'm using STM32F446's, and found that this issue appears if I use any mbed revisions after 127.

I'm using the STM32L476 and I have the same issue. any fix ?

I believe the same problem is present on the Nucleo F401 SDK. Noticed the problem after SDFatFileSystem stopped working after mbed revision 127. Does any of the ST or mbed devs actually monitor and read these threads?

<<quote riaancillie>> I believe the same problem is present on the Nucleo F401 SDK. Noticed the problem after SDFatFileSystem stopped working after mbed revision 127. Does any of the ST or mbed devs actually monitor and read these threads? <</quote>> Which version of the mbed library are you using? I think I understand how the function spi_master_write() was improperly implemented for the STM family in revision 128. However, in revision 148, the latest at the time I am writing, the implementation of spi_master_write() for the STM family has changed significantly and seems to be working fine for both 8- and 16- bit transfers during my tests. I had last tested my code with revision 132 when the bug was still present. Cheers, Luigi

This nice and useful info for me. Thanks a lot