• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 533 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.

runing code from sram

Peter K.
Prodigy 70 points

Other Parts Discussed in Thread: CC2540, CC2530, Z-STACK

Hi all,

We're working on 'firmware update ' task (cc2540) , this is briefly:

when the pc adapter (central device) gets update command from user's application (running on pc) ,the gadget (peripheral device) gets the firmware (bin file) which is transferred using ble rf  transceiver,  then will be stored in internal flash. I wrote a bootloader code which must be executed from sram because cpu cannot acces the flash while it is being written, so to allow program execution from sram, I mapped the available sram into the lower range of the bank area from 0x8000 through 0x9FFF (8kB ) and I set code memory space banks. Bootloader does the following tasks: erease flash then write new firmware (using dma) and reboot.

and next steps are:

the gadget will copy  bootloader to sram using dma->jump to sram->firmware and flash preparation to run ->reset->  load 'new' firmware

What any other steps are necessary to set cpu to begin run that code from sram?

How can I set the cpu  begin  to read program code from sram?

Thanks.

  • 0
    TI__Mastermind 19350 points

    You are not correct in your understanding that the only way to write to flash is by running from RAM. The 2nd way to be able to write to flash while running from flash is to use a DMA channel to trigger the flash write. An excellent example of how to use a DMA channel to do this is found in hal_flash.c

    Originally, I had code in hal_flash.c that ran from RAM to do the flash write, but it is just so onerous to support this - it takes a special placement of such code with the linker control file, and the correct setup of all of the registers in the 8051, AND, worst of all, the loss of that area of RAM, so I changed to use the method that you will see today - to trigger the flash write by a DMA channel.

    I strongly urge you to re-consider your design and just use the DMA channel to trigger the flash write, as it is done in hal_flash.c module. Otherwise, if you must use code that runs from RAM, it is completely explained how to do this in the CC2540 User's Guide and I cannot paraphrase the complex process for you here any better.

    Good Luck.

  • 0 in reply to Dirty Harry
    Prodigy 70 points

    Hi Harry,

    Thank you for your response. I didn't think that the only way to write to flash is by running from RAM. We can write  the packets of  'new' firmware into the flash while  update process is running . When the transfer is complete , the flash contains 2 bin images , the 'new' firmware and the original which is still executed, size: each of images approx. 120 kB.

    My main problem is to load the 'new' firmware after transfer is done. At this time the flash cannot be erased while cpu executes the 'old' firmware. That's why I wrote loader which can delete the 'old' firmware then reboot . I agree with you, it can be achieved  easier way instead of using sram.

    I know, loader can be executed from flash but I didn't find any description how to 'jump' cpu to read/load that program code instead of  firmware.

     How can I  instruct the cpu to set/change the source address ( flash) to read/load program code?

    Or how can I give the source address for the cpu to read/load program code?

    Thanks.

  • 0 in reply to Peter K.
    TI__Mastermind 19350 points

    Usually a boot loader is a separate build of code from the code that it will be loading into flash. As such, it shares no data or function calls with said code in either direction. The boot loader is built to occupy say the first flash page and intercept all ISR vectors. If the boot loader is "running", it does not forward the reset vectors; if the "Application" code is running, is does forward the reset vectors with a simple jump to the offset location. Thus, the Application code is built with the reset vectors offset, in this example, offset by 0x800.

    The next BLE stack release in Q1 2012 will have sample boot loaders. If you need to piece it together now, you can download the Z-Stack for CC2530, and SOC almost identiccal to your CC2540, and you can study how the boot loader works in those sample apps.