STM32F407 tutorial with CooCox

STM32F4 Development BoardBuying the development kit was easy, using it, proves to be 10x more difficult.  First of all you’ll need a good integrated development environment (IDE) and as Java architect I’m quite spoiled and I don’t expect anything less for my hobby projects where I use mainly C.  After doing some research I found a couple of very good IDE’s but unfortunately not free to use.  Until I came across CooCox’ CoIDE, reading the testimonials on the net and the documentation made me drool about its possibilities.  And what was even more astonishing, it is completely free!  I’m not a novice in development and I know how much time and effort software like this costs and I thought first that was too good to be true.  Until I started playing with it and I must say, this IDE is just great!

When I started to play with it, I felt somewhat in known territory… and indeed the IDE is based on Eclipse, the same one I use for my Java projects and some other C hobby projects.  CoIDE supports the standard GCC ARM tool set including a compiler, assembler, linker and debugger.  My board includes a ST-LINK/V2 which is supported by CoIDE for debugging and flashing.   The part of CoIDE that I love the most is the ‘Repository’, a point and click choice of the main processor or board, MCU library modules and a variety of peripherals.

Unlike the 8-bit microcontrollers, the STM32F4 is somewhat more difficult the operate.  I’ll show here how you can get your STM32F4 up and running very quickly.  The most difficult part is the setup of the MCU’s clock and debugging to a remote terminal (PC).  Let’s start with the easy part.

Install CooCox, ARM GCC and ST-LINK.

  1. Download ARM GCC, CoIDE and STM32 ST-LINK utility.  You need to register to be able to download CoIDE, but it’s entirely free.
  2. Install ARM-GCC first, all default parameters are OK.
  3. Install CoIDE
  4. Install STM32 ST-LINK utility.
  5. Configure CoIDE to use ARM GCC

Configure the STM32F4’s Clock.

Before, on 8-bit MCU’s, configuring the clock was already cumbersome; now on the 32-bit STM32F4 it’s even more complex.  But luckily ST was so nice to provide an Excel based Clock Configuration Tool:STM32F4_ClockWith this tool, configuring the clock is like a breeze;  in my case I used the external oscillator (HSE) and set it to 8 MHz, I filled in the desired HCLK of 168 MHz.  The Excel sheet did the rest…  You could enter all the values for yourself, but better is to let the tool generate a .c file that you embed in your project.  The tool generates a system_stm32f4xx.c, just put it aside for later.

Create a first project with blinking leds.

In our first project we’ll create a small program that is capable to blink the four leds on the discovery board and we’ll demonstrate semihosting.  Semihosting is a mechanism that enables code running on an ARM target to communicate and use the I/O facilities on a host computer that is running a debugger.  In other words send data back over the ST-LINK back to your computer.

  1. Click Create Project and name it Blinker
  2. Choose Chip (board could also do if your board is listed)
  3. Choose ST and STM32F407VG; click Finish
  4. In the Repository window’s Peripherals, click on GPIO (M4 CMSIS Core, CMSIS BOOT and RCC are auto-selected)
  5. Again in the Repository window, click on Semihosting (C Library and Retarget printf are auto-selected)

Selected Peripherals:STM32F4_Project

When configured correctly, your project structure should look exactly like mine.  Notice the file system_stm32f4xx.c in the cmsis_boot folder; you should replace this file with one generated by the clock calculation tool.

Now to get the clock running at desired speed all of this code needs to be called before the main program starts.  This is done by editing the startup_stm32f4xx.c file and uncommenting the SystemInit prototype first:

/*----------Function prototypes-----------------------------------------------*/
extern int main(void);           /*!< The entry point for the application.    */
extern void SystemInit(void);    /*!< Setup the microcontroller system(CMSIS) */
void Default_Reset_Handler(void);   /*!< Default reset handler                */
static void Default_Handler(void);  /*!< Default exception handler            */

and then calling it just before main() is called in the Default_Reset_Handler:

#ifdef __FPU_USED
  /* Enable FPU.*/ 
  __asm("  LDR.W R0, =0xE000ED88\n"
        "  LDR R1, [R0]\n"
        "  ORR R1, R1, #(0xF << 20)\n"
        "  STR R1, [R0]");

  /* Call the application's entry point.*/

Now your code should run at full speed, this is the first step for every project you create.  Next we want to use the semihosting to send data back over the debugger to the PC, to achieve this, we must rewrite printf or more concrete its PrintChar method.  Open the printf.c file and edit the PrintChar method and add a call to SH_SendChar just before the method’s closing bracket (remember to include the semihosting.h!):

#include "semihosting/semihosting.h"

 * @brief  Transmit a char, if you want to use printf(), 
 *         you need implement this function
 * @param  pStr	Storage string.
 * @param  c    Character to write.
void PrintChar(char c)
	/* Send a char like: 
	   while(Transfer not completed);
	   Transmit a char;

To enable the semihosting over the debugger, right click your project and select ‘Configure’, got to the ‘Debugger’ tab and enable the check box for ‘Semihosting Enable’.

This concludes the ‘difficult’ part, now comes the fun part; let’s actually create some code.  Put the following code in your main.c and start the debugger:

#include <stdio.h>
#include "stm32f4xx_rcc.h"
#include "stm32f4xx_gpio.h"

GPIO_InitTypeDef GPIO_InitStruct;

int main(void) {
	RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);

	GPIO_InitStruct.GPIO_Pin = GPIO_Pin_15 | GPIO_Pin_14 | GPIO_Pin_13
			| GPIO_Pin_12;
	GPIO_InitStruct.GPIO_Mode = GPIO_Mode_OUT;
	GPIO_InitStruct.GPIO_Speed = GPIO_Speed_100MHz;
	GPIO_InitStruct.GPIO_OType = GPIO_OType_PP;
	GPIO_Init(GPIOD, &GPIO_InitStruct);

	printf("Hello World!\r\n");

	while (1) {
		static int count = 0;
		static int i;

		for (i = 0; i < 10000000; ++i)
		GPIO_ToggleBits(GPIOD, GPIO_Pin_12 | GPIO_Pin_13 | GPIO_Pin_14 | GPIO_Pin_15);
		printf("%d\r\n", ++count);

If everything went well, you should see all four leds blinking at a pace of about 3 seconds and you should see the following output in the semihosting console of CoIDE:


This concludes my tutorial and hopefully it worked for you as well as it did for me.  This platform gives any ARM Cortex M4 developer a very powerful tool.  And I want to use this occasion to thanks the CooCox team of developers for the great product they delivered.

Tagged , , , . Bookmark the permalink.

67 Responses to STM32F407 tutorial with CooCox

  1. E. Murder says:

    Hi there,
    Great writeup! I’ve used the exact same setup and it has always worked for me. However, ST recently released STM32CubeMX which generates startup and configuration code, and since Coocox doesn’t support it directly, I was wondering if you could perhaps look into it?

    • pleyman says:

      I’ve seen the STM32CubeMX, it seems to be a very helpful tool for the STM32 family. Unfortunately it won’t work directly with CoIDE, Cube doesn’t support Eclipse (the base for CoIDE) yet. To make it work integrated with CoIDE, ST needs to port for Eclipse first (for which they have plans). Once this is done, it will be quite easy to embed it in CoIDE.
      On the other hand I think it might be possible to use both tools, a bit like we use the Excel based tool for the clock. I’m unsure how much the generated code by Cube deviates from the one generated by CoIDE, but it might be possible to copy the generated files in CoIDE. I’ll give it a try and if, I succeed, I’ll post a new topic here…

      • Aditi says:

        Hi Patrick,

        Which version of CooCox did you use? I am using the latest version and it is very confusing and different. I would rather use an older, stable and sensible version so please let me know the version number!

        Many thanks for the great post!


        • Patrick says:

          Hi Aditi,
          At the time this post was written it was version 1.6.x, now I’m using 1.7.7. I tried the 2.0 version, but I didn’t like it and rolled back to version 1.7.7; much easier to use…

          • Aditi says:

            Thanks, I’ll try that!
            Aaron’s tutorial below makes use of a different version of the CoIDE V2Beta. I am in process of running through that. Have you gone through that tutorial yet?

          • Patrick says:

            Yes I did, and it is working quite well. Aaron made a great tutorial. But all depends on how you have configured your current working environment and how much existing code (libraries) you already have. When you have a lot of libraries that you re-use throughout your projects, it will be quite some work to transform everything for a new environment.

  2. Paulo says:

    Thanks a lot, this was real useful! i was just wondering how does the STM32F4 sends data through the printf function back to the host. Does it use UART or JTAG or something else?
    Also can you send data back from the Host to the STM32F4? scanf, something like that?
    My Discovery Board will arrive in a couple of days!

    • pleyman says:

      Hi Paulo, thanks for the compliment!
      The printf sends it data back via JTAG by adapting the PrintChar method in the printf.c file as explained in this blog. Theoretically it should be possible to send data back from the host to the board, although I never tried this.
      Enjoy your board when it arrives, at least I already a lot of fun with it!

  3. Ivan says:

    Hi great text! Worked from first! Tnx a lot!
    Also I have one question, if i connect it without debugger, LEDs just turn on and they doesnt blink. How can I make them blink?

    • pleyman says:

      Thanks for the compliment!
      When you don’t use the debugger, you’ll have to remove the printf statements from the code. The printf uses the semihosting’s printchar method which requires the debugger to be connected, otherwise the method simply locks up (I guess a hardfault). So the easy solution is to remove the printf statements in the code. The hard solution is to rewrite the semihosting’s printchar method that it can detect the presence of the debugger.

  4. Ivan says:

    It works!!! Thx for quick reply! Cheers!

  5. Please let me know if you’re looking for a article author for your blog.
    You have some really good posts and I believe I would be a good asset.
    If you ever want to take some of the load off, I’d really like to write some
    articles for your blog in exchange for a link back
    to mine. Please shoot me an e-mail if interested.

  6. Arun Sharma says:

    I did the same thing, but it is not working for me.
    Can anyone please help me, i had posted the problem here.

    and i am using LPC1343 CoLinkEx and CoIDE v 1.7.7

    • Patrick says:

      I checked your post and your code is correct. By looking at the screenshots, I’m guessing that that you enter the code with a breakpoint right away. Semihosting requires quite some clock cycles to get the data through the SWD. Let the code run for a while and you will see the characters appearing in the semihosting window.
      Semihosting cannot be used for realtime debugging.

  7. Heya i am for the first time here. I found this board and I in finding It truly useful & it helped me
    out much. I hope to provide something back and help others such as you aided me.

  8. yoe says:

    Hi.. This is excellent tutorial. Thank very much man..
    I tried to connect with RN42 bluetooth module. but i don’t know how to communicate between STM32 Board and Bluetooth module. Could you share some idea how to use serial using STM32F4?

    • Patrick says:

      Thanks for the compliment.
      You’ll have to connect the RN42 to one of the STM32F4’s UARTs. I didn’t use the UART yet on the STM32 myself, but a colleague blogger did and wrote an excellent tutorial (unfortunately in German)

  9. Amarendra Wijaya says:

    I’m trying to build a lux detection using Nuvoton NUC140 board in CooCox CoIDE program.
    However it keeps getting an error that said:

    ..\obj\startup_NUC1xx.o:(.co_stack+0x0): multiple definition of `pulStack’
    [cc] ..\obj\startup_coide.o:(.co_stack+0x0): first defined here
    [cc] ..\obj\startup_NUC1xx.o:(.isr_vector+0x0): multiple definition of `g_pfnVectors’
    [cc] ..\obj\startup_coide.o:(.isr_vector+0x0): first defined here
    [cc] ..\obj\bh1750fvi.o: In function `BH1750Init’:
    [cc] C:\CooCox\CoSmart\workspace\luxsensor\CoX_Driver\bh1750fvi/bh1750fvi.c:110: undefined reference to `xI2CMasterEnable’
    [cc] ..\obj\bh1750fvi.o: In function `BH1750Configure’:
    [cc] C:\CooCox\CoSmart\workspace\luxsensor\CoX_Driver\bh1750fvi/bh1750fvi.c:151: undefined reference to `xI2CMasterWriteS1′
    [cc] C:\CooCox\CoSmart\workspace\luxsensor\CoX_Driver\bh1750fvi/bh1750fvi.c:152: undefined reference to `xI2CMasterWriteS1′
    [cc] C:\CooCox\CoSmart\workspace\luxsensor
    [cc] \CoX_Driver\bh1750fvi/bh1750fvi.c:157: undefined reference to `xI2CMasterWriteS1′
    [cc] collect2.exe: error: ld returned 1 exit status
    –Deleted source code–
    Do you have any suggestions about my program?
    Please help

    Sorry for the long post.

    • Patrick says:

      I deleted a portion of your comment as it was not relevant for the error you get. And I moved the comment to this post where it makes more sense.
      The error is caused by the linker which cannot find the library or compiled sources for the three functions mentioned in ‘undefined reference’. In CooCox make sure that all the .c files that implement these functions are present in the project’s structure. If they are part of a precompiled library, you must reconfigure the linker so that it can locate that library.

  10. Eagle7 says:

    Thanks for article. Very well!
    If I had to use the STM32F4xx_HAL_Driver. Is possible? How? I a code for IAR that uses HAL_driver and I would compile with gcc in coocox. Is possible?. Thanks for your help.

    • Patrick says:

      Libraries compiled for IAR are in general not compatible with gcc. If you have the sources of the driver, you could rebuild it.
      On the other hand, check the CooCox repository, you might find one developed by someone else. About which HAL device are we talking?

  11. Eagle7 says:

    Thanks for your answer. It ‘a STM32F417VG. I have the sources i tried to rebuild it. The compilation is linker is okay but I have a .bin and a .elf of 0 kb and do not understand why.
    Thank you again for your help.

    • Patrick says:

      hmm, never encountered a zero byte .elf. Sounds like the configuration of the MCU is not right in CoIDE.

      • Eagle7 says:

        I have not used the “repository” of CoIDE I just brought all of the code used in IAR. Do you think it recommended to use the “repository”?

        • Patrick says:

          Yes, I would not recommend to work without! The repository configures the makefile according to the chosen device. This might explain why you have a zero byte .elf. The Cortex M4 is a quite complex micro controller; trying to compile and link the code without the repository is quite difficult; I never managed to build a project without it.

  12. pras says:

    hi i have problem in multiple definition on my program, i want to read ahrs sensors on stm32f3, this is the log :

    GCC HOME: C:\Program Files\GNU Tools ARM Embedded\4.9 2014q4\bin
    [mkdir] Skipping E:\kuliah\ARM\usart+bluetooth\usart\Debug\bin because it already exists.
    [mkdir] Skipping E:\kuliah\ARM\usart+bluetooth\usart\Debug\obj because it already exists.
    [cc] Starting dependency analysis for 15 files.
    [cc] Parsing ..\..\..\cmsis_boot\stm32f30x.h
    [cc] Parsing ..\..\..\cmsis\core_cm4.h
    [cc] Parsing ..\..\..\cmsis\core_cmInstr.h
    [cc] Parsing ..\..\..\cmsis\core_cmFunc.h
    [cc] Parsing ..\..\..\cmsis\core_cm4_simd.h
    [cc] Parsing ..\..\..\sensors.c
    [cc] Parsing F:\initKu.h
    [cc] Parsing ..\..\..\MadgwickAHRS.c
    [cc] Parsing ..\..\..\sensors.h
    [cc] Parsing ..\..\..\MahonyAHRS.c
    [cc] Parsing F:\InitKu.c
    [cc] 13 files are up to date.
    [cc] 2 files to be recompiled from dependency analysis.
    [cc] 2 total files to be compiled.
    [cc] arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -Wall -ffunction-sections -g -O0 -c -DSTM32F303VC -DSTM32F30X -IE:\kuliah\ARM\usart+bluetooth\cmsis -IE:\kuliah\ARM\usart+bluetooth\cmsis_lib\include -IE:\kuliah\ARM\usart+bluetooth -IE:\kuliah -IE:\kuliah\ARM -IE:\kuliah\ARM\usart+bluetooth\cmsis_lib -IF:\ -IE:\kuliah\ARM\usart+bluetooth\cmsis_boot E:\kuliah\ARM\usart+bluetooth\main.c E:\kuliah\ARM\usart+bluetooth\sensors.c
    [cc] In file included from E:\kuliah\ARM\usart+bluetooth\main.c:2:0:
    [cc] E:\kuliah\ARM\usart+bluetooth\sensors.c: In function ‘UpdateGyroBias’:
    [cc] E:\kuliah\ARM\usart+bluetooth\sensors.c:161:3: warning: implicit declaration of function ‘Delay_1ms’ [-Wimplicit-function-declaration]
    [cc] Delay_1ms(1000);
    [cc] ^
    [cc] In file included from E:\kuliah\ARM\usart+bluetooth\main.c:2:0:
    [cc] E:\kuliah\ARM\usart+bluetooth\sensors.c: In function ‘getEulerAsArray’:
    [cc] E:\kuliah\ARM\usart+bluetooth\sensors.c:418:7: warning: unused variable ‘i’ [-Wunused-variable]
    [cc] int i = 0;
    [cc] ^
    [cc] E:\kuliah\ARM\usart+bluetooth\main.c: In function ‘main’:
    [cc] E:\kuliah\ARM\usart+bluetooth\main.c:9:2: warning: implicit declaration of function ‘initUSART1’ [-Wimplicit-function-declaration]
    [cc] initUSART1();
    [cc] ^
    [cc] E:\kuliah\ARM\usart+bluetooth\main.c:16:6: warning: implicit declaration of function ‘speed1’ [-Wimplicit-function-declaration]
    [cc] speed1(600);
    [cc] ^
    [cc] E:\kuliah\ARM\usart+bluetooth\main.c:17:6: warning: implicit declaration of function ‘speed2’ [-Wimplicit-function-declaration]
    [cc] speed2(300);
    [cc] ^
    [cc] E:\kuliah\ARM\usart+bluetooth\main.c:18:6: warning: implicit declaration of function ‘speed3’ [-Wimplicit-function-declaration]
    [cc] speed3(300);
    [cc] ^
    [cc] E:\kuliah\ARM\usart+bluetooth\main.c:19:6: warning: implicit declaration of function ‘speed4’ [-Wimplicit-function-declaration]
    [cc] speed4(300);
    [cc] ^
    [cc] E:\kuliah\ARM\usart+bluetooth\main.c:7:6: warning: unused variable ‘i’ [-Wunused-variable]
    [cc] int i;
    [cc] ^
    [cc] E:\kuliah\ARM\usart+bluetooth\sensors.c: In function ‘UpdateGyroBias’:
    [cc] E:\kuliah\ARM\usart+bluetooth\sensors.c:161:3: warning: implicit declaration of function ‘Delay_1ms’ [-Wimplicit-function-declaration]
    [cc] Delay_1ms(1000);
    [cc] ^
    [cc] collect2.exe: error: ld returned 1 exit status

    Total time: 2 seconds

    • Patrick says:

      This is a typical linker error. The warnings during compilation indicate that some prototype for functions you developed/used were not found (speed1, speed2, speed3, speed4 and Delay_1ms). The (pre-)linker (collect2.exe) then fails with error: ld returned 1 exit status
      Make sure that a) you include the correct header files (.h) in your code and b) that each header has correct a correct implementation (.c)

  13. Vishnu says:

    I have done exactly as said it this tutorial. But the semihosting window does not open at all and the LED’s do not blink they remain on. Please Help.

    • Patrick says:

      Could be lots of things, I don’t have enough information to help you out. Try debugging the application and see were it get’s stuck…

  14. Cyclo says:

    Hi Patric,
    Thanks for the helpful post.
    I’m having several problems with my very first STM32 and CooCox project.
    IDE version is 2.0.0. Selecting components and the way they list down is different from your screen shot. But I managed to add the required components. IDE doesn’t allow me to edit the component source files in the editor.
    startup_stm32f4xx.c file ( startup_stm32f407xx.S in my setup) is seems to be an assembly file, not a C file. I have no clue how to do the changes in the file.
    Without doing any alterations, I just compiled the source. It gives me an error in linking. It refers to a HAL file. HAL prototypes are getting included with cmsis boot and I cannot remove them (unless I delete those files from the project)
    Any idea on what I have done wrong?
    Thanks a lot

    • Cyclo says:

      I found this issue mentioned in the forum and added a reply there as well

      • Patrick says:

        I looked at your reply in the forum.
        The problem you have is that the printf function has encountered a problem during the compilation. The impure pointer is part of the C running stack; when you have a problem with that, it is usually linked to the parameters you pass in functions.
        In your case I would check all the printf statements you have and check the passed arguments. Make sure they’re not empty or considered empt; for instance printf(“\n”) could cause an error like this.

        • Cyclo says:

          Thanks Patrick for your very quick response!

          Thanks for the info. Actually I haven’t written a single line of code. I’m just trying to build the project so that I know there is nothing wrong in the setup. Only change I’ve done so far is replacing the system_stm32f4xx.c file generated from Excel tool.

  15. Cyclo says:

    Commenting the line struct _reent *_impure_ptr = &r; in printf.c would fix the above problem.

  16. Aaron says:

    Hello Patrick et al. I have developed a couple of tutorial projects that show you how to use ST’s new CubeMX code generator along with CoIDE. Yes it is absolutely possible and really not that hard. I will leave a link below to a DropBox folder which contains two ZIP files and a readme. Each ZIP contains a PDF document that walks through the tutorials step-by-step, along with the complete file directory structure for the resulting project. The first project, Blinky407 is a first tutorial on bringing up a basic CubeMX generated project and using CoIDE as the build and debug environment for the project. As the name implies the resulting code is a useless simple LED blink routine however it provides the foundation platform for complicated and creative projects.

    The second ZIP file similarly contains a PDF with the step by step tutorial, along with the complete project directory structure. This second project however results in what I think is one of the most useful components for embedded project development- a working console I/O port using the on-chip USB controller found on many ST microcontrollers and boards, as a virtual COM port to communicate through stdio calls to talk with a host PC or other device. If people find these useful I have a few more on the drawing board that I can put up relatively easily.

    DropBox link:

    • Patrick says:

      I downloaded the zip and quickly ran through the tutorial. It looks great‚ I’ll try this out for myself.
      Thanks for this!

      • Aaron says:

        just one update. I fixed a bug in the console application and reposted it this morning, so if you downloaded the second ZIP you might want to get the newer version. It doesn’t affect the tutorial but it fixes some problems with stdio based console input from the PC to the board. Enjoy.

        • jfmateos says:

          Thank you very much Aaron… Today I have received my STM32F4 discovery and made my first blink LED program following your tutorial.
          I would love to see more of this kind of tutorials (I would like to learn to use external interrupts).
          Thanks again and congratulations.

        • Aditi says:

          Hello Aaron,

          I am trying to use your tutorial to work on an STM32L1 board “STEVAL-IKR002V3”. This board does not have Cube support (not much of any support actually). So I will have to use the chip and work on all the peripherals I need. Do you have any suggestions on how to go about that? The application is Low RF Communication. Any input would be nice!


          • Patrick says:

            Try to create a project in CubeMX that looks exactly like your development board, save it, and then use a copy to start your own project based on that board.

    • luser says:

      I’m trying to download this tutorial, but the file seems to be deleted from Dropbox.

      can you upload it again somewhere?

  17. malboo says:

    hi patrick,
    i try to download clock config and st-link utility from stm web site but failed, i tried several days already but never ending “loading” everytime i click download button on it. do you know any mirror site or other way i can get it. thanks.

  18. Mothiram says:

    Hi patrick,
    For configuring the clock i downloaded the tool and enabled the macros and activeX settings but to enter new frequency values its opening one project file with the name VBAPROJECT and asking password ….
    please help me out from this

    Thank you.

    • Patrick says:

      Weird should work without any hiccup… Maybe the file got corrupted; try to download a new copy.
      What version of Excel are you using?

  19. Ronaldo says:

    First of all, thanks for this information. I’m new to microcontroller programming, and this example is the first thing I managed to compile and run using the board I got (Port407Z).

    I changed the port and port numbers to match the installed on-board leds (A4-A7) and it runs fine, but some 10 times slower as it should. I think I may be missing something about the clock configuration, but I’m not sure. I’m using the spreadsheet and the same parameters as you (the built-in crystal is 8 MHz), the MCU is an STM32F407ZET6, but I don’t know what I could be doing wrong. Any suggestions?

    • Patrick says:

      You’re welcome!
      Looks like you forgot to initialise the clock or call the function that sets it up.
      Check the code generated by the clock utility (Excel sheet) and make sure that it is compiled alongside your other code.
      Did you call the SystemInit() function somewhere? I usually add it to the startup_stm32f4xx.c. But it can be called anywhere as long as it is called before you enter your main loop.

      • Ronaldo says:

        Unfortunately yes, I uncommented SystemInit(), as you told people to do… But thanks for trying to help, it would be hard to tell what went wrong remotely. I wish it would be such an easy mistake 🙂

      • Ronaldo says:

        System_stm32f4xx.o appears to be part of the linking process, so I guess that means the file generated by the Excel sheet is being reached. I’m also printing SystemCoreClock to Semihosting and getting the expected 168000000

  20. Makinde says:

    Thanks a lot!!! got it working for the first time!!

  21. Benzopal says:

    There’s a syntax error in the STSW-STM32091
    Clock configuration tool for STM32F40x/41x microcontrollers (AN3988) for the simple reason it issues a wrong matched array variable in ‘If (PLLUSB_table(i1, i2, i3) Like “1”) Then’ when it was declared as ‘Dim PLLUSB_table(0 To 61, 0 To 240, 0 To 3, 0 To 11) As String’. Obviously this is wrong and renders the tool definitely erroneous at some level.

    • Patrick says:

      Working for me… But I open the worksheet in Excel in compatibility mode; the code is not compatible with the latest versions of Excel.

      • Benzopal says:

        I got rid of LibreOffice and installed OpenOffice 4.1.1. That solved the syntax problem. It must be that there are Macros that change the Basic according to circumstances. The conflict in the code was obvious to see.

  22. Benzopal says:

    Why is enabling the FPU not part of the System Initialisation? Why the machine code? Aren’t we in an IDE that serves this? Isn’t there any C-code to take care of this to stay into the realm of that language?


    • Patrick says:

      Just right click your project, Configuration, Compile and select FPU (not used, soft or hard). The necessary options will be added to the Compiler Control String.

  23. Benzopal says:

    Yesterday I discovered CooCox is only for Windows. It is based on Eclipse says the site owner. How can it be based on Eclipse, which is available for all popular platforms, when CooCox is only available for Windows? I know, CooCox is the results from hacking through Eclipse source code and rebuilt on a Windows system. The developer(s) responsible for this seem to have a hard time porting their work to the two other platforms Linux and Apple OS. But hey, isn’t Eclipse supposed to run from a JAVA runtime repository? What did the CooCox developer(s) do to give themselves such a hard time making Linux and Apple OS versions available? This has been requested for over 3 years without result.

    • Patrick says:

      It is Eclipse based, but the launcher (CoIDE.exe) is dependent on the platform. If you don’t use this launcher, you can launch Eclipse/CoIDE on any platform as long as you have Java installed.
      I’ve never tried this with CoIDE, but you could launch manually a JVM from a command line with the settings from CoIDE.ini. This works with a native Eclipse and should work with CoIDE as well. Check the Java command line options and assign the correct ones with the info from the ini file.

      • Benzopal says:

        You mean CoIDE launched with the exe launcher doesn’t need JVM? That’s awkward. I know we cannot access CoIDE from Linux if it is one big exe file. If I understand well then I should install it on a Windows system (or WINE in Linux), look for that CoIDE.ini file and rename it to eclipse.ini … probably. Let’s see how that works … I’m curious why the CooCox folks find it so troublesome to add this manual startup from Linux.

        • Benzopal says:

          Thx for the advices by the way.

        • Patrick says:

          The launcher starts the JVM with all required parameters; this launcher acts as a wrapper (you won’t see a Java process running). I’ve been reading through the posts where developers are requesting a Linux version, and I think that the launcher might hold more code than a regular Eclipse. I guess that they also included some drivers for the USB/Serial port for the programmer/debugger. I’m afraid that WINE might be your only option for the moment…

          • Benzopal says:

            Well, I had no luck with WINE accepting the drivers.

          • Patrick says:

            Oh damn, there you have it… That’s what I was afraid of, the drivers only work under Windows and that’s why CooCox never bothered to make CoIDE multi-platform. Pity!

          • Benzopal says:

            And still, there’s no reason to not bother since we know successful uploads to MCU’s have been made from inside Eclipse under any platform running from JAVA runtime.

            My take is they have no access to Linux. Why go machine dependent if you start from a JAVA project anyway, so.

            Win was complaining about not finding winusb.dll and another USB dll that was ST-LINK specific. winusb.dll was nowhere to be found and the ST-LINK specific usb dll file was both in the CoIDE folder and in System32 not recognized. Wine was blind to it.

  24. Benzopal says:

    CooCox is after all Chinese. If they use a cracked Windows version as platform it’s no wonder they can’t bother about porting to Linux. Probably Linux is blocked in China … Who knows.

  25. sscarrion66 says:

    Hello Patrick. Congratulations for your interesting blog.

    I’m beginning with CoIde and trying to make it work with the new CubeMx code. The link to Dropbox that Aaron posted isn’t avaiable. Do you keep a copy of his work?

    Tank you.

Leave a Reply

Your email address will not be published. Required fields are marked *