AnsweredAssumed Answered

Linker Problem: Implementing Boot-loader On Coldfire V1

Question asked by Doug Paulsen on Jun 11, 2014
Latest reply on Jun 13, 2014 by Doug Paulsen

I have been trying to implement Paul Zhang's Coldfire V1 bootloader (see: <http://read.pudn.com/downloads132/sourcecode/embed/561869/Implement%20UART%20Bootloader%20On%20CF%20V1.pdf>) and I am having the most bizarre problem trying to get CW 6.3 to include my Vector Redirection Table.  I hope someone can point out  the error in my ways.

 

Basically, Zhang's approach is straightforward.  His example is for the MCF51QE128.  My project is for a MCF51AC256, but the approach should be pretty much the same except for the memory boundaries.  Zhang sets up four memory segments:  1) the primary vector table is fixed at 0x0 for the MCF51s, 2) the Bootloader itself above that table beginning at 0x00000410, 3) the Vector Redirection Table on top of the bootloader code beginning at 0x00000c000, and finally 4) the application area beginning at 0x00001000 to the end of flash.

 

Preparing these segments involves modifying CW's LCF file as follows:


MEMORY

{

      userram (RWX)          :      ORIGIN = 0x00800000, LENGTH = 0x00002000

      BootLoad (RX)           :      ORIGIN = 0x00000410, LENGTH = 0x000007F0      #this is new...

      VectorReMap (RX)     :      ORIGIN = 0x00000C00, LENGTH = 0x00000400      #...as is this...

      code (RX)                 :       ORIGIN = 0x00001000, LENGTH = 0x0001F000      #... and finally the code start has been moved from 0x0000410 to allow space for Bootloader & VectorReMap

}

 

then adding tge following to the SECTIONS space:

 

     # define code sections

     .BootLoad           :      {}      >      BootLoad

     .VectorReMap     :      {}     >      VectorReMap

 

     # Code placement for boot-loader section

      .text_bootload :

      {

      BootLoad.c (.text_bootload)

      . = ALIGN (0x4);

      } >> BootLoad

 

     # Code placement for remapped vector section

      .text_vectormap :

      {

      VectorMap.c (.text_vectormap)

      . = ALIGN (0x4);

      } >> VectorReMap

 

I have added file VectorMap.c to my project, and it begins as Zhang demonstrates:

 

    #pragma CODE_SEG __FAR_SEG text_vectormap

 

     void StartupEntry(void)

     {

          asm (jmp _startup);

     }

 

Now, before I invest in filling out the other 119 vectors to be remapped, I thought I'd take a peak at my Project.abs.xMAP file.  I've got a segment .text_vectormap and it is fixed at 0x00000c00 as instructed. 

 

But what's this?  .text_vectormap is empty!?  Length of zero.  What happened to my function StartupEntry()?  It's nowhere to be found in the xMAP file.  I even loaded the project onto hardware and checked at address 0x00000c00.  It's plain 0xFFs, which is very much un-good.. 

 

It appears the linker is smart enough to know that StartupEntry() is never called and therefore the linker does not include it.  To verify this, I've made a extern declaration and call to StartupEntry() in main() (which I of course very much do NOT want to do), rebuild the project, and then checked my xMAP file.  StartupEntry() now is shown at 0x00000c00, as intended.

 

I have tried variations on a theme such as the following in VectorMap.c:

 

     #pragma define_section TEST ".text_vectormap" ".text_vectormap"

     _declspec(TEST)void StartupEntry(void)

     {...

 

but again, the linker chooses not to include my very important but, from the linker's perspective, unused/unreferenced code at 0x00000c00.

 

I've done bootloader in HCS08 machines.  There the technique used was to create a table such as the following:

 

     T_VECTORENTRY const VectorJmpTable[]@0x00000c00

     =

     {

          { 0xCC, _startup     },

          { 0xCC, UNASSIGNED_ISR },

          ....

 

This will actually work in my project.  VectorJmpTable[] will be fixed at 0x00000c00.  The problem comes in that 0xCC is a plain old jump instruction in the HCS08.  The MCF51 jump instruction is much more complex so that hard coding looks to be fraught with error opportunities.  This option to create a vector redirection table is definitely out.

 

So we're back to trying to fix asm( jmp <addr>) pseudo functions as our vector redirection table, except the linker decides they are not necessary and saves the code space for me (thanks, linker!).

 

Is there something obvious I'm missing?  Some pragma or other way to make the linker include code regardless?  I tried the "Disable Deadstripping" option, only to have all sorts of other errors show up before abandoning that.

 

I fear, although I haven't gotten there yet, I'm going to have similar problems trying to get the boot loader code in there.  But, I'm sure whatever solution forces the linker to include my table will do the same for the also uncalled boot loader.

 

Thanks for any comments/suggestions!

Outcomes