• State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 21 subscribers
  • Views 1207 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

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

How to map address for XDATA (F000-FDA1)

dingyg99 Mickle

Hi:

We are now using the Ti-CC1110(Originally Chipcon). This MCU have a enhanced 8051 core and an RF modem(433MHz) integrated.

Because some address are mapped out for the RF modem, the 8051 core has NONE regular XDATA address. It is not mapped in address (0X000-0XFFF), but in address (0XF000-0XFDA1). As a programmer for CC1110, we are forced to modify the default XDATA map, otherwise the stack allocation will failed definitely, i.e. functions use the XDATA stack(large mode) will failed.

Then where to modify the default XDATA map?

According to my experience, there maybe THREE ways can achieve this object:

(1) Modify the default STARTUP.A51 file

(2) Modify the Device Manager DataBase of CC1110

(3) Write a project specific linker control file

I can not make sure which way is correct. I have tried method 1 and 2. But no aid at all.

If you need more information please let me informed! Thanks & Best Regards!

Parents
  • 0 in reply to ImPer Westermark

    It's a breeze if we are talking about absolute mapping of memory-mapped hardware.

    Using absolute addresses for normal variables on the other hand - that is not a good route. It may be meaningful when sharing a common data structure between a boot loader and the application, but normal application variables should not be absolutely located.

    I locate my XDATA absolute to allow @Ri buffer transfers without page crossings.

    Had it been pure C I would probably agree with you, since the compiler can not possibly take advantage of "no page crossings" with the willy-nilly location of variables that charaterizes C.

    just try a simple (addr1, addr2, length) xdata to xdata copy function that can only work between two aligned buffers (<256 bytes long) using @Ri and compare to a "pure C" xdata to xdata copy function.

    Erik

Reply
  • 0 in reply to ImPer Westermark

    It's a breeze if we are talking about absolute mapping of memory-mapped hardware.

    Using absolute addresses for normal variables on the other hand - that is not a good route. It may be meaningful when sharing a common data structure between a boot loader and the application, but normal application variables should not be absolutely located.

    I locate my XDATA absolute to allow @Ri buffer transfers without page crossings.

    Had it been pure C I would probably agree with you, since the compiler can not possibly take advantage of "no page crossings" with the willy-nilly location of variables that charaterizes C.

    just try a simple (addr1, addr2, length) xdata to xdata copy function that can only work between two aligned buffers (<256 bytes long) using @Ri and compare to a "pure C" xdata to xdata copy function.

    Erik

Children
  • 0 in reply to erik malund

    Not so much different from the requirements of aligning data in high-speed loops on bigger processors.

    I would prefer a solution where I define all relevant data in a struct, and makes sure that the start of the struct has the relevant align. I would not like to have to compute the individual addresses of the members of the struct.