i am using IDE-Version: µVision V4.50.0.0 Copyright (C) 2012 ARM Ltd and ARM Germany GmbH. All rights reserved.
License Information: BINOD KUMAR EMC AUTOMATION PVT LTD LIC=----
Tool Version Numbers: Toolchain: MDK-Lite Version: 4.50.0.0 Toolchain Path: C:\Keil\ARM\BIN40 C Compiler: Armcc.Exe V4.1.0.894 [Evaluation] Assembler: Armasm.Exe V4.1.0.894 [Evaluation] Linker/Locator: ArmLink.Exe V4.1.0.894 [Evaluation] Librarian: ArmAr.Exe V4.1.0.894 [Evaluation] Hex Converter: FromElf.Exe V4.1.0.894 [Evaluation] CPU DLL: SARM.DLL V4.50.0.0 Dialog DLL: DARMP.DLL V1.51
can you tell me there is any difference between hex file of uvision4 version and uvision3 version of same source file. because i have hex file of both version of same source file but they are totally difference.
thanking you.
Guess what - whenever you change version of a compiler, the produced binaries tends to be different. The only real exception is the new compiler version just has a bug-fix, and the specific code wasn't affected by that bug.
A question: Do you think there are one, and only one, mapping from source code to machine instructions? The goal, when writing compilers, is to produce as good mapping as possible. So new compiler versions tend to produce different mappings.
thanks sir for your valuable time. but when i burn hex code of uvision3 in arm kit its work. and when i burn hex code of uvision4 which i mention above of same source file in arm kit its doesn't work.
its doesn't work.
And you really believe that is a description of your problem that will allow anyone to offer any kind of meaningful assistance? Really?
Do you also habitually call a car repair shop in a city 500 km away from your current location and ask "my car doesn't work --- what's wrong with it?"
Maybe the source code contains a bug that doesn't manifest itself until you change to a different compiler/linker where the generated code will look a bit different or where variables will have slightly different location in RAM.
Maybe you have a memory region that is too small, so you get a stack or buffer overflow.
Maybe the code only works with a very specific set of compiler flags, based on a specific assumption about the original compiler. An assumption that isn't correct anymore.
Maybe the project file contains incorrect configurations - but errors that doesn't hurt with the older compiler.
The normal way to proceed is to debug. To try to figure out if anything at all starts. How far you get before things seems to deviate. And this can happen before or after you reach main().
Let's say the project file happens to give the memory sizes for a larger model of the processor. Then a compilation that produces too much code or variables will not result in a build error. But will result in a failure when the code is loaded and/or run.
There are a million possible reasons why one build works and another build doesn't. Time to consider giving the debugger some quality time.