• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 54 subscribers
  • Views 1258 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1110 questions

mj3419
Intellectual 270 points

Hi,
I'm a newbie currently programming my first firmware ever on the TI chipcon CC1110F32 using KEIL uVision3 compiler.

I need to write a firmware update routine so I have some questions about the way things work:
If you have answers to any of these questions I will be grateful.

1)Does the compiler I mentioned build RELATIVE code so that if I'll make it run from one base location or another it will work properly?
2)How come that the .HEX file that is created by the compiler is larger than the sum of sizes of data,xdata and code sizes mentioned by the compiler?
3)How come that when I do a "Read flash into hex file" using TI SmartRF Flash programmer I get a 90KB hex file which is larger than the 32+4 KB the chip has?
4)How do I create an even byte alignment to a function with the compiler mentioned?
5)When I burn the hex file to the chip how do I know from what base address the code starts to run from?
6) Is the code burnt to the flash fragmented or in one chunck?

7) When I write/erase to flash memory from the program FROM FLASH using the DMA what happens to the pages my program is written on,how does it continue working if I erase it(strange question)?

thanks

  • 0
    TI__Expert 3370 points

    Hi mj,

    1) I think µVision3 is only the version of the IDE from Keil. Whether this is possible I think depends on your compiler/linker. I know there are e.g. two different C compilers: C51 and CX51 with slightly different features (and different price). Then there's two different linkers as well: BL51 and LX51. I am not fully up to date on the feature set of each of these. I suggest that you contact Keil support team.

    2) The HEX file format contains more than just the image data. It stores meta data such as address and checksum etc. Check here for more details about the HEX file format. This explains why the file gets bigger. You can try to open the .hex file in a text editor to see for yourself.

    3) Same explanation as for 2. When reading out flash into hex file, the 4kB RAM will not be read, but the entire FLASH (all pages which may includes unused memory consisting of only 0xFF bytes). I am not fully aware why this constitutes 90 kB (about 200 % overhead), though.

    4) I don't know this compiler well enough (which is why I can't answer 1 either). I guess you want to know this in order to do a proper byte alignment for the function that triggers flash writing with DMA. I know that with IAR Embedded Workbench for 8051 the only way to do this alignment properly is with assembler. Maybe you will have to use assembler with Keil too. If it is possible with the Keil C compiler, I guess you would have to use some #pragma of some sort (try to see it's user manual).

    5) When you program the FLASH the code will be put as mapped by the linker. You should be able to get an output file from your linker showing you which areas the different functions are located.

    Normally the linker will place a LJMP instruction at the reset vector address (0x0000) for CC1110. This is where the CPU starts to execute code from upon a reset (e.g. a power-on-reset). The LJMP instruction normally leads to a routine often part of what's called the C start-up code, if you're using C. This start-up code will e.g. clear all uninitialized non-local or static variables in RAM (from what's also known as the .bss section), and initialize other variables by copying contents from FLASH to RAM. Then it will jump to the main() function of your program. Where all these routines/functions are located in FLASH is up the linker to decide.

    6) With the TI SmartRF Flash Programmer it will write 1 FLASH page at a time (the CC11110F32 has 32 pages of 1024 B FLASH), by erasing it and writing the contents set by the hex. If a FLASH page (e.g. the last one) has no records in the HEX file, it will not be erased. This means that a total chip erase is not performed, only for the relevant pages. (Note that if the HEX file contains records of 0xFF bytes on an entire page, the page will be erased (to 0xFF) and 0xFF will be written to it). It is possible that a HEX file may contain code that only affects e.g. page 1, 4, 5 and 6, but this is dependent on your linker.

    7) When you use the DMA to do a FLASH erase+write from code running from FLASH, the CPU will stall and wait until the flash controller and DMA transfer is completed. The CPU can not fetch the next instruction from FLASH since the FLASH controller is busy. See section 12.3.2.1. in the CC1110 data sheet for further details. However, when the erase+write is completed the CPU will continue to fetch the next instruction from the following address where it stalled. If you erased this page and did not write any sensible code to it, e.g. if it was filled with 0xFF, the CPU would start to execute these instructions, and all 0xFF bytes would get parsed as "MOV R7, A" instructions, until the end of the flash page. Most likely your program would misbehave as it re-enters a random place in code when it reaches the following flash page. So if you plan to write to the same page as the CPU is currently running from you need to be extra careful.

    I hope this answered at least some of your questions.

  • 0 in reply to esy
    Intellectual 270 points

     Thank you very much ( :