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

    (Ok, I hope I got the formatting correct this time)

    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.


    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

    (Ok, I hope I got the formatting correct this time)

    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.


    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
  • 0 in reply to Christoph Franck 

    tXSDevice_DeviceEntry xdata * deviceEntryPtr
    A lot of Linker Errors with different Datatypes and Unresolved Externals. I change my typedef from
    typedef struct _XSIMDEVICE {

  tXS_UINT8 numEvents;             /**< Event entry count for the device.*/
  tXS_UINT8 groupCount;                     /**< Group entry count for the device.*/

  tXSEvent_SourcePtr eventListPtr; /**< Event group pointer. */
  struct _XSIMDEVICEGROUPINFO groupList[0x10u]; /**< Pointer to list of group entries. */

} tXSDevice_DeviceEntry;
    to
    typedef xdata struct _XSIMDEVICE {

  tXS_UINT8 numEvents;             /**< Event entry count for the device.*/
  tXS_UINT8 groupCount;                     /**< Group entry count for the device.*/

  tXSEvent_SourcePtr eventListPtr; /**< Event group pointer. */
  struct _XSIMDEVICEGROUPINFO groupList[0x10u]; /**< Pointer to list of group entries. */

} tXSDevice_DeviceEntry;

    But do not work.

  • 0 in reply to Michael Maennel

    A lot of Linker Errors with different Datatypes and Unresolved Externals.

    I guess you will have to hunt down all declarations of the function and change them accordingly.

    However, this was just something I noted on the side.

    The cause for your problem is most likely related to the call tree. Read the application note and the chapter in the linker's documentation.

  • 0 in reply to Christoph Franck

    I disabled NOOVERLAY to get a call tree in my map-file.

    But the calling tree of the application is empty. Perhaps it's a problem with my startup-code and linker-script inside application-project.