cancel
Showing results for 
Search instead for 
Did you mean: 

STM32-MAT Simulink spi example compilation and chip select problems

sebastiaan goossens
Associate II
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)

0690X00000606wLQAQ.png

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):

0690X00000606wUQAQ.png

This can be fixed by moving the gpio write to before starting the spi transmission:

0690X00000606pLQAQ.png

After moving this line of code the communication is succesful:

0690X00000606pMQAQ.png

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: 

0690X00000606wyQAA.png

This is caused by the uart buffer being too small for the transmission buffer:

0690X00000606woQAA.png

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

4 REPLIES 4
Tomas DRESLER
Senior II
Posted on May 05, 2017 at 21:43

Thank you, forwarded to STM32-MAT author.

Posted on May 10, 2017 at 15:26

Hi Sebastiaan,

thank you for your comments. They will be fixed for next release.

Regarding problem 1:

I changed input argument of getBuffPtr to void* because sometimes it is uint8* and some times uint16* depending on example. 

problem 2:

put 3 instead of 5

problem 3:

Unfortunatly, not possible to solve from code generation.

Solution is to set different priorities: 0 for generateBuff, 1 for GPIO_Write and 2 for SPI

problem 4 :

set both to 20!

Thankx again

Best regards

Pascal

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:

0690X00000606zeQAA.png

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?

Eduard Betko
Associate
Posted on April 12, 2018 at 12:03

Hi,

Does a readme file exist for this Simulink example? I am not a very experienced programmer and therefore don't understand entirely what happens at which point of this model. I want to build an own model to communicate with the ST-MEMS digital accelerometer on the STM32F4 Discovery Board via SPI, but the example model in STM32 MAT/Target doesn't help me understand the process (or workflow).