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
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.
That is insufficient reason for changing tools, particularly across a major version number step which typically signifies incompatible changes. There is a discipline called "configuration management" that deals with problems like that, and one of the primary rules of that discipline is: you keep the exact versions of all tools involved available throughout the foreseeable lifetime of the code. That means you ought to have Keil uVision 3 installed somewhere, or at least have the installation media and releated materials archived securely. If you had a contractor do the work, you should have made sure you get the tools as part of final delivery, and made them demonstrate that the final work can be built on your installation of the tools, bit-for-bit exactly as delivered.
Tools change from one version to the next. That's what new versions exist for. It may be possible to compensate those changes to some extent, but that's really a problem you don't need. How will you ever be certain that the resulting program, which will almsot certainly be different from the original version, still functions the same way, i.e. that you didn't introduce bugs just by patching the software for the new tools?
I still do almost all work with uVision 3 - because that is the version used for certifying all the code. It would represent a huge work to first perform all the testing again with a new compiler before biting the bullet and recertify everything.
So yes - it is imperative to make sure to keep used versions. And a new Keil version license is compatile with older versions of the tools. So I can move my tools to a new machine and on that have both new and old versions of the tools making use of the latest license.
Thanks a lot for your kind replies. According to your suggestion, this morning, I managed to find a colleague's PC with Keil 3 installed and try to use the right version to open the project.
I opened the project(written in Keil 3) and compile it by using the Keil 3, everything is fine. The .hex was built without any warning and error mesages. Howvever, when I downloaded the .hex to the hardware platform (LPC 2103), it does not work.
Using JTAG debugger, I found this crash is caused by invalid access of memory which further result in data abortion exception, and is taken over by the exception handler.
I was thinking/hoping the crash is caused by user program(usually it is), however, using unassembly tool, the invalid memory access is caused by RTX kernel itself (in the the task initializing stage), even before enter the "main function" of the program.
So could you please help me out on this problem?
Howvever, when I downloaded the .hex to the hardware platform (LPC 2103), it does not work.
You're going too fast. I mentioned the step about testing that you actually get the identical program file for a reason. You have to be able to re-create an identical hex file from your toolchain before you start making any modifications. As-is, you're probably still using slightly the wrong version of the tools themselves, and/or some of the supporting libraries. Or maybe some post-processing step was forgotten.
It is enough that the program contains __DATE__ or similar to make it impossible to recreate an identical program file.
But yes - it is important to make some form of validation of repeatability of builds.
Another thing is that the load process must also be repeatable. Are extra steps needed when programming the device?
Thanks for your kind help!
Seems in my previous post, I did not describe clearly.
The current situation is that: I did not change anything in the project, i.e. the source/header files, the startup.s, and the scatter file, as well as the flash tool settings in uvision 3 IDE.
What I did is just opened the project in uvision 3, compiled it, and then downloaded the generated .hex file to the hardware platform.
More details: I opened the project(written in Keil 3) and compile it by using the Keil 3, everything is fine. The .hex was built without any warning and error mesages. Howvever, when I downloaded the .hex to the hardware platform (LPC 2103), it does not work.
I guess there probably something wrong in the startup.s/ rtx_config.c, or the flash tool settings.
Since I cannot get in touch with the person who wrote the project to ask for the right source code/tool. So could you please help me out on this problem? or can you give me some suggestion which file I should look into?
Thanks a lot.
Then it's time for standard debugging.
You have enough stack?
Are the memory regions in the project correct for your processor?
You use a boot loader or is your hex file complete for bare-bones execution?
Does the clock settings seem to agree with your processor?
Thanks for your quick reply!
You have enough stack? ----I will double check.
Are the memory regions in the project correct for your processor? ----yes, for both scatter file and flash tool setting, there are same, i.e., on-board rom 0x0-0x8000, and on-board ram: 0x40000000-0x40002000.
You use a boot loader or is your hex file complete for bare-bones execution? ----My understanding is that the startup.s is responsible for loading the real Keil RTOS.
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.
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.