Hello,
I've inherited a project that previously used uVision2 to build code for a Silabs C8051F060 device. The hex file built with uVision2 runs fine on my hardware.
However, when I open the uv2 project file with uVision4 and build, the resulting hex file doesn't run on the hardware. There are no modifications to the code, the only difference is the uvproj file generated by uVision4 and presumably the versions of C51,A51 and BL51.
I'm trying to isolate the actual point of failure in a debugger but haven't had any success yet.
Unfortunately, I don't have access to a copy of uVision2, so I need to get the code working under uVision4.
Are there any compatibility issues between these two versions that I should be aware of, or are there things I should look at that may help isolate the problem?
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?
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.
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
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...
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
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. if that is the case, the whole thing is faulty you can only have ONE startup file. To have two you need the bootloader to overwrite itself and that is no good.
you can only have ONE startup file. To have two you need the bootloader to overwrite itself and that is no good.
Sorry my mistake. There are two startup files included in the project but the one used for the main application just jumps to the bootloader code and it isn't actually run.