STM32F4 Discovery
ST Micro really gave the world a nice Holiday present this year by releasing the STM32F4 Discovery board! You can get yours at Mouser for $16.25. An amazing dev. board for $16.25.
- 32-bit ARM Cortex-M4F Core
- 1MB Flash, 192KB RAM
- FPU (Float Point Unit), 16-Channel DMA
- Ethernet MAC 10/100
- USB 2.0 OTG HS/FS
- 6x UART (LIN, Strtacard, IrDA)
- 3x SPI, 2x I2S, 3x I2C, 2x CAN 2.0 B
- 3x 12Bit ADC (24 Channels 2.44MSPS), 2x 2-Channel 12-Bit DAC
- 2x 16-Bit Motor Control PWM, 10x 16-Bit Timers, 2x 32-Bit Timers
Discovery Board Extras:
- ST MEMS motion sensor (LIS302DL 3-axis digital accelerometer)
- ST MEMS audio sensor (MP45DT02 omni-directional digital microphone)
- Audio DAC with integrated class D speaker driver (CS43L22)
Using Atollic TrueSTUDIO and FreeRTOS on the new board is truly amazing. In my humble opinion, the new STM32F4 is going to be a game changer. Oh, and I like Atollic TrueSTUDIO because they don’t impose ANY stupid limits on code size. With TrueSTUDIO, it’s just a matter of getting use to the dumb pop-up ads for their pro product. Hard to argue with a free product. Still, I with they had a hobbyists version for $100 bucks that dropped the ads.
So, to get the ball rolling, I downloaded a FreeRTOS port for the F4 from Thomas Kindler. You can find Thomas’s on git hub work by following the the link here. Thanks you Thomas, your port was indispensable. With the work Tomas provided I was able to port that into a Atollic TrueSTUDIO project. Below you can find a link to my source code that combines the following parts.
- STM32F4 Discovery Board
- TrueSTUDIO for STMicroelectronics STM32 Lite 2.2 (they now have a 2.3 version out that I need to upgrade to)
- FreeRTOSV7.1.0
- FreeRTOS_ARM_CM4F (ver 2.0 from Thomas Kindler)
The TrueSTUDIO project runs a demo on the STM32F4 that uses FreeRTOS to do a couple of things.
- TIM4 is setup to provide smooth PWM output channels to control the four LEDs around the motion sensor.
- A task is used to query the MEMS motion sensor.
- The task reads the sensor every 15ms. This should be changed to interrupt based so full 100Hz data can be captured.
- The task averages the reads to get rid of sensor noise.
- Finally, every 180ms the four LEDs around the MEMS sensor have their PWM values updated based on the motion sensor values.
- A low priority debug task is used to send messages out over USART2.
- A really small vDebugPrintf function is provided that preforms like a classic printf.
- The vDebugPrintf provides for decimal, integer, hex, binary, and string values.
- Works just like printf, in that, it uses a variable argument list.
- Other task can simple call vDebugPrintf to queue a message to be set out on the uart.
- The formatted message is added the debug FIFO OS queue.
- The debug task runs at the lowest priority and does not use interrupts to send strings. This keeps the micro free to do real task and no be bothered with debug messages.
- Incoming characters are used to trigger debug events.
- As an example, the streaming of the motion sensor values can be controlled by using ‘M’ to start and ‘m’ to stop.
Well, I hope this source code helps others. The only cost to you to use is that you must agree to post some comments below letting me know how your experiences were with the new board and my demo code.
Link to Atollic project: STM32F4-FreeRTOS-Demo.zip
After downloading the zip file, simple extract the ‘Test1′ directory and move it into your Atollic workspace directory. Note, the Test1 directory path variables will need to be changed to match your installation of Atollic. Since I’m running TrueSTUDIO under VMWare the path statements are odd.
Good Luck,
Jim
Hi Jim,
I also bought the STM32F4 Discovery board the last week.
For the moment, I tested the FreeRTOS (for STM32F4) in the IAR Embedded Workbench lite and the MDK-ARM lite but this software limited at 32 Ko !! And the paid version costs more than 1000 € !!! So, I also try the Atollic TrueStudio !
Thanks for your exemple !!
Ronan.
Ronan,
Thanks for the comment.
Atollic makes it easy to install and run TrueSTUDIO. Their template code will setup and run code on the STM32F4 right away. Only one problem, Atollic assumes the external crystal is 25MHz. However, the STM32F4 Discovery uses a 8MHz. So, there is a little gotcha.
The first time you run TrueSTUDIO you will be asked to define a “WorkSpace” directory. Once you define that directory, you can simply extract my source code directory (called “Test1″) right into that WorkSpace directory. TrueSTUDIO will then allow you to open test1 as a project. You’ll need to adjust the library path statements before the project will build.
I’ve added a new post that should help with the changes you’ll need to make. Here is a link to the new posting:
http://ph-elec.com/archives/freertos-demo-and-truestudio/
I’m hoping the jpg images make it easier to make the changes.
Ronan, your on the hook now. You gotta report back and let me know how you made out.
Thanks,
Jim
One question I have regarding the FreeRTOS port. Will it properly support hardware floating point? I had heard there was a FreeRTOS port at one time that did not properly push / pop the floating point registers during a context switch.
The power in the Discovery kit is truly amazing. Regarding IDEs, LPCXpresso by Code Red which supports certain LPC products only give a 128K limit and is free. For a incremental fees you can increase the limit. I don’t think NXP there is an Xpresso board for M4 yet. I really like an ultra low cost system that can do something right out of the box without lots of BSP work.
John
John
Yes, this port of FreeRTOS does support floating point by pushing and popping the FPU registers. It was Thomas Kindler who sorted that out. His work can be found here: https://github.com/thomask77/FreeRTOS_ARM_CM4F
I agree, the TrueSTUDIO software from Atollic makes the STM32 micros really easy to use.
Don’t forget to have a look at this posting which will help you get the demo code running quickly:
http://ph-elec.com/archives/freertos-demo-and-truestudio/
Good Luck,
Jim
If I build with Atollic TrueStudio set for floating point code with the “Mix HW/ SW Implmenentation” all builds fine. However, if I switch to Floating Point = “HW Implementation” I get many errors of the type shown below. I believe “HW Implementation” was introduced recently in TrueStudio 2.3.
Any suggestions on how to get around this? I would like to use full HW floating point eventually.
c:/program files (x86)/atollic/truestudio for arm pro 2.3.0/armtools/bin/../lib/gcc/arm-atollic-eabi/4.5.1/../../../../arm-atollic-eabi/bin/ld.exe: error: src\utils.o uses VFP register arguments, BSPBase.elf does not
c:/program files (x86)/atollic/truestudio for arm pro 2.3.0/armtools/bin/../lib/gcc/arm-atollic-eabi/4.5.1/../../../../arm-atollic-eabi/bin/ld.exe: failed to merge target specific data of file src\utils.o
c:/program files (x86)/atollic/truestudio for arm pro 2.3.0/armtools/bin/../lib/gcc/arm-atollic-eabi/4.5.1/../../../../arm-atollic-eabi/bin/ld.exe: error: src\tiny_printf.o uses VFP register arguments, BSPBase.elf does not
c:/program files (x86)/atollic/truestudio for arm pro 2.3.0/armtools/bin/../lib/gcc/arm-atollic-eabi/4.5.1/../../../../arm-atollic-eabi/bin/ld.exe: failed to merge target specific data of file src\tiny_printf.o
c:/program files (x86)/atollic/truestudio for arm pro 2.3.0/armtools/bin/../lib/gcc/arm-atollic-eabi/4.5.1/../../../../arm-atollic-eabi/bin/ld.exe: error: src\system_stm32f4xx.o uses VFP register arguments, BSPBase.elf does not
c:/program files (x86)/atollic/truestudio for arm pro 2.3.0/armtools/bin/../lib/gcc/arm-atollic-eabi/4.5.1/../../../../arm-atollic-eabi/bin/ld.exe: failed to merge target specific data of file src\system_stm32f4xx.o
John
JohnDS,
I have not played with those settings. However, I would guess that the “Mix HW/SW Implmenentation” would be the right setting for the STM32F4 Discovery board. Pushing TrueSTUDIO to use only hardware implmenentation would force the compiler to generate assembly code for a full floating point coprocessor. The STM32F4 only has a single pression coprocessor.
Using “Mix HW/SW Implmenentation”, you can check if the compiler is doing the right thing by inspecting the compiler’s assembly output. A floating point multiply should take advantage of the floating point assembly language instructions.
You will need to take to make sure all your floating point calculations are using only single pression calculations. It’s my understanding that many of the library functions use double pression. Still, by using the “Mix HW/SW Implmenentation” you can still use double pression calculations – it’s just you don’t get the benifit of the floating point processor.
To really know what’s going on your going to have to look at the assembly language output.
Oh, and another tip, use the compiler option “-fsingle-precision-constant”. This will tell the compiler to assume floating point constants are single pression. Otherwise, you would have to declare floats like 3.141f to make sure they are single pression.
Hope this helps,
Jim
Thanks Jim. I found out the problem has nothing to do with FreeRTOS. It was apparently because I was only changing the floating point mode for the C-compiler and not the assembler and linker. I apologize for the error. I tried unsuccessfully to find a good defintion of what the floating point settings meant in the documenation.
Below I capture some assembler output with various FPU options selected. The last case (soft float) would not compile in my FreeRTOS project so I had to paste the code to a different project and the addresses may have shifted. Basically, it appears that for this case the HW and mixed case were the same, and the soft float branched to a multiply routine.
Hardware Implementation:
59 volatile float a = 1.1, b = 2.1, c = 0;
08000726: ldr r3, [pc, #92] ; (0×8000784 )
08000728: str r3, [r7, #12]
0800072a: ldr r3, [pc, #92] ; (0×8000788 )
0800072c: str r3, [r7, #8]
0800072e: ldr r3, [pc, #92] ; (0x800078c )
08000730: str r3, [r7, #4]
60 c = a * b;
08000732: vldr s14, [r7, #12]
08000736: vldr s15, [r7, #8]
0800073a: vmul.f32 s15, s14, s15
0800073e: vstr s15, [r7, #4]
Mixed SW/HW:
59 volatile float a = 1.1, b = 2.1, c = 0;
08000726: ldr r3, [pc, #92] ; (0×8000784 )
08000728: str r3, [r7, #12]
0800072a: ldr r3, [pc, #92] ; (0×8000788 )
0800072c: str r3, [r7, #8]
0800072e: ldr r3, [pc, #92] ; (0x800078c )
08000730: str r3, [r7, #4]
60 c = a * b;
08000732: vldr s14, [r7, #12]
08000736: vldr s15, [r7, #8]
0800073a: vmul.f32 s15, s14, s15
0800073e: vstr s15, [r7, #4]
SW Implementation : Other code changed but still have c = a * b.
47 c = a * b;
0800072e: ldr r2, [r7, #12]
08000730: ldr r3, [r7, #8]
08000732: mov r0, r2
08000734: mov r1, r3
08000736: bl 0x80001b8
0800073a: mov r3, r0
0800073c: str r3, [r7, #4]
48 }
JohnDS,
Wow, looks like you have done a lot of digging into floating point on the F4.
Here is a link to another forum that also has a lot of really good info about floating point + FreeRTOS:
http://sourceforge.net/projects/freertos/forums/forum/382005/topic/4761747
My source code was based on the work done by Thomas Kindler who is the moderator of the forum on SourceForge. He’s a good guy and very helpful. He was the guy who sorted out how to get FreeRTOS to perform preemptive task switches on the F4 Discovery board while using floating point. He appears to me to be a real expect on this stuff.
Jim
Worked perfectly the first time! Thanks!
One side note though: Atollic TrueSTUDIO V3.0.0 Lite (which has now integrated the TrueSTUDIO for STMicroelectronics STM32 version) seems to now have a 32KB limit as well (see first paragraph here: http://www.atollic.com/index.php/download/truestudio-for-arm). Sad. Exploring open source options at the moment.
Hi,
I downloaded Atollic TrueSTUDIO V3.0.0 Lite and your sample code and tried to compile it. I get a compilation error:
..\stm32f4xx_it.c:1:0: error: target CPU does not support ARM mode
If I run the compiler again this error moves to a different file, such as debug.c or heap_1.c. I have followed all the steps that you described but this error has stymied my efforts.
Are you aware of any obvious error I might be making?
Cheers,
Peter
Peter,
I suspect the problem may be with your Atollic installation of v3.0. My original work was done with v2.0.1.
I know Atollic made a lot of changes going to v3.0. The big change was, Atollic introduced a code-size limit (32k I think). That makes me crazy given how large the code space is on the F4 chip! I sent an email to Atollic pointing out how bad this idea is. I sent that email at least a month ago and I’ve gotten zero response. Makes me sad. The Atollic Lite package was perfect for folks to get started with Discovery board. OK, I’m getting into a rant here. I’ll stop.
I was going to suggest installing v2.x but now I comment #6 above from sjwilks who indicated he got it working with v3.0 “First Time”.
Does your installation work completely with an Atollic example program? In other words, use the Atollic wizard to build a skeleton / example program. If I remember right, there is an Atollic example that blinks an LED on the Discovery board. Can you get that to work? That would prove out the basic install of all the Atollic pieces and parts.
Once your sure Atollic is working at a 100% then make sure you extract my zip file into your Atollic workspace directory. Atollic should automatically show the new project in the project panel. If you don’t put my code in your “workspace” your just going to have problems.
If the Atollic examples are compiling and working and you dump my code into your Atollic workspace area everything should work. If not, let me know and maybe we can brainstorm some other ideas to try. Seems it’s always something silly that keeps things from working.
Good luck,
Jim