AN2295 Section specification for bootloader code

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

AN2295 Section specification for bootloader code

1,386 Views
rogerpease
Contributor III

I am using an MK10DX64VLH7 processor and trying to use the Developer's Serial Bootloader in AN2295.


We are using Processor Expert with GCC.

My main code is split into roughly three sections....

GeneratedCode/*.{h,c} <--- Stuff Processor expert generates

Sources/Bootloader/bootloader.c    <---- Stuff leveraged from Common_source of the AN2295 distribution

Sources/Bootloader/flash_kinetis.c

Sources/Bootloader/flash_kinetisRamFuncs.c

Sources/Bootloader/crc.c

Sources/Bootloader/rs232.c

Sources/*.{c,h}  <---- Application code I have written.

My understanding of the requirements is:

1) I need to use the AN2295 interrupt vectors (which are defined for CodeWarrior, ARMCC and IAR). I

presume I should just use whatever is used with CodeWarrior since I'm not using a Keil or IAR compiler. 

2) I need to keep the bootloader in the first 0x2000 bytes of the flash. The idea is that at powerup the Bootloader will run first and decide that if it needs to run bootloader code or my application code. If the bootloader needs to do an update it will update 0x2000-0xFFFF.

So my main question is in GCC what is the best way to guarantee that my Sources/Bootloader/* .text code appears in 0x0400-0x2000 and the rest of my code appears in 0x2000-0xFFFF?

I tried this:

MEMORY {

...

m_bootloader      (RX) : ORIGIN = 0x00000410, LENGTH = 0x00001BE0

...

}

  .bootloader :

  {

  *bootloader.o (.text);

    *flash_kinetis.o (.text);

    *flash_kinetisRamFunc.o (.text);

    *crc.o (.text);

    *rs232.o (.text);

  } > m_bootloader

Following embedded - Put gcc libs .data in specific section? - Stack Overflow ​ but that doesn't seem to have done the trick.

Do I need to put section attributes on all the Bootloader functions (or all my application and PE functions)? From what I've also read gcc doesn't support or recommend section pragmas.

Or is there a better way to do all of this i am not aware of? :smileyhappy:

Thanks,


Roger

Labels (1)
0 Kudos
4 Replies

750 Views
rogerpease
Contributor III

Hi Mark-

I had to put this project aside and am coming back to it now.

I'm still using an MK10DX64VLH7 and am trying to figure out the path to do field updates without using the serial port. I pulled KBOOT1.2.0 from the website and it still looks like it's not supported for K10 processors. Even if it were it looks like it's a little on the big side. Is that correct? If not, which CPU_ should I #define?

I also don't have access to the serial port so I can't use a ROM based bootloader. I do have an on-board connected I2C EEPROM. 

So my options (assuming I can't use KBoot):

1) Can I pull flash libraries from apps/flash_driver_api/src and try to hack something together myself which uses the I2C and EEPROM? Would those be the proper flash libraries?

2) Use uFlasher?

Anything else you can suggest?

Thanks,

Roger

0 Kudos

750 Views
mjbcswitzerland
Specialist V

Roger

KBOOT supports loading via I2C (there is a module that connects to the PC that is used - it is called "Bus-Pal" or something similar).

If you don't have UART but do have I2C you could try porting KBOOT to the K10 to use this option, although the person doing the SW update will need a PC and such an adapter, in which case there is probably not much advantage over just using a cheap debugger to do the same task (needs a PC and an adapter...).

What I did complete recently is an EzPort cloner that can be used with Kinetis K parts: EzPort Cloning

This has potential for cases where EzPort is accessible because it allows boards to clone each other - it would require one master board that is uploaded with new code (eg. using debugger or with UART access) and then it can be used to update further boards with. The advantage over Kboot I2C is then that no PC is needed from that point on.

I don't know exactly what is most suitable for your requirements.

Regards

Mark

0 Kudos

750 Views
mjbcswitzerland
Specialist V

Hello Roger

The AN2295 is a legacy loader and Freescale has move to the KBOOT serial loader, so you may have more luck with that: Kinetis Bootloader|Freescale

You can also get serial loaders for all Kinetis boards at  µTasker Kinetis support

which is documented in http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF

These are also Kboot compatible and include configurations for

Specifically for GCC, a typical example is attaced, athough it is in fact no different to any standalone application on any part. The boot loader must suppy the reset vector (0x00000000) and the Flash configuration (0x400..0x40f) plus its own code (0x410..0x1fff if you limit to 0x2000) but possibly also using any spare space between the reset vector and the flash configuration).

Regards

Mark

Kinetis: µTasker Kinetis support

K20: µTasker Kinetis TWR-K20D72M support  / µTasker Kinetis FRDM-K20D50M support  / µTasker Kinetis TWR-K20D50M support  / µTasker Teensy3.1 support

For the complete "out-of-the-box" Kinetis experience and faster time to market

750 Views
mjbcswitzerland
Specialist V

Roger

By the way, I have also implemented the AN2295 Developer's Bootloader in the uTasker project

AN2295 Developer's Bootloader and KBOOT

This means that it now builds with all IDEs for all Kinetis parts. However I didn't see any real advantage of this loader over the Kboot, apart from the fact that it uses a little less code space.

Regards

Mark

Kinetis: µTasker Kinetis support

K20: µTasker Kinetis TWR-K20D72M support  / µTasker Kinetis FRDM-K20D50M support  / µTasker Kinetis TWR-K20D50M support  / µTasker Teensy3.1 support

For the complete "out-of-the-box" Kinetis experience and faster time to market

0 Kudos