• 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

    There seems to be two communities of users of the Keil '51 software:

    There is the "C is C" community that refuse to accept that the '51 is weak in certain respects which makes it advisable to avoid certain constructs. I guess that those also do not use the unique features of the '51 that makes it strong in other respects:
    I implement a state machine with a table of function pointers

    Then there is those that adapt to the realities:
    Personally, I'd have loved to have used my normal function-pointer table approach to FSMs, but found all the manual Linker tweaking far too risky - so I used switches instead.

    Erik

Reply
  • 0 in reply to Andy Neil

    There seems to be two communities of users of the Keil '51 software:

    There is the "C is C" community that refuse to accept that the '51 is weak in certain respects which makes it advisable to avoid certain constructs. I guess that those also do not use the unique features of the '51 that makes it strong in other respects:
    I implement a state machine with a table of function pointers

    Then there is those that adapt to the realities:
    Personally, I'd have loved to have used my normal function-pointer table approach to FSMs, but found all the manual Linker tweaking far too risky - so I used switches instead.

    Erik

Children
  • 0 in reply to erik malund

    I think it should be possible to use function pointers in C51 without having to manually tweak the Linker's call tree?

    On the other hand, I know that the switch approach works.

    Hence my choice!

  • 0 in reply to Andy Neil

    I think it should be possible to use function pointers in C51 without having to manually tweak the Linker's call tree?

    But you have nevertheless accepted reality :)

    Everyone has something they would like to see different, it may and may not be included in the next release. Do I have 'things', absolutely. Do I sit doen and whine about them? abaolutely not.

    Now, for a real BUG. I would send 47 e-mails every day till it was fixed.

    Erik