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

UDP Response problem

Michael McCarrick

Hello,

I have a device (K60) with code built using the Keil MDK-Pro and using the TCP_CM3.lib library. I am able receive every UDP packet sent from the PC to the K60. But every other response packet from the K60 is not received by the PC.

This error seems to be rather intermittent. If I build with the No Init options (in Target options) for both IRAM1 and IRAM2 the problem "sometimes" goes away.

Has anyone seen this issue before?

Any ideas?

Thanks,
Mike

Parents
  • 0 in reply to Michael McCarrick

    Your main() gets an additional leading underscore in the object file, so links as _main.
    But there is also an external symbol __main that is part of the runtime library startup code and that must be called first.

    The use of a leading _ when translating C symbols is to give the assembler world a protected namespace, i.e. the only way to create symbols without leading underscores.

    The C library on the other hand is the only one allowed to have C source symbols with a leading underscore (resulting in double leading underscores when linking) to make sure that the C library also gets a protected namespace for private symbols that should not clash with normal C code.

Reply
  • 0 in reply to Michael McCarrick

    Your main() gets an additional leading underscore in the object file, so links as _main.
    But there is also an external symbol __main that is part of the runtime library startup code and that must be called first.

    The use of a leading _ when translating C symbols is to give the assembler world a protected namespace, i.e. the only way to create symbols without leading underscores.

    The C library on the other hand is the only one allowed to have C source symbols with a leading underscore (resulting in double leading underscores when linking) to make sure that the C library also gets a protected namespace for private symbols that should not clash with normal C code.

Children
No data