Forum : ARM
| Post Information | Post |
|---|---|
|
July 3, 2009 - 12:33pm
|
Dear sirs, Today i downloaded the Ride7 (7.20.09.162 ) and Rkit-ARM ( 1.20.09.0154 ) updates ( STM32F103RBT6 uP ) and came across some problems: - In my project i use the flash functions( FLASH_Unlock and others ) for reading and writing non-volatile settings. Unfortunatly, the project barfs at me at link time ( i defined _FLASH and _FLASH_PROG ) with all the FLASH_ functions as undefined reference. - In the old version i was using ( Ride 7.14.0001 and Rkit 1.13.0810 ), to define a custom flash area where i could safely store my settings i copied the STM32F103_128K_20K_DEF.ld linker script to my project directory and edited it as follows:
/* Memory Spaces Definitions */
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 20K
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 127K
USRFLASH (rx) : ORIGIN = 0x801FC00, LENGTH = 1K /* My settings area */
FLASHB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0
EXTMEMB0 (rx) : ORIGIN = 0x00000000, LENGTH = 0
EXTMEMB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0
EXTMEMB2 (rx) : ORIGIN = 0x00000000, LENGTH = 0
EXTMEMB3 (rx) : ORIGIN = 0x00000000, LENGTH = 0
}
This seemed to work quite well. However, when i now try to build the project i get the following warnings: Quote:
( I understand that the way i managed to make the linker reserve the flash area is probably not the right way to do it) My questions are thus: |
Hi,
Your previous manipulation was not a good idea, because you were making Ride believe that it was using the default script when in fact it was a modified one.
The new default ld files have two new regions called FLASHPATCH and ENDFLASH. For STM32 these regions happen to be empty, but still they must be declared by the _DEF.ld file or there will be an error.
Also note that the new version of Ride copies all the default linker scripts to the project's directory, while the old one was referencing them in \lib\ARM.
So what you should do is this: remove all .ld files from your project's directory, and link once using the default linker script option in Ride. This will probably fail because your source code puts data in USRFLASH section that doesn't exist. But we don't care because we just want Ride to generate and copy the default linker script in your project's directory.
Then, uncheck the "default linker script" option, and configure Ride for using the linker script it just copied in your project's directory. (take 'STM32F103_128K_20K_FLASH.ld' and not 'application.elf.ld')
Now you are using a custom linker script that is the same as the default. Then you just need to add your USRFLASH region and the associated section, re-link and all should be fine.
I hope it helps.
Best Regards,
Vincent
Vincent, thank you for your time to help me so far.
With your info i managed to get rid of the linker warnings, but problem 1 still exists.
Any idea on how i can get the FLASH_* back, or does that mean that i have to somehow recompile the STM lib?
( I would prefer a solution that not requires me to include stm32f10x_flash.c myself because that would probably break on any update of the Rkit )
Hi,
Some functions' names and/or prototypes have changed from one version of the ST lib to the other.
In fact the ST libraries are designed to be used like templates more than like 'real libraries'. That means you should include the source of the lib in your project and recompile it in any case. I know it might sound strange to some people, but that's how ST wants it... Just think about the lib as a set of templates/examples, not what most people call a 'library'.
In the next version we will even completely remove the precompiled version of the lib, as the different lib versions from ST are not compatible with each other, and so the precompiled version is more a trap than a help, as you experienced.
Then you handle the upgrades of Ride and the lib independently. You'll be able to upgrade one and not the other as you see fit.
Best Regards,
Vincent
Thx again Vincent,
Seems that including the sources is the only solution at this time then. ( Any ideas where the assert_param macro(?) should be defined, as it is used in the flash module source but it never pulls in any definition of it as far as i can see. *sigh* )
( Btw, some names might have changed but these FLASH_* functions did not when i examine the library sources which were installed by the Rkit. I'm not getting any "use of undeclared function" compiler warnings either, it just sizzles @linktime. No offense, but either i am doing something really stupid or someone forgot to include the flash sources ( or did it without defining _FLASH and/or _FLASH_PROG ) when building the Rkit? )
If you guys are gonna remove the precompiled library that would probably mean that most of the existing projects are gonna break? Also, does that mean that in the next version one would have to include all "library" source files? Or are we gonna make some sort of selection from the IDE and the IDE pulls em in by copying the source files to the projects directory? It all sounds like a maintenance nightmare waiting to happen tbh )
Did i mention that "Goto Definition" stopped working?
Kind regards and my apologies for sounding frustrated.
Tom
Hi,
I understand your frustration and I apologize for the issues you face.
In fact it IS a 'maintenance nightmare' as it is now: The problems you face and others similar were met by many people and the old projects are broken anyways because of lib functions changing names and prototypes, the need to recompile the lib if you don't have the same crystal as the ST demo board, etc.
In the end almost everybody ends up dropping the precompiled version and including the sources of the lib, which is the way they were designed to be used. And because of this it is very possible that a mistake in the generation of the precompiled lib has been made and was not noticed.
So when we remove the precompiled lib we will have a tough but relatively short adaptation time, and then it should be over with this problem. If we keep the precompiled version, the nightmare will go on forever...
Best Regards,
Vincent