While continuing to test some of the SPI functionality of STM32-MAT using the nucleo-f302r8 board. I again ran into some problems (and solutions).
While compiling the "STM32-MAT\STM32\STM32demos\Test\SPI" example, I got a compile error in getBuffPtr.c: "getBuffPtr.c:9:25: error: unknown type name 'uint16_t' ". (using SW4STM32)
This is because the integer types are not recognized. Adding #include <stdint.h> to the getBuffPtr.c file will solve this.
This error also happens in EWARM and KEIL.
Next, SW4STM32 warns about an incompatible pointer type: "warning: passing argument 1 of 'getBuffPtr' from incompatible pointer type [-Wincompatible-pointer-types]"
EWARM and KEIL will both treat this as an error and will not compile. This is due to the simulink example provinding an uint8_t pointer type while getBuffPtr() expecting an uint16_t pointer type. This can be easily fixed by changing the input argument of getBuffPtr to uint8_t* instead of uint16_t*.
The buffer size of the spi perifiral is too large (5 bytes) for the amount of bytes to be sent (3 bytes).
This will lead incorrect transmissions with somehow variable length messages being sent (between 1 and 3 bytes)
The generated code puts the chip select gpio action after the transmission already has started! This results in corrupted spi messages being sent because the chip select becomes active during the transmission of the first byte. (example of the spi clock line and chip select line when sending two bytes):
This can be fixed by moving the gpio write to before starting the spi transmission:
After moving this line of code the communication is succesful:
It is very inconvenient to do this every time by hand, am I missing something in the simulink design or is this a code generation bug? If so, can this please be fixed?
EDIT: Okay so apparently it is possible to assign priorities to the block in the block properties section. These are not used in this example and should probably be fixed.
The simulink example includes some blocks to output the received spi data over uart. The problem is that some messages have missing characters:
This is caused by the uart buffer being too small for the transmission buffer:
Increasing the "Send Buffer Size" value to 18 fixes this problem. What is also curious is that the getSpiDataValue() function uses a 20 byte buffer so when this one is filled the last two characters also won't be sent. Increasing both the "Send Buffer Size" and the size returned by the "Get Val" function to 20 also seems to solve this problem.
I hope this information is enough to be of some help!