Cosumized Bootloader Problem

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

Cosumized Bootloader Problem

1,152 Views
bouhady
Contributor II

I'm working with K64 and KDS .

since there is no USB Host Bootloader for this device I'm tring to implement my own Bootloader.

Based on a "BM USB Host" example for this device (USB Host Project with KSDK 1.3 and Processor Expert ) I created a tool which read and parse .hex file in order to program it automatically.

I edited the original linker file for the code to push adresses by 0x020000 so all the data should be writen in the rest of the memory.

After overcoming HEX Parsing, Flash Saving and USB integration here comes the last problem:
after flashing all the hex data to adresses 0x020000 and on I resetting the device and the default BL program supposed to do "Jump" to the 0x020000 section . Ive tried both options suggested in tje NXP examples:

1. direct call to void* :

2016-05-31_17-17-51.png

2. asmembly "blx" command:

2016-05-31_17-19-02.png

both options resetting the device right after the jump and the "Post" printf is not printed even (its directly go to "reset" sequence).

what did i do wrong? is there any special permision or special preperation i should to to the original source sotwere before compiling it or generating the Hex file?

3 Replies

810 Views
mjbcswitzerland
Specialist V

Hi

You can get USB Host Memory stick loader for the K64 and KDS at http://www.utasker.com/kinetis.html, which also allows USB MSD device as well if required (auto-detection).

This is the code it uses to jump to the application in case it may give you some ideas to solve your problem:

// Allow the jump to a foreign application as if it were a reset (load SP and PC)

//

extern void start_application(unsigned long app_link_location)

{

    #if defined KINETIS_KL || defined KINETIS_KE || defined KINETIS_KV   // {67} cortex-M0+ assembler code

        #if !defined _WINDOWS

    asm(" ldr r1, [r0,#0]");                                             // get the stack pointer value from the program's reset vector

    asm(" mov sp, r1");                                                  // copy the value to the stack pointer

    asm(" ldr r0, [r0,#4]");                                             // get the program counter value from the program's reset vector

    asm(" blx r0");                                                      // jump to the start address

        #endif

    #else                                                                // cortex-M3/M4 assembler code

        #if !defined _WINDOWS

    asm(" ldr sp, [r0,#0]");                                             // load the stack pointer value from the program's reset vector

    asm(" ldr pc, [r0,#4]");                                             // load the program counter value from the program's reset vector to cause operation to continue from there

        #endif

    #endif

}

extern void fnJumpToValidApplication(int iResetPeripherals)          // {25}
{        
if ((*(unsigned long *)fnGetFlashAdd((unsigned char *)_UTASKER_APP_START_) != 0xffffffff) && (*(unsigned long *)(fnGetFlashAdd((unsigned char *)_UTASKER_APP_START_) + 4) != 0xffffffff)) {
#if defined USB_INTERFACE && defined USB_MSD_DEVICE_LOADER       // {9}
    if (*(unsigned long *)fnGetFlashAdd((unsigned char *)UTASKER_APP_START) == 0xffffffff) {
        return;
    }
#endif
    if (iResetPeripherals != 0) {                                // if peripherals have been in use
        uDisable_Interrupt();                                    // ensure interrupts are disabled when jumping to the application
#if  (defined USB_INTERFACE && defined USB_MSD_HOST_LOADER && defined USB_HOST_SUPPORT)
        USB_HOST_POWER_OFF();                                    // {28} remove power to memory stick
#endif
        RESET_PERIPHERALS();                                     // {14} reset peripherals and disable interrupts ready for jumping to the application
    }
#if !defined _WINDOWS
    start_application(_UTASKER_APP_START_);                      // jump to the application
#endif
}

}

UTASKER_APP_START would be 0x20000 in your case.

Regards

Mark

810 Views
bouhady
Contributor II

thank you vary much!

I manage to perform the Jump command correct right now.

now I have new problems referring the copied code:

few problems and bugs was referring the HEX file parsing so part of the code was copied wrong and it was fixed now.

I believes that the code copied now correctly but still I have very acute problem:

I compare the original code sequence (both the asm and even the HEX itself between the original program (line by line debugging) and there is a specific line that on the original code act OK and nothing wrong is happened and on the BL version when I get this specific line the whole code is the memory seem to be shifted if one block (16 bytes) and the addresses is not correct anymore (then the code just got lost and reset..).

the original program codes (the specific line is #03 (OSC->CR..) :

MCG->SC = SYSTEM_MCG_SC_VALUE;       /* Set SC (fast clock internal reference divider) */

  MCG->C2 = (MCG->C2 & (uint8_t)(~(MCG_C2_FCFTRIM_MASK))) | (SYSTEM_MCG_C2_VALUE & (uint8_t)(~(MCG_C2_LP_MASK))); /* Set C2 (freq. range, ext. and int. reference selection etc. excluding trim bits; low power bit is set later) */

  OSC->CR = SYSTEM_OSC_CR_VALUE;       /* Set OSC_CR (OSCERCLK enable, oscillator capacitor load) */

MCG->C7 = SYSTEM_MCG_C7_VALUE;       /* Set C7 (OSC Clock Select) */

  #if (MCG_MODE == MCG_MODE_PEE)

the original disasmly :

pastedImage_4.png

the registers original state:

pastedImage_5.png

Now the BL dis-assembly lines (looks the same i think): the line that makes the whole problem is 0x6316a :

pastedImage_7.png

the registers before this line:

pastedImage_9.png

the memory before this line : the memory right after this line:
pastedImage_8.pngpastedImage_10.png

Can you understand what can be the reason for this behavior? I'm trying to debug this line by line and usually i found bug relate the HEX parser but now the code memory is looks the same so i have no idea where the bug is caused by.

0 Kudos
Reply

810 Views
mjbcswitzerland
Specialist V

Hi

This looks more like a problem with the application/start-up code that can't handle the case that a boot loader has already programmed the MCG/OSC.

Regards

Mark

0 Kudos
Reply