Related to AN4370 USB DFU Bootloader for Kinetis MCU

[dingo]

It's about the necessity to move  the vector table for user application from flash to RAM when using interrupts, I don't understand why ? I work with K60 , IAR , MQX3.7. I wrote my own experimental bootloader on serial port and the user application vector table was located also in flash at user application start. Both user application and bootloader use MQX and interrupts and all work fine.

[c0170]

Hello Tripac Stefan,

the question is if you used MQX interrupt dispatcher or intent was to use own interrupts out of the MQX scope?

If former (_int_install_isr), then an application does not have to copy interrupt vector to the RAM. If desired latter one (int_install_kernel_isr), vectors must be copied to RAM.

The macros used in MQX are well explained in MQX User Guide.

Regards,

MartinK

[dingo]

Hello Kojto,

I use in  my user application only the interrupts of the serial driver, SPI  driver,  timer driver without (_int_install_isr) or (int_install_kernel_isr) .

Thanks,

Stefan T.

[DavidS · Accepted solution]

Hi Stefan,

In general when having two independent applications (bootloader + MQX application), each has its own space and each should not have their own vector table.

The appnote is doing this.

The bootloader is the default application that runs at boot time and owns the flash vector table space.  It generally does not get updated and its flash space can be protected from potential erasing.  The bootloader can erase and program the MQX application space and should have method to determine if the MQX application is present and valid.

After bootloader does a erase and program of update MQX application and determines it is valid, the bootloader will jump to start the MQX application from running.  Prior to this it is important that any interrupts the bootloader was using are disabled and the system as close to a POR (Power On Reset) state as possible so that the MQX application can boot freely.

The MQX application will initialize the device, copy its vector table from Flash to SRAM, and then update the system to know that the vector table is in SRAM.  MQX uses the following to know where the vector table is located:

#define MQX_ROM_VECTORS                     0  //DES 0=RAM, 1=ROM vectors (default in small_ram_config.h)

The indepedence of the two applications is important so that is there is power failure, corruption of MQX application update, etc.. that the bootloader will always function from POR/Watchdog/etc..

Hope this helps.

Regards,

David

PS

Yes it is possible to have two applications share one vector table but it is not our recommended method.  This decision is ultimately left up to the developer.

[dingo]

Hi David,

Thank you for reply , You  are right, but my application didn't share the same vector table in ROM I have two vector tables in ROM one for the bootloader at address 0x00000000 and one at the start of user application, so when switching from bootloader to appplication a new MQX is initialized with vector table in ROM but at different address than the start of the ROM. When restart,  first start the bootloader,  it check if it's a valid user application in flash or the user want to update the application, if the user application is valid the bootloader switch to the vector table of this application.

Regards,

Strefan T.

[DavidS]

Hi Stefan,

Thanks for your explanation.  ColdFire only allowed a vector table in Flash or SRAM.  Kinetis allows for multiple locations in Flash or SRAM.  I've tried having bootloader vector table at 0x0 and a MQX application vector table at 0x10000.  Thanks again for pointing out that capability.

Has you question been answered?

If not please re-phase.

Regards,

David