Hi,

Today I tried to compile a program for the STM32 Nucleo F103RB and got a bunch of errors:

Earlier this week another project of mine using the STM32F103 compiled just fine but I noticed today that there was an update symbol on the mbed library. I updated this to the new version and now it also does not compile anymore.

What happened ?

Problem seems worse: when I reverted back to a earlier revision (with the older mbed lib) the code compiles just fine and runs OK. Including the old mbed library in my new program also results in the program compiling and running on the new board. With or without the GPIO_InitTypeDef structure stuff.

A simple 'blinky' compiled with the new mbed library results in a non working binary.

If something isn't working please publish an example program and provide a link or embed it here using <<program /path to program >>

Also note the specific versions that work or don't work.

#include "mbed.h"

DigitalOut myled(PA_2);



int main()
{
    
    while(1) {
        myled = 1; // LED is ON
        wait(0.2); // 200 ms
        myled = 0; // LED is OFF
        wait(1.0); // 1 sec
    }
}

With the latest mbed library (96?) it compiles without errors but the LED does not blink, with the older rev. 95 mbed library it compiles and works OK

In my other project I used the GPIO_InitTypeDef and that gives the errors show above during compilation.

Hi, check the release notes https://developer.mbed.org/users/mbed_official/code/mbed/rev/487b796308b0

Your platform was updated to the cube driver. But LED should be still blinking.

Thanks I've confirmed this behavior using LED1 in place of PA_2. I'd suggest using mbed lib 95 or older for now. Looks like ST has been making some driver updates.

Hi All,

I know this is late, but I'm also having problems with the change from rev 95 to 96 using my Nucleo F103 board. The problems arise when I export to Keil - it won't compile any more (this is a simple blinky example, shown below).

/media/uploads/ptranter/main.cpp

I've worked my way back through the revisions until I found one that works. It lines up with mbed's move to Cube, I think, because the error is about a missing hal file:

.\build\Nucleo_blink_led.axf: error: L6002U: Could not open file mbed/TARGET_NUCLEO_F103RB/TOOLCHAIN_ARM_MICRO/stm32f1xx_hal_u: No such file or directory

Any version of the official mbed library >95 seems to show this error.

I have Middleware v6.5.0, CMSIS 4.4.0 and STM32F1xx_DFP 1.1.0

Reverting to earlier versions of Keil (v5.11) solves the problem, but its not ideal.

Help!

Hi Philip, can you please update to the latest revision ? You dont have any error when using the online compiler?

Ah I see u are using middleware, so are u using mbed - I am confused, you are mixing mbed lib with middleware and cmsis packs from keil?

Hi Martin,

Thanks for getting back. I am not using the Middleware, but for completeness I was trying to describe my setup of Keil.

Just to give you some context, I work in a UK University, and we started using mbed (ST Nucleo) with our yr2 students last year. In yr3 they progress to 'bare metal' ARM programming at register level and using CMSIS and the Standard Peripheral Libraries (using Keil). Its important for us to have single step debugging facilities, so the 'export to Keil' facility is really useful. It worked well all last year, but as I mentioned above, it has now stopped working. The latest successful setup I have been able to use is Keil v5.11 - I can make mbed compile on later versions of Keil if I use mbed library revision 95.

Basically, I compile Blinky on-line, to check its OK, then 'export' to Keil v4 (v5 not available?). I then migrate to 'packs', open it in Keil 5.14 (just done it now) and try to build. I get a linker error:

linking... .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol gpio_init_out (referred from main.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol mbed_assert_internal (referred from main.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol wait (referred from main.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol wait_ms (referred from board.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol SlaveCounter (referred from hal_tick.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol oc_int_part (referred from hal_tick.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol oc_rem_part (referred from hal_tick.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol set_compare (referred from hal_tick.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol us_ticker_irq_handler (referred from hal_tick.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol HAL_SPI_MspInit (referred from stm32f1xx_hal_spi_ex.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol mbed::FileSystemLike::opendir() (referred from retarget.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol mbed::FilePath::fileSystem() (referred from retarget.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol mbed::FilePath::file() (referred from retarget.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol mbed::FilePath::exists() (referred from retarget.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol mbed::FilePath::isFile() (referred from retarget.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol mbed::FilePath::fileName() (referred from retarget.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol mbed::FilePath::FilePath(const char*) (referred from retarget.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol serial_getc (referred from retarget.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol serial_init (referred from retarget.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol serial_putc (referred from retarget.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol stdio_uart (referred from retarget.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol stdio_uart_inited (referred from retarget.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol HAL_TIMEx_BreakCallback (referred from stm32f1xx_hal_tim.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol HAL_TIMEx_CommutationCallback (referred from stm32f1xx_hal_tim.o). .\build\Nucleo_blink_led.axf: Error: L6218E: Undefined symbol TIMEx_DMACommutationCplt (referred from stm32f1xx_hal_tim.o). Not enough information to list image symbols. Finished: 1 information, 0 warning and 25 error messages

Other things I have noticed: if I substitute mbed official library Revision 95 it does not have this problem, and compiles and links correctly. The download zip file size using rev95 is 474k, whereas for later versions jumps to >650k, so something is significantly different.

Other versions of Keil give different linker error messages, like the one in my earlier post.

I wondered if it was obvious from the above errors what is going wrong?

Sorry this has been so long-winded, but I really want to get this resolved if possible. I'd really appreciate some support with this, Martin.

Thanks

Phil

I think I may have discovered part of the problem.

I looked at the Keil 'Misc Controls' linker text box, and it has a list of references to all the mbed 'o' files. Unfortunately, there are multiple spaces between the file names in the dialogue box, and I think Keil ran out of string space (the truncated filename stm32f1xx_hal_u was the clue). I compacted the entries using the Keil text editor, and now it seems to work fine.

Not sure if the problem lies with mbed writing the Misc Controls entry, or Keil interpreting the incoming project file - or a combination?

I'd be interested to hear your opinion on this.

Thanks

Phil

At the possible risk of making a nuisance of myself. . .

I think that the problem lies in the uvproj file produced by the mbed 'export' function. It generates (XML) references to a list of '.o' files. These are padded by significant numbers of spaces in the XML, which get included as real spaces by Keil in the 'Misc Controls' entry in the Linker setup of the project.

Between v95 and v96 the number of these files increased considerably (and most include 'hal' in the name). The increased number of files seems to cause Keil to run out of string space in the Misc Controls box, and so the list gets truncated. Manually removing the spaces can 'fix' the problem (but is tedious!).

Can the generation of the exported uvproj file be reviewed?

Thanks,

Phil

Resolved . . . . .

Keil have now fixed this problem, which they describe thus:

'The reason is, mbed generated µVision projects contain an excessive list of object files in the Misc Controls of Linker options and at one point µVision cuts off the these object files. This issue has been resolved with MDK-ARM Version 5.17'

So if you get this problem, update to the latest version of Keil.

Phil