• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 57 subscribers
  • Views 1979 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.

CC2530: CC2530 Bootloader Configuration

Sean Michel
Prodigy 40 points
Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK

I am working on creating a custom bootloader for a device that uses a CC2530 microcontroller, and modifying an existing firmware build to work with the bootloader. Eventually this will be the means to achieve OTA update capability.

 

I’ve based a fair amount of the code on examples from Z-Stack 3.0.1, but I’ve hit a roadblock with configurations and linker files. As my version of IAR (v7.51) is ancient I cannot open the example project to see how the compiler is configured for both the bootloader and main application. This is what I need help with; choosing the correct code model, data model, calling convention, location for constants, etc. for each part and setting up the linker files. Using the linker files from Z-Stack for OTA boot and main is not working.

 

At this point, a bootloader configured exactly like the existing application can do everything short of reprogramming the internal flash. The code works for doing so, but without everything stashed in the correct internal memory locations I don’t think the main application will program correctly.

 

Just as verification, I stripped down the bootloader to just start the clock and jump to main application (proof of concept type stuff). This seemed to work, though I think the interrupt vector mapping is a bit jury-rigged. I just included in my project (can’t remember if it was bootloader or main application) the interrupt_stubs.r51 file from Z-stack. Looking at the hex file showed the lowest addresses essentially remapping elsewhere. If there’s a better way to do this, please let me know.

 

Any help with this last major hurdle of configuring the two builds (bootloader and main app) to play well with each other, and anything about interrupt vectors, would be greatly appreciated. If you need more information, please ask and I will provide what I can.

 

Thanks,

Sean

  • 0
    Guru 735695 points
    To build examples in Z-Stack 3.0.1, I think you have to use IAR EW8051 10.10.1
  • 0
    Intellectual 675 points
    Hello Sean.

    You can choose your code mode according to your bootloader size. If it's lower than 32k than you can choose NEAR. By choosing NEAR your code will probably be smaller because the compiler will not implement the switching between banks.
    I have made my own bootloader also and my configurations are:
    Code:NEAR, Data_Model:Large, Calling:Xdata_Stack_Reentrant, 8 registers, constants from RAM.

    The interruption vector is probably your biggest problem. You can't change the address internally, so it will always point to address 0x03 to 0x8B.
    What you can do is to insert code into these address to redirect to your routine. You can also check your stack to discover your previews program counter address.
    I'm using interrupts in my bootloader code and in my application code. My application code has an offset of 0x5000, so when an interrupt occurs I am reading the stack to get the last program counter address. If the address is higher than 0x5000 I need to jump to the application interrupt routine. If it is lower than 0x5000 I jump to the bootloader interrupt routine.
  • 0
    TI__Expert 8950 points

    Hi Sean,

    If it helps, here is how we have our CC2530 BootLoader project and CC2530 SampleLight project setup in IAR:

    What other information did you need?

  • 0
    Prodigy 40 points

    Thank you all for your replies. I ended up opening the TI IAR example project file in a text editor and compared it my existing projects, using the comparison to figure out the correct settings. I ended up with the exact same configurations as JasonB posted. My bootloader is allowed the first two pages of memory (4kb) addresses 0x0000 - 0x0FFF.

    As for interrupt vectors, I don't need to use them in the bootloader. I think it is still a bit "hackey", but simply adding the interrupt_stubs.r51 (from the TI OTA example) to my bootloader project actually works. Based on my understanding of assembly, that file simply adds code to the interrupt vector that jumps to an offset memory location where the main application stored its vectors. In my case, at the beginning of the main app (address 0x1000).

    After that, all seems to work. I can successfully reprogram the internal memory, using a bootloader and an image stored in external flash. The app jumped to functions as expected.