• State Not Answered
  • Locked Locked
  • Replies 17 replies
  • Subscribers 22 subscribers
  • Views 3520 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Code doesn't run when built with UVision4

Joseph Foran

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?

Parents
  • 0 in reply to Joseph Foran

    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

Reply
  • 0 in reply to Joseph Foran

    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

Children
  • 0 in reply to ²erik malund

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

  • 0 in reply to Andy Neil

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

    Erik

  • 0 in reply to ²erik malund

    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

  • 0 in reply to ²erik malund

    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.

  • 0 in reply to ²erik malund

    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...

  • 0 in reply to Andy Neil

    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

  • 0 in reply to Joseph Foran

    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?

  • 0 in reply to ImPer Westermark

    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

  • 0 in reply to Joseph Foran

    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.

    Erik

  • 0 in reply to ²erik malund

    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.