• State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 22 subscribers
  • Views 7733 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

BL51: '*** WARNING L1: UNRESOLVED EXTERNAL SYMBOL'

Gary Lynch

I am designing an application to run on the Si Labs
C8051F046 MCU with uVision 3. Yesterday I created a new
project, but forgot to include one of the source modules.
This produced a line during the link in the Output Window:

  *** WARNING L1: UNRESOLVED EXTERNAL SYMBOL

I missed it, as this program generates many similar warnings:
  *** WARNING L16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS

(in that tiny, little output window) which I must ignore.
Because L1 is only a warning; BL51 completed the build and
gave me a load module, which I attempted to debug. (It came
fairly close to working). I wasted an hour tracking the
cause back to this source.

I can't think of any scenario where I would want the build
to continue with missing source modules, yet I can find no
tool that would allow me to make L1 an error instead of a
warning. As best I can tell, this topic has never appeared
in the knowledge base or on this forum.

Does anybody have a differing opinion? A workaround?

Advance thanks for any insight.
============================================================
Gary Lynch            |     To send mail, change no$pam in
lynchg@no$pam.com     |     my domain name to stacoenergy

Parents
  • 0 in reply to Andy Neil

    On 5/10/06 8:16:52; A.W. Neil wrote:
    >
    > Why must you ignore them?
    >
    > Have you not just proved the folly of ignoring warnings?!
    >
    Several reasons:

    • This board is one of 5 using the same MCU. I frequently
      borrow a driver from one board to use on the other. The
      old driver may contain multiple functions which I have not
      yet implemented on the new hardware, and aren't called by
      my test suite.
    • I have developed a suite of functions I find extremely
      useful in debugging, but are not a part of the final
      application, which I keep in a separate source file. I
      don't call all of them when I need help debugging.
    • I implement a state machine with a table of function
      pointers. This interacts with an idiosyncracy of BL51
      to make it jump to the (erroneous) conclusion my
      functions are calling themselves recursively. Keil has
      an app note detailing a workaround for this, but it is
      such a hassle to get the syntax right, I frequently let
      BL51 whine.

    So although I don't expect to have any warnings in my final
    release, the debug process is not that simple.

    I also find it extremely difficult to review the list of
    warnings (accurately) in that little slit that passes for an
    output window. If anyone has found a way to pass the build
    output to a text file I could open with my text editor, that
    might make it worth the trouble.
    ============================================================
Gary Lynch            |     To send mail, change no$pam in
lynchg@no$pam.com     |     my domain name to stacoenergy

Reply
  • 0 in reply to Andy Neil

    On 5/10/06 8:16:52; A.W. Neil wrote:
    >
    > Why must you ignore them?
    >
    > Have you not just proved the folly of ignoring warnings?!
    >
    Several reasons:

    • This board is one of 5 using the same MCU. I frequently
      borrow a driver from one board to use on the other. The
      old driver may contain multiple functions which I have not
      yet implemented on the new hardware, and aren't called by
      my test suite.
    • I have developed a suite of functions I find extremely
      useful in debugging, but are not a part of the final
      application, which I keep in a separate source file. I
      don't call all of them when I need help debugging.
    • I implement a state machine with a table of function
      pointers. This interacts with an idiosyncracy of BL51
      to make it jump to the (erroneous) conclusion my
      functions are calling themselves recursively. Keil has
      an app note detailing a workaround for this, but it is
      such a hassle to get the syntax right, I frequently let
      BL51 whine.

    So although I don't expect to have any warnings in my final
    release, the debug process is not that simple.

    I also find it extremely difficult to review the list of
    warnings (accurately) in that little slit that passes for an
    output window. If anyone has found a way to pass the build
    output to a text file I could open with my text editor, that
    might make it worth the trouble.
    ============================================================
Gary Lynch            |     To send mail, change no$pam in
lynchg@no$pam.com     |     my domain name to stacoenergy

Children
  • 0 in reply to Gary Lynch

    This interacts with an idiosyncracy of BL51
    to make it jump to the (erroneous) conclusion my
    functions are calling themselves recursively.

    The linker is not making any erroneus conclusions. It tries to construct a calling tree for your functions, but fails as soon as function pointers come into play since the Linker has absolutely no idea what values the function pointers will have during run-time. It therefore makes the right decision by not considering those functions for overlaying.

    Don't blame the linker for perfectly expected behavior.

  • 0 in reply to Gary Lynch

    I also find it extremely difficult to review the list of
    warnings (accurately) in that little slit that passes for an
    output window.

    Have you tried resizing the output window ? Works fine for me ...

  • 0 in reply to Christoph Franck

    "Have you tried resizing the output window ? Works fine for me ... "

    All the Linker messages are saved in the Linker Listing file (the "Map" file).

    Just as the compiler messages are in the compiler listing files.

    I think the build window content is also saved to a file - maybe .plg ?

    You can also copy-&-paste from the output window.

    With Windows XP, you could probably even get it to read the warnings to you out loud...

  • 0 in reply to Andy Neil

    With Windows XP, you could probably even get it to read the warnings to you out loud...

    Doing this at your workplace without headphones would amount to severe Wally-esque behavior.

  • 0 in reply to Andy Neil

    I think the build window content is also saved to a file - maybe .plg ?

    Yep. In HTML, no less.