I downloaded the source code of the Benf firmware from google code (DSO BenF v3 for IAR5.0.rar), compiled it succesfully, converted it to a dfu file and programmed it to the dso nano.
Allthough I did not make ANY modifications to the firmware it does not run. I don’t see the “APP Version” string in the bottom-right corner. Instead of this I see a strange box in the upper left corner (see attached picture).
As far as I know I use the correct LIB version for this APP version. The only problem that occured during build process of the IAR compiler was that the linker script could not be found, because it was set to an absoulte path that is not available on my system (D:\My Documents…). I fixed it then and used the linker script that was supplied in the package in the path “\DS0201_APP\project\EWARM\stm32f10x_flash.icf”.
Does anybody have an idea how to get rid of this problem?
This code is based on BenF’s latest open-source code. I try to maintain a single tree that works with all compilers. Previously there was code in svn on code.google.com also but it had different code trees for different compilers and it all did not make sense to me. Another issue I had with the svn repo was that it did not track changes back from BenF’s release. They just imported newer tarballs without common origin.
I was under the impression that IAR4 to IAR5 porting issues had been sorted out, but I’m not 100% sure (I’m using IAR4).
One thing to keep in mind is that you can not mix LIB and APP binaries from IAR4 and IAR5. That is if you compile and load an IAR5 APP, you must also load a LIB compiled with IAR5.
I have another problem when compiling the firmware:
I tried to compile the BenF 3.11 sourcecode with IAR and I get a linking problem:
Error[Li005]: no definition for “__program_start” [referenced from E:…\DS0201_APP\project\EWARM\FLASH\Obj\stm32f10x_vector.o]
I used the very recent IAR Embedded Workbench for ARM, 32K Kickstart Edition 6.10. Is this IAR version too recent, should I try IAR 5.0? If so, where do I get IAR 5.0 from?
My linking problem is not caused bij the IAR version. I have the same problem when using IAR 5.5.
The linking error:
Error[Li005]: no definition for “__program_start” [referenced from E:…\DS0201_APP\project\EWARM\FLASH\Obj\stm32f10x_vector.o]
is caused by the file “stm32f10x_vector.c”. This file contains the Vector Table for the microprocessor:
The reset vector is filled with the function __program_start(). This function is however missing in the BenF source code.
Does anybody have a solution? I could fill the reset vector with the main() function, but I do not know if this can be done safely.
__program_start() is in the start-up code provided by the toolchain. It mainly initializes memory before calling your main(). The linker adds this code to your own code, unless you disable it. Not sure what is up in your case, but you should for instance see it referenced by default under Project-Options-Linker-Config.
Hi Tormod,
Thanks for your answer. I saw that earlier code used
void __iar_program_start( void );
This works with me. Your reply assures me that this is a linker problem and can be influenced by the linker options. Soon I will start testing my FFT routine, so I keep my fingers crossed.
Just found this: iar.com/website1/1.0.1.0/926/1/
Apparently they renamed __program_start to __iar_program_start in IAR 5.
I should add some #define magic in the git tree to take care of this.
After compilation problems are solved, I managed to compile and link succesfully. However, I get EXACTLY the same error as xyphro described above. The application does not start properly and the left top screen shows a grey rectangle, as shown in the photo above.
I used the BenFv3forIAR5.0 release, as this project is compatible with the IAR version I have (5.4). Other releases use older IAR versions, which are not compatible with IAR 5.4 and therefore will lead in the project configuration file be converted.
As stated in “http://www.iar.com/website1/1.0.1.0/926/1/”: the project files (EWP and EWD) are converted by the IDE. You must remember to check the options after the conversion has been made. The linker options, for example, are reset to the default values.
I think this error must be a different IAR configuration. Can someone who uses IAR and has a configuration that works (gives running code) check his/her configuration with the configuration setting I have? These settings are listed below. Thanks very much.
[code]IAR Embedded Workbench 5.4
Project Options for DSO201_APP
General Options
Target
Processor Variant
Device = ST STM32F10xxB
Endian mode = Little
Output
Output file = Executable
Output directories
FLASH\Exe
FLASH\Obj
FLASH\List
Library Configuration
Library = Normal
Library low-level interface implementation
Semihosted
stdout/stderr = Via semihosting
…
C/C++ Compiler
Language
Language = C
Require prototypes
Relaxed ISO/ANSI
Plain ‘char’ is Unsigned
Optimizations
Level = High Balanced
Enabled transformations: all checked
Output
Genrated d i = unchecked
Code section name = text
List
2 x unchecked
Preprocessor
Ignore standard include directories = unchecked $TOOLKIT_DIR$\INC
Additional i d (opl)
$PROJ_DIR$…\library\inc
$PROJ_DIR$…\include
Defined symbols
VECT_TAB_FLASH
Assembler
Language
User symbols are case sensitive = checked
Macro quote chars = < >
Output
Generate debug info = unchecked
I do not know if the “DSO BenF v3 for IAR5.0.rar” has ever been reported to work correctly on IAR 5.0. There were some extra patches (by Antonio) to make it work in the svn repo which disappeared.
My git tree includes fixes for the same issues as Antonio was working on, so except for the __iar_program_start rename (which I will fix soon) it should work.
EDIT: Fixed up the git tree for IAR 4 and IAR 5 (untested). Feedback welcome.
I tested the gitorious code on IAR 5.4 and it doesn’t work. The IAR 5.4 version does not use the .xcl files as linker command files, but instead uses .icf files.
The .icf files are not included in the gitorious tree. Therefore I used two stm32f10x_flash.icf files from other project (BenFv3forIAR5.0). These files determine the ROM and RAM start location.
The stm32f10x_flash.icf used in APP defines ROM as 0x800C000…0x0801FFFF and RAM as 0x20001800 … 0x20004FFF (same values as in lnkarm_flash.xcl).
The stm32f10x_flash.icf used in LIB defines ROM as 0x08004000…0x0801FFFF and RAM as 0x20000000 … 0x20004FFF (same values as in lnkarm_flash.xcl).
When I tweak the Project - Options to use the linker command files and generate hex files, convert to dfu and load these files, the DSO nano will on startup display “Please connect to USB Host” and only accept uploading functionality.
I get exactly the same problem as Paulvvz with IAR 6. The linker configuration was also adjusted.
Maybe the location of the function table that is used to interface between the 2 projects is not placed at a fixed adres?
I really think Benf should have a look at this as there seem to be more people with this kind of problem and IAR4 is already VERY old and you can’t download it anymore.
In commit http://gitorious.org/dsonano/dso-firmware/commit/9710905cf1d6152b807bc732a032626bf0c2a4fe I added a segment called branchtab to the linker file (positioned first among the code segments so just after the INTVEC segment) which makes sure the function table has a (practically) fixed address. You will have to add this to your icf file (for LIB) as well.
I will look at the BenFv3forIAR5.0 icf files and add them to git. I guess IAR 5 can open the IAR 4 project files and convert it automatically, so we won’t need double sets of them. What is the default icf file name, if any? Or do you have to add one manually in the Options GUI?
In the worse case we would need EWARM4 and EWARM5 directories and keep them in sync.
The meaning of this branch table is unclear to me. I have to examine this further (or you can explain it a bit more?). I understand that the values in this branch table can be corrected from the generated .map file?
It is true that IAR 5 can open the IAR 4 project files (.ewd and .ewp) and convert them automatically, however information is lost in the conversion. There are no default .icf names, the linker options must be set in the project options (see below). Maybe you can download an IAR 5.4 version and try this.
It appears that IAR just drops all linker options when converting from 4 to 5. Nice. Wonder why we other people prefer gcc and make
I therefore split it up into EWARM4 and EWARM5 project directories. The LIB/EWARM5 linker file has an entry for the “branchtab” segment. Please test if that works. If it builds fine, but the DSO does not run, please send me your .map files.
Hi Tormod,
You dit it! It works!
Without changing a thing on the latest gitorious code, I was able to build it on IAR 5.4 and have the code running!
You are a hero! I do not understand what you did for solving this linker problem, but thanks very, very much. I will now continue on my FFT routine (my next challenge).
Thanks for your feedback guys, good to hear it works for everybody. I hope you will keep on testing whenever the repository gets updated so that we can keep it working for all compilers versions.
For the git tutorial, that was a particularly thorough tutorial, which I will recommend looking at, and going back to later. But you don’t need to know that much only to start using git as you would use another revision system. As many things, you have to use it and play with it to get the feeling for it. especially if you are new to the concept of revision systems, commits and branches etc. Start with pull, checkout -b, add, commit, merge and so on. One very useful thing after having messed up is: git reset --hard which brings you back to the commit in question, discarding any changes you did (on that branch).
