I have a project which was completed by another persion by using uvision 3. Recently I plan to add some new fuctionalities in this project. Since I only have uvision 4 on my machine, so, I plan to use uvision 4 to open the project and see if I can complie the project.
Without touching anything of the source and header files, I opened this project using uvison 4. However, when I compiled this project, there was an error message, "_swi_0 multiply defined in hal.o and rtx_config.o".
Is it caused by the toolchain upgrade? could anyone help on this issue?
Thanks a lot!
The hardware platform is LPC 2103 (Arm-7 core based) RTOS: keil MDK RTOS
Louis
What I did is just opened the project in uvision 3, compiled it, and then downloaded the generated .hex file to the hardware platform.
We know. You already told us that yesterday. And as I also already pointed out yesterday, you missed a crucial step in that sequence. There's no point flashing the .hex file to the hardware yet. Before you do that, you have to compare it to the official release .hex file that's currently in production. You have to find perfect explanations for every bit of difference between those two files. As long as there are unexplained differences, there's no point trying that hexfile on hardware, because you already know it's not the right hex file.
Note that "uVision-3" was shipped for several years with various different versions of the other tools (compiler, linker, etc) - as was uVision-2 before it, and uVision-4 after it.
So just saying "uVision-3" is not sufficient to know that you have the same tool chain that was used previously!
and that would include different versions of RTX...
But with a valid license, Keil should be able to help out with a specific version of the tools - which would obviously require that the exact tool version is documented in the project documentation.
Thanks all for your replies, your suggestions are very helpful.
I will check the differences between the 2 .hex files (one is generated 2 or 3 years ago which can work, one is just built by me which does not work).
I will update the result in the forum.
Thanks Louis
In case you find out that the files are identical you might want to read this article that explains why debugging on those devices is sometimes leading to weird behaviour:
http://www.keil.com/support/docs/2767.htm
> Does the clock settings seem to agree with your processor ----The frequency of the external crystal is 14.7456MHz, which is same as startup.s and the rtx_congig.c settings. <
It seems that startup.s and rtx_config.c are fine.
Maybe the answer of the following questions would be obvious and irrelative, but:
Are all the *.c files, *.h files, and library files included in the project package? Or some of them are relied on the host PC' Keil directory?
LPC2103.h?
>My understanding is that the startup.s is responsible for loading the real Keil RTOS.<
This does not mean that, no boot-loader exists.