#2 STM32F4 template

[Liviu Ionescu (ilg)]

The new version (2.1.1) of the STM32F4 template is available for testing.

I tested it on STM32F4DISCOVERY, and the green led blinks.

For the first time, the debug version using semihosting for tracing, can be executed without the debugger connected (many thanks to user diabolo38 for the contribution).

I'm not sure the initialisations (more specifically the clock) works on other boards with other processors from the F4 family.

I would appreciate feedback on tests performed with other F4 boards.

[Liviu Ionescu (ilg)]

please be aware that on this version, only the F4 and the generic Cortex-M templates are functional, the F1, F3 are work in progress.

so do not install it on a production Eclipse, better use a separate Eclipse.

[diabolo38]

Eclipse Kepler sr2 (win 7 64)
GNU ARM C/C++ STM32Fx Project Templates 2.1.1.201403281421
openocd 0.7.0 (win 64)

stm32f4xxx c project semi hosting blink with debugger but is not blinking if not debugged?
I must be missing something but what ?

[Liviu Ionescu (ilg)]

yes, I had this problem too and took me some reading to figure it out.

the debug bit tested by the trace_write_semihosting_* routines is cleared only at power up reset.

so, after unplugging the debug cable, cycle the power for the board, and the led should start blinking.

[Liviu Ionescu (ilg)]

although it does not apply to F4, another detail to remember is that the CoreDebug register used to skip the semihosting call, is not available on armv6 architectures, so Cortex-M0/M0+ cannot use this method to make applications compiled with trace run without the debugger, and more elaborate methods must be used (exception handler tricks).

[Liviu Ionescu (ilg)]

I just added two more features:

• an option to select if the stdPeriph unused drivers remain present in the project but are excluded from build (similar options will be added to all templates)
• the TRACE definition is not issued at all if no trace device is selected (this applies to all existing templates F[014])

[diabolo38]

I did unplug re plug usb cable so it is not the debug bit?

for M0 Just add an Hard Fault handler like I provided to bypass all swi
maybe review it to check it is an swi instruction and also do not compare if pc < main.
I can help for that
It might just be slower with lot of exception generated but should work for all cpu.

Ideally std periph could be an external lib (two project linked or not ) but it's more complex to put in place. It is more convenient as we can have different build setting and also do not need to rebuild it whenever on option change in main project.

your new option is already a good alternative to avoid compiling tons of unused file.

[Liviu Ionescu (ilg)]

I did unplug re plug usb cable so it is not the debug bit?

ah, ok, now I saw you have USE_SEMIHOSTING...

as I said first, I applied the patch to check the debugger only to the trace_write_semihosting_*() routines

for semihosting there are too many calls to patch, so I decided to use the handler patch.

your Hard Fault handler is a good starting point, but I need some more time to study the details, so I decided to do it in the next release.

anyway, semihosting configurations are intended for unit tests, that get the test parameters from the host, write a progress file back to the host and return the pass/fail status also to the host, so it makes not much sense to run such tests without the debugger.

for the next release I plan to add a fourth configuration (Google Tests) to generate unit tests projects (using a separate library project, with the Google Mock code). the testing infrastructure is almost ready in µOS++, but I'm waiting for SEGGER to implement some details related to passing the exit code back to the host).

Ideally std periph could be an external lib

yes, it is planned to be a more advanced wizard to select the required components (based on some metadata added to the source files describing the dependencies and configuration options), and pack them as a separate library (eCos style, which packs everything, startup, drivers, scheduler, network, filesystem, etc. as a separate managed library, i.e. can be reconfigured at any time using the wizard).

[Liviu Ionescu (ilg)]

From user AlexX (https://sourceforge.net/u/alex-x2/profile/):

Hi, Liviu!
Thanks for the invitation to test updated software!
For the last few month I have been working with other projects, and I didn't have time to work with STM32 & Eclipse. So, I'm a little bit "outdated".
As I see, there is major changes with gnuarmeclipse plugin, as well as with "SPL", now known as "HAL".
For today, I didn't have much time to test it. Just few remarks:

I. I tried to compile Blink template for STM32F429 and instantly got errors in file "vectors_stm32f4xx.c", such as undeclared "UART7_IRQHandler, UART8_IRQHandler, SPI5_IRQHandler, SPI6_IRQHandler..." This problems caused by this line:

    #if defined(STM32F427_437xx) || defined(STM32F427_429xx)

This should be something like:

 #if defined(STM32F427xx) || defined(STM32F437xx) || defined(STM32F429xx) || defined(STM32F439xx)

because of later

 #elif defined(STM32F429xx)

II. After the line:

     #if defined(STM32F427_437xx) || defined(STM32F427_429xx)

you defined SPI4_IRQHandler second time:

 void __attribute__ ((weak, alias ("Default_Handler")))
 SPI4_IRQHandler(void);

It also have been defined a couple of lines earlier.

After that compilation went ok and the led blinked.

Then I tried to compile with this new library & template my previous project, which requires 150 K of RAM. But i didn't succeed, so I couldn't test it for you at the moment.
After all I tried to compile some simple example projects from STM32Cube for STM32F407 and STM32F429 chips. That was also unsuccessful, I got tons of errors like

 unknown type name 'SPI_HandleTypeDef'
 unknown type name 'I2C_HandleTypeDef'
 'HAL_SPI_STATE_RESET' undeclared (first use in this function)
 request for member 'Instance' in something not a structure or union
 'SPI_BAUDRATEPRESCALER_16' undeclared (first use in this function)
 ...

and so on. They were connected, as I understand, with I2C and SPI modules.
I should remark, that was new examples specially written for work with "HAL" library.
I don't know, what the problem is, but I couldn't figure it out quickly, may be it was my fault, but they were identical both for STM32F407 and STM32F429.
After all of these, I'm a little bit sad with this new experience.
I also have some remarks to new template structure, but I will write it to you later, I should investigate them more carefully.
By the way, thanks for such huge amount of work!
Best regards.

[Liviu Ionescu (ilg)]

Hi Alex, thank you for your help.

I fixed the lines you indicated, they were obviously wrong.

regarding I2C and SPI, as the new HAL library is designed, you need to enable those drivers in the conf.h file and be sure you did not exclude the sources from build. I updated the conf.h file and now all drivers are included, but normally this should be trimmed by the application, to save some compile time.

[Liviu Ionescu (ilg)]

I just published a new beta version, with vectors fixed for all processor variants and warnings fixed.

Please let me know if for your configurations it compiles properly.