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

Bootloader, Application, Structures and deep pointer

Michael Maennel Smart GmbH

Bootloader: C:0x0000 - C:0x7FFF
Manages CAN-Communication and in-field update.
Application C:0x8000 - C:0xEFFF
Applications is controlled with bootloader over CAN 2.0.

Compiled both seperatly and merge the Hex-file. Interrupts and function calls work.

At level of 8 successive funtions calls the acces to an struct in Applications XDATA mem is incorrect. The expected pointer is not given.

Any adwise?

Parents
  • 0 in reply to Michael Maennel

    <dEP Pointer is correct. At eSE is the error.

    Ah. So the pointer does get passed correctly, and becomes corrupted later on. That is a different can of worms entirely, and would point more towards a problem with the call tree, i.e. the pointer gets stored in a memory location and is later overwritten.


    pre>tXSDevice_DeviceEntry* deviceEntryPtr
    If this is always a pointer to a location in xdata memory, it is a waste to use a generic pointer.

    tXSDevice_DeviceEntry xdata * deviceEntryPtr

    This would be a memory-specific pointer to xdata memory, which takes up only two bytes instead of three.

Reply
  • 0 in reply to Michael Maennel

    <dEP Pointer is correct. At eSE is the error.

    Ah. So the pointer does get passed correctly, and becomes corrupted later on. That is a different can of worms entirely, and would point more towards a problem with the call tree, i.e. the pointer gets stored in a memory location and is later overwritten.


    pre>tXSDevice_DeviceEntry* deviceEntryPtr
    If this is always a pointer to a location in xdata memory, it is a waste to use a generic pointer.

    tXSDevice_DeviceEntry xdata * deviceEntryPtr

    This would be a memory-specific pointer to xdata memory, which takes up only two bytes instead of three.

Children
No data