STM32-MAT/TARGET. Tons Of Bugs

[Dima Sagalov]

Posted on February 26, 2018 at 04:01

E

nvironment

:

Windows10 (x64)

Matlab R2017a

STM32-MAT/TARGET-v4.4.2

STM32CubeMX-v4.24.0

STM32Cube MCU Package for STM32F0 Series -v1.9.0

STM32Cube MCU Package for STM32F3 Series -v1.9.0

SW4STM32-v2.4

TrueSTUDIO-v9.0.0

The last 2 weeks had to work very tightly with the package STM32-MAT/TARGET. For my first acquaintance - too many mistakes. It became terrible to describe them all - I will kill a lot of time. But, nevertheless, I decided to do it. It will be useful for everyone!

My main conclusion, which I could have voiced - the package is very interesting, but the number of errors exceeds the limit. Most likely, the main reason for this is a weak coverage of tests, both through a series of microcontrollers, and through various IDEs. It seems that the developers focused on STM32F4. This is evident from the way the package works with ADC for STM32F0, for example - it does not work with it at all, completely ignores the ADC outputs in the Simulink model (the reason I will put in a separate post on ADC).

If the tests that are present in the STM32-MAT\STM32\STM32demos\Test directory � are all tests, then this is definitely not enough!

I'm sure (at least, I hope so) that developers spend a lot of time on improving this product. But with the forces of the community - it would happen faster and more productive! The end user would not have to wait half a year until the next release, when the project needs to be handed over to the customer here and now, but there is a critical error in the generator! The community could also adapt the package for Linux, especially since it is partially compatible with it.

Errors that I found, I'll explain in separate posts - for one post there are too many of them!

Here I only list them in the order in which they are viewed:

- Incorrect generation of projects for SW4STM32 and TrueSTUDIO (I will not tell you about other IDEs - I did not check it)

- Hardware error during SPI operation (jumping over NULL pointers)

- stopping the slave SPI after each transmission, if only the SPI-slave is defined in the system.

- If there are more than 1 USART in the system, for the first USART all the variables and functions are generated correctly, for all subsequent ones - only partially.

- If several USARTs have one common interrupt, the Cube generates the code for USART operation in the interrupt mode, and STM32-MAT/TARGET supplements this code for USART operation in the polling mode - the porridge turns out.

- ADC. Ohhhh .... This thing just killed me! I'm tired of fighting with it! Actually, after that I already spat, and decided to write about all this disgrace!

Perhaps not all of what I will write about is a mistake! It is possible that I myself do not understand something. Then I beg your pardon! Perhaps some of the problems have already been described by someone sometime. According to the ADC, I saw two posts ... �ADC does not work!� Oh, sorry, It works!�� On STM32F0, it definitely does not work!

#stm32-mat/target-matlab #simulink

[S.Ma]

Posted on February 26, 2018 at 05:40

High level programming language, or in this case visual programming hardly gets C optimized end results unless the code is being manually optimized in a second step. Memory requirements should be higher than usual, hence targetting initially STM32F0 or L0 family probably raises the challenge level.Don t know mat target in details, however with genuine matlab license, IAR or KEIL IDEs maybe more suitable. If the examples are more aiming at F4 family, generate and bug fix there, then through HAL adapt and optimize the code for F0 or L0.

If Matlab us used to test algos, it should be used in resource rich mcu, then squeezed to the most compatible target. I assume that spending time in debugging points to little alternatives out there in the non linux embedded space? Maybe ST should restrict the IDEs and targets to focus more on rugged than versatile, avoiding frustrations as here. 

[Dima Sagalov]

Posted on February 26, 2018 at 06:14

STM32-MAT/TARGET package is not only about rapid prototyping,

in my opinion

, but also for programming finished applications.

Therefore, it should cover not only the top chips, but the whole range of MCU.

By experience I can say - most part of footprint is occupied by STM32 drivers.

If we compare the pure project of Cube and Cube+

STM32-MAT/TARGET

project, then the difference in size is not so great.

To the algorithms implemented in Simulink, I generally have no questions - compact and fast.

For example, I have already implemented a complex communication module on the STM32F070CB and it took up only 26K of memory and showed an acceptable speed even on such a smart chip.

The package works and works

quite well

!

But its problem is a weak test coverage.

[Aimagin Co., Ltd.]

Posted on February 27, 2018 at 10:00

Hi,

I fixed the

USART problem you can see in this

https://community.st.com/0D50X00009XkWfLSAV

.

https://community.st.com/0D50X00009XkWfLSAV

Best regards,