Same Keil version, different output files

project setings?

also the 'deep' ones (menu selected from menu selected fom menu.

Erik

This is one scenario where Makefile-based build system is superior to an IDE: you have complete trasparency regarding build tool settings.

How do you know the build images are different? Maybe the JTAG programmer has problems on different machines.

I compared the output hex files and the map files. My "Options for Target" are the same!
Where are the deep settings?

"This is one scenario where Makefile-based build system is superior to an IDE: you have complete transparency regarding build tool settings." - Is there any workaround in this situation?

Is it possible that KEIL was not installed completely correct and this causes the problem?

Actually you can use one IDE for several compiler variants. Check also Components, Environment and Books settings on both computers.

Components, Environment and Books are also the same. Can I change the compiler just copying the .exe to the keil/ARM/ARMCC folder?

I seem to remember that the Watcom compiler would limit the extent of some optimizations depending on the amount of memory available. I doubt RealView tools would do the same, though.
Why don't you use a tool like WinMerge to compare build folders on the two machines?
By the way, make sure you don't embed build time into the image (through the use of __TIME__ or similar).

Thanks, I'll try it with WinMerge!
Also no __TIME__.

a quick check would be if both versions of the code run as expected

I have had similar after updating the IDE
e.g compile debug the system then update the Keil tool then rebuild and the embedded system does not run as expected.

remove all the IDE files apart from the uvision project file.
remove all the output files

reset the flash programming algorithums in the debugging tab
rebuild and reprogram the embedded system and the thing works as expected.

works for me and I do this as standard now whenever the tool is updated

__DATE__ (and __FILE__ if the pathnames are different) are also possibilities.

Do you know where in the .axf/.o files the differences are? fromelf --compare can be useful for this. Start by comparing the .axf files, find the first difference (probably ignoring .debug*). The use a link map to figure out what .o files it came from. The compare the .o files. Or convert them to text with fromelf and compare the text.

The differences are in:
system_stm32f4xx.o
stm32f4xx_rcc.o

There are __DATE__! So, the difference could be because of this also...
But one very interesting thing:
I used a simple project just with the UART and LEDs.
Programming with the one computer, it works, Programming with the other - it gives wrong characters.
But when I copy the stm32f4xx_rcc.o file from the computer where it works to the second and built the project, UART works correctly.

So, I suppose it can't be from just because of the __DATE__!

"a quick check would be if both versions of the code run as expected

I have had similar after updating the IDE
e.g compile debug the system then update the Keil tool then rebuild and the embedded system does not run as expected.

remove all the IDE files apart from the uvision project file.
remove all the output files

reset the flash programming algorithums in the debugging tab
rebuild and reprogram the embedded system and the thing works as expected.

works for me and I do this as standard now whenever the tool is updated"

I tried it out, doesn't work :(

uhmm
because system_stm32f4xx.c is involved in setting all the clocks
If you use a different clk that would cause a baud rate difference.

check for the definition of the HSE clk.

I use the stm32f2xx and Keil had a default for the HSE in the enviroment and there is a HSE setting in the source files.

I use the stm32f2xx and Keil had a default for the HSE in the enviroment and there is a HSE setting in the source files.

Ah, the joy of using so-called 'libraries'!
I wonder if they solve more problems than they create.

check the system_stm32f4xx.c and where the project is picking it up from

If you use a different HSE clk than the standard default Keil value and demo boards you will need to make sure all the clk rates are correct.

I use a 8 mhz clk rather than the 25Mhz on the eval board so had to use the STM excel app to generate the file.