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.

Calling functions by address.

Other Parts Discussed in Thread: CC430F5137

Hi there,

I've linked #pragma LOCATION(main_app, 0xC000). 0xC000 start of app code.

In the boot function I'm calling this main_app as 

uint16_t addr = 0xC000;
((void (*)())addr)();

Well it goes and executes. But If  tune that two line to,

uint16_t addr = 0x8000;
((void (*)())addr)();

Also my sys. works fine.

 

Basically I want to call specific/good firmware after reset in dual firmware image  based firmware update.

Please help in understanding/solving this issue!.

 

Device: CC430F5137

IDE: CCSv6

 

 

-Thanks,

Rahul

  • You can remap the interrupt table and change the default startup file

  • Thank you Mich!.

    I my reset vector will point to boot code. In boot code I'll not be using any interrupts.  Its going to boot code. but calling app code is not happening properly. 

    As I said if call 0x8000 addrs also goes to same function. and  for 0xc000 addrs also go to same function!!!.

    I tried linking main_app like this: .text:main_app : {} > 0xC000. but same issue.

    P.S:    FLASH                   : origin = 0xC000, length = 0x3C00

               And I've linked main_app to 0xc000 so that I can have definitive memory address that I can call from boot code.

              

    I'm I missing something?

    Thanks,

    Rahul

  • Rahul SU said:
    I've linked #pragma LOCATION(main_app, 0xC000). 0xC000 start of app code.
     [...]
    Well it goes and executes. But If  tune that two line to,
    uint16_t addr = 0x8000;
    ((void (*)())addr)();
    Also my sys. works fine.

    If you placed your main function to 0xC000, likely the area from beginning fo flash to 0xxc000 is empty. If the CPU now jumps to 0x8000, it will find 0xffff, 0xffff as instruction there, which is AND @R15+,0xffff(R15) (and basically does nothing). So it continues executing this instruction through all the "empty" flash until it finally reaches 0xc000 where your start code is, and then continues as if it were jumped to 0xc000 right from the start. It only took 16000 clock cycles (16ms) more than necessary.

**Attention** This is a public forum