Code doesn't run when built with UVision4

There must be at least 5 years between uVision-2 and uVision-4 - possibly longer if it's a very old uVision-2, and the very latest uVision-4.

"There are no modifications to the code, the only (sic!) difference is the uvproj file generated by uVision4 and presumably the versions of C51, A51 and BL51."

Yes - after (at least) 5 years there most certainly will be different versions of C51, A51 and BL51!

The actual tools updates are most likely to be the cause, as uVision just calls the tools.

One thing where the uVision version might have an effect is in the default settings of options that aren't specifically controlled by your Project - especially options that didn't exist all that time ago!

"Unfortunately, I don't have access to a copy of uVision2"

That really does make things a whole lot harder - and emphasises the importance of maintaining the appropriate tools with old projects!

"are there things I should look at that may help isolate the problem?"

The Release Notes will tell you what's changed through the versions - but the hard thing is how to tell which change(s) might actually be affecting your application!

Debugging to find the point of failure is probably your best bet...

Have you also asked on the SiLabs forum? (don't forget to give links if you do)

You need to look for anything in the code that relies upon particular behaviour of the specific version - but quite how you do that is another matter!

Can you run the code through lint or similar?

I don't envy you this one!

I think I would actually try to reduce your project into a "hello world" that either prints something on a serial port or flashes a LED. When that works, you know that you build a binary that can be correctly downloaded and run. Then it should be possible to add real project code.

Whatever complexity your code has - if it is valid C code that the compiler can produce runnable code from - the tools should still be able to produce a binary that gets through the startup file, initializes the runtime library and enters the main loop as long as the project settings are reasonable.

Does your code contain anything that produces an externally visible stimuli when the program enters main()?

try compiling with optimization level 2

Thanks for the responses

try compiling with optimization level 2

Unfortunately this didn't work.

Does your code contain anything that produces an externally visible stimuli when the program enters main()?

At the moment no, but I'll modify it to try turning on a LED and see what happens. As you say, it looks like reducing the code down a bare-bones LED Blinker and then rebuilding from there is what I'm going to need to do.

"Unfortunately this didn't work"

Do you mean the code doesn't run (correctly), or the build fails?

What about level 0?

Do you mean the code doesn't run (correctly), or the build fails?

What about level 0?

At level 2 the code builds but doesn't run. At level 1, the code fails to build because the generated machine code is too large to fit into the available memory.

At level 2 the code builds but doesn't run. At level 1, the code fails to build because the generated machine code is too large to fit into the available memory.
level 2 basically is no 'optimization' just local variable overlaying. Thus the level 1 'problem' was anticipted by me.

Erik

so why did switching to Level 1 increase his code size...?

so why did switching to Level 1 increase his code size...?
I guess it was not code, but data.

Erik

Any warnings from compiler/assembler/linker?.
the typical "upgrade problem" is due to some misconstruct previously allowed/interpreted which now is misinterpreted with a warning (nothing wrong with misinterpreting a misconstruct).

If you use the IDE DO scroll through the full "build report" do not rely on the last line which is just linker warnings/errors.

this is now cross-posted at the SILabs forum, I wonder why someone would suggest posting a Keil problem there

Erik

Any warnings from compiler/assembler/linker?.

Nothing that is relevant. There are 2 warnings but they relate to a function that definitely hasn't been called before the program fails.

I made some progress today and it seems to be related to a bootloader. The build is a two stage process. Firstly one set of code (the bootloader) is compiled and linked and the resultant hex file is converted to an assembler file which is then fed as source code for the final full build.
I was able to get my hands on the assembler file generated by the original toolset and when this is fed in to the second stage, the resulting binary seems to work fine.

Now I just need to figure out what causes the problem in building the first stage.

Thanks everyone for your helpful advice.

I suggested it: because an SiLabs chip is involved - so there could be someone there who's seem a similar effect, but doesn't read this forum.

Or there could be some specific "interaction" with the particular chip...

However, I did say that links should be given between the cross-posts...

However, I did say that links should be given between the cross-posts...

Well I did include a link to this thread when I reposted the question on the Silabs forum. I guess I should have also put a link to that thread here.

Here goes...
www.cygnal.org/.../000317.html

Does the boot loader and application share any data?

Does the boot loader sends some information to the application?

Does the boot loader allocates some memory that should be reserved by the application?

Is the boot loader using a standard startup file?

Does it turn on any interrupts before starting the application?

Does the boot loader and application share any data?
It appears not

Does the boot loader sends some information to the application?
No

Does the boot loader allocates some memory that should be reserved by the application?
Not as far as I can tell

Is the boot loader using a standard startup file?
It's the same startup file as the main application except for a different address to jump to after initialisation. Whether it's standard or not, I'm not sure.

Does it turn on any interrupts before starting the application?
No

I think my problem may be in the actual generation of the bootloader assembly. The build process is neither automatic nor well-documented, so I may have made a mistake in how I created it. That's where I'm going to focus my efforts now. Thanks for all the helpful advice and pointers