Kinetis Bootloader Version 2.0.0

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

Kinetis Bootloader Version 2.0.0

Jump to solution
3,665 Views
ken_sallings1
Contributor III


I am having trouble with the Kinetis Bootloader Version 2.0.0.

 

I have a TWR-K65F180M board.

I am using KDS 3.2.

 

I am using the USB HS with MSD.  I drag and drop a firmware.sb file created from the following command file:

// Define one input file that will be the first file listed

// on the command line. The file can be either an ELF file

// or an S-record file.

sources {

inputFile = extern(0);

}

// create a section

section (0) {

load inputFile; // load all sections

call inputFile; // jump to entry point

}

 

The STATUS file reads "Ready" before I copy the .sb file.

After I copy the .sb file STATUS reads "Transferring" forever.  Any ideas out there?

Labels (1)
Tags (1)
0 Kudos
1 Solution
2,877 Views
ken_sallings1
Contributor III

Jeremy,

Thank you for your support.  Everything is now working.  I had an error when loading the image via the elf file.  When I switched to a binary file and fixed the start address to 0x0000e000, everything worked.  Here is my final command file for anyone that is interested.

sources {

     inputFile = extern(0);

}

     // create a section

     section (0) {

     erase all;

     load inputFile > 0x0000e000;

     reset;

}

View solution in original post

0 Kudos
12 Replies
2,877 Views
ken_sallings1
Contributor III

Most everything is now working; my last problem is that when I start my application from the bootloader, I go into the HardFault exception handler.  I have spent all day trying to determine why.  I could really use some help.

0 Kudos
2,877 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Ken,

Thanks for your reply.

I'd like to know whether the hard fault interrupt arise when debug the application or not, and what's the kind of operation execute in the application demo?
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
2,878 Views
ken_sallings1
Contributor III

Jeremy,

Thank you for your support.  Everything is now working.  I had an error when loading the image via the elf file.  When I switched to a binary file and fixed the start address to 0x0000e000, everything worked.  Here is my final command file for anyone that is interested.

sources {

     inputFile = extern(0);

}

     // create a section

     section (0) {

     erase all;

     load inputFile > 0x0000e000;

     reset;

}

0 Kudos
2,877 Views
davenadler
Senior Contributor I

Ken, had the same problems. See this thread for some solutions:
https://community.nxp.com/message/843787

0 Kudos
2,877 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Ken,

Thanks for your reply.

According to your reply, the 0x~0xa000 range of flash area would be occupied by bootloader code.

Next, you should focus on another two modification, the first is linker file of the application demo and the second is the BD file, and I've also illustrated the modified BD file below.

sources {

        # BIN File path

        myBINFile = "xx.bin";

}

section (0) {

        #1. Erase the internal flash

        erase 0x0000a000..0x0010000;

        #2. Load BIN File to internal flash

        load myBINFile > 0xa000;

        #3. Reset target.

        reset;

  }

Hope it helps.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
2,877 Views
ken_sallings1
Contributor III

I can't load anything to address less than 0x0000e000.  When I run the bootloader INFO.txt has the following:

Kinetis Bootloader K2.0.0

System device ID: 0x650083ac

Flash size: 2097152 bytes

Flash range: 0x00000000-0x001fffff

Flash sector size: 4096 bytes

Flash blocks: 4

RAM size: 262144 bytes

RAM range: 0x1fff0000-0x2002ffff

Reserved region 0: 0x00000000-0x0000dfff

Reserved region 1: 0x1fff0000-0x1fff485f

Verify writes: yes

Check reserved regions: yes

Boot config present: no

Peripheral detection timeout: 0 ms

CPU clock: 120000000 Hz

However, I did find in bootloader_config.h that the value is 0x0000a000.  I changed that to 0x0000e000 and I am still having trouble.

0 Kudos
2,877 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Ken,

I was wondering if you can share the completely procedure of experiment, then I can replicate the issue on my site.

It can help me to figure out the root cause of the issue.

I'm looking forward to your reply.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
2,877 Views
ken_sallings1
Contributor III

I believe that I almost have this solved. 

At first, the bootloader was in a sync_wait call forever; it appears that the USB_HID interface code was causing this.  I am not 100% sure about this.  The sync_wait loop went away when I removed the USB_HID support from bootloader_config.h.  Now I discovered that my elftosb command file needed some work.  I am now using this.

// Define one input file that will be the first file listed

// on the command line. The file can be either an ELF file

// or an S-record file.

sources {

inputFile = extern(0);

}

// create a section

section (0) {

//erase 0x0000e000 .. 0x1ffeffff;

erase all;

load inputFile; // load all sections

call inputFile; // jump to entry point

}

I believe that it is now failing when my data section is getting loaded.  I am going to modify my command file to not load the data sections.

0 Kudos
2,877 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Ken,

Thanks for your reply.

In the ~\NXP_Kinetis_Bootloader_2_0_0\NXP_Kinetis_Bootloader_2_0_0\targets\MK65F18, the KBOOT v2.0 has provided two kinds of the bootloader demo, Flashloader and Tower_bootloader, which one do you choose?
Have a great day,
Ping

2016-07-22_10-49-54.jpg

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
2,877 Views
ken_sallings1
Contributor III

I am using tower_bootloader.

0 Kudos
2,877 Views
ken_sallings1
Contributor III

I have tried tracing this in the debugger, and the device is stuck in a sync_wait call.  Below is the snippet of code:

     // The first receive data request was initiated after enumeration.
     // After that we wait until we are ready to read data before
     // we request more. This mechanism prevents data loss      

     // by allowing the USB controller to hold off the host with NAKs

     // on the interrupt out pipe until we are ready.

     if (g_device_composite.hid_generic.hid_packet.isReceiveDataRequestRequired)        {

            // Initiate receive on interrupt out pipe.       

            USB_DeviceHidRecv(g_device_composite.hid_generic.hid_handle, USB_HID_GENERIC_ENDPOINT_OUT,

                              (uint8_t *)&g_device_composite.hid_generic.hid_packet.report.header,                                                            sizeof(g_device_composite.hid_generic.hid_packet.report));

     }

     g_device_composite.hid_generic.hid_packet.isReceiveDataRequestRequired = true;        // Wait until we have received a report.           sync_wait(&g_device_composite.hid_generic.hid_packet.receiveSync, kSyncWaitForever);

0 Kudos
2,877 Views
ken_sallings1
Contributor III

I have gotten further with this.

The transfer is failing to write to flash, because the target memory address is reserved.

0 Kudos