Using function pointers to jump to an address in memory?

Follow

Rhys Heffernan

• February 24, 2011 03:33

Hello,

 

First let me get some particulars out of the way.  I am using CrossStudio 2.0.9 for MSP430 for my project.  Currently I am using TIs EXP430FG4618 development board for some testing, I am using the MSP430FG4618 on the board (which may seem obvious, but there are actually two different MSP430s on that board).

I am working on implementing a bootloader into my system.  The unit is wireless so my plan is to have a bootloader the unit will go to once it starts up, and two sections for the code.  One of the code sections will be temporary storage for the new program, while the other section is running and receiving the new code.

I have never done one before and as such I am trying to break it down into small steps.  I have used the section placement file, and the #pragma codeseg command* to make a BOOT section in flash, starting at 0x4000 with a size of 0x0100, and CODE_A section starting at 0x4100 with a size of 0x0100.  So far the bootloader simply turns on an LED, so I can see that it has run, and then tries to jump to the CODE_A section, which toggles a second LED.  

At the end of the code in the BOOT section, I am trying to use function pointers to jump to the start address of the CODE_A section.  Currently both sections of code are defined in the one project, so I could simply call the function in the CODE_A section rather than try to jump to the address, however that would do me no good in the long run, since they will inevitably be separate.  If I set the pointer to be &CODE_A_main like this,

 

  func_ptr = (int(*)())&CODE_A_main;

  func_ptr = (int(*)())&CODE_A_main;

 

it works fine and jumps to the function at the start of the section (at address 0x4100), however if I set the pointer to 0x4100, like this,

  func_ptr = (int(*)())0x4100;

the MSP430 seems to do a reset and goes back to the start of the CrossStudio init code.  

Looking at the disassembly I can see that the code in address 0x4100 is the same using both methods.  When the first method is used, the disassembly shows that the jump command is going to address 0x4200, which is the start of the CrossStudio init code, and there are two instructions, that are not there when using the second method.  They are

   0x4200 0041     BR         SP

   0x4202 0000     BRA       PC 

 

If anyone has any ideas regarding what I could do to solve my problem, or point me in the right direction it would be much appreciated.

 

Thanks for your time,

Rhys Heffernan.

 

* which reminds me, in the "Linking and section placement" section of the help, there is a typo in the example of how to use the #pragma codeseg directive.  It says #pragma codeseq.

0

• 

  Paul Curtis

  • February 24, 2011 12:18

  Are you and Adam Koch using CrossWorks then?

  0

  Comment actions Permalink
• 

  Paul Curtis

  • February 24, 2011 12:26

  If you are using a large code memory model then code pointers are thunked, i.e. the 16-bit code pointer points to a 20-bit address indirected to the code.  To understand this, try executing a regular function pointer in low-level mode and see how the code works.

  0

  Comment actions Permalink
• 

  Rhys Heffernan

  • February 24, 2011 12:42

  Thanks for the response.  

  So if I tried this on one of the smaller msp430s it should work?  My actual device uses a msp430f248 which has only 48K of flash, the next time I get a chance I will have a try on there and see what happens.

  Thanks a lot for the help, I'm sure you have save me much heartache.

  Rhys Heffernan

  
  
  So if I tried this on one of the smaller msp430s it should work?  My actual device uses a msp430f248 which has only 48K of flash, the next time I get a chance I will have a try on there and see what happens.

  Rhys Heffernan

   

  0

  Comment actions Permalink
• 

  Paul Curtis

  • February 24, 2011 12:49

  It would probably work on the smaller variant, yes, as function pointers in small memory model are direct pointers.

  0

  Comment actions Permalink
• 

  Rhys Heffernan

  • February 24, 2011 12:58

  Thanks again.  Sorry for the strange post above with the message twice, my computer had a bit of a spaz and deleted my graphics drivers and set my resolution to 800*600 so I couldn't see that I was incorrect and I can't seem to be able to edit my message.

  Also I sent an email replying to your question about Adam Kosh, however I sent it to the norelpy email address (again the resolution meant I did not see the address until after I had sent it).  If you didn't get it let me know and an email address that you would like it sent to.

  0

  Comment actions Permalink
• 

  Bart Tormans

  • October 11, 2011 20:22

  So, if i get it correctly, a function pointer on a MSP430X device, actually takes up 6 bytes?

  2 for the 16bit pointer, which points to a 20(32)bit address, stored somewhere else, thus, inderectly pointing to the correct location?

  Where is the real addres stored? Same place as the thunked pointer (local, static, const) ?

  0

  Comment actions Permalink
• 

  Paul Curtis

  • October 11, 2011 21:06

  There are a finite number of entry points to functions, all known to the compiler.  When one of these functions is called, the compiler creates a single instance of a thunk that requires four bytes in code memory.  A function pointer is two bytes and indirects through the thunk.  Therefore, you require two bytes to store a function pointer and pass it around and four bytes (only) per function entry point (and only then if it is used by assigning it to a function pointer).

  0

  Comment actions Permalink
• 

  Bart Tormans

  • October 11, 2011 21:10

  Ok. That clears it up perfectly.

  Thanks

  0

  Comment actions Permalink

Please sign in to leave a comment.