Posted on May 05, 2017 at 13:54
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).Problem 1:
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*.
Problem 2:
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)
Problem 3:
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.
Problem 4:
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!
Regards,
Sebastiaan
Application versions:
Matlab r2016b (with all the required toolboxes)
STM32CubeMX 4.20.1 with STM32F3 package 1.8.0
STM32-MAT_TARGET 4.4.1
SW4STM32 v1.14.0
EWARM v8.11
KEIL v5.23
Posted on May 12, 2017 at 18:06
Hi Reynaud,
I investigated some more in problem 2, because I'm trying to set up a sensor(using several small transfers) and aftewards read larger chuncks of data from it(14 bytes at a time), so I do need to use multiple sizes of transmission. Including 1 byte of command data the total data packages are either 2 bytes or 15 bytes, so I put the buffer up to 15 bytes.
And indeed right after this, the two byte transfers are acting weird again. Sometimes only 1 byte is transmitted.
When looking into this it seems there is something weird going on with the spi ringbuffer:
During debugging in some of the SPI functions I saw the following:
It seems that the nb2Send variable has an absurd large value and this value keeps increasing over time (overflowing at the 16-bit limit).
Using the same buffer size (or an integer multiple!) as the to be transmitted message does not show any problems but still inhibits the growing value of nb2Send. This is not possible for me however due to the requirements of different sized transfers.
Could this be somehow related to the wrong number of messages being sent? From my point of view something is wrong with the ringbuffer --> skipping a byte when it hits the end (this also could explain why using a buffer size which is a multiple of the transfer does not show any problem, and also the fact that 1 to 3 bytes are sent when using a 5 byte buffer on a 3 byte message).
Do you have any idea?
