"Flash from file" not working for release build

cancel
Showing results for 
Search instead for 
Did you mean: 

"Flash from file" not working for release build

Jump to solution
524 Views
Contributor II

Hi!

I am using Kinetis Design Studio v3.2.0 to develop for a Kinetis MK64FX512VDC12.

I am using a PEMicro Multilink Universal module to debug and I am not able to flash (Run --> Flash from file...) when the application file I built is in release configuration.

In that case, the running application is stopped on the target hardware but the application to flash is not starting.

When the application file is in debug configuration, the running application is stopped and the application to flash is started.

Here is the Console output I get (it is basically the same than the one I get in Debug configuration besides checksum values):

Connection from "127.0.0.1" via 127.0.0.1
Connection from "127.0.0.1" via 127.0.0.1
Searching for FreeRTOS Kernel Symbols...
  pxCurrentTCB not found. FreeRTOS analysis not enabled.
Copyright 2017 P&E Microcomputer Systems,Inc.
Command Line :C:\Freescale\KDS_v3\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_3.4.0.201802282250\win32\pegdbserver_console -device=NXP_K6x_K64FX512M12 -startserver -singlesession -serverport=7224 -gdbmiport=6224 -interface=USBMULTILINK -speed=5000 -por?

CMD>RE

Initializing.
Target has been RESET and is active.
CMD>CM C:\Freescale\KDS_v3\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_3.4.0.201802282250\win32\gdi\P&E\supportFiles_ARM\NXP\K6x\freescale_k64fx512m12_pflash_dflash_eeprom.arp

Initializing.
Initialized.

;version 1.04, 04/20/2017, Copyright 2017 P&E Microcomputer Systems, Inc. All rights reserved. www.pemicro.com [mk64_512k_x_pflash_dflash_eeprom]

;device freescale, k64fx512m12, pflash_dflash_eeprom

;begin_cs device=$00000000, length=$14004000, ram=$20000000

Loading programming algorithm ...

WARNING - Selected .ARP file has been modified. CRC16 = $5EE3
Done.
Programming sequency is : erase, blank check, program, and verify {default}
CMD>VC
Verifying object file CRC-16 to device ranges ...
   block 0000C080-0000C48F ...
Ok.
   block 0000C4A0-0004CC17 ...
Calculated CRC-16 does not match block. (File = $8203, Device = $5130)

CMD>EM

Erasing.
Module has been erased.
Reloading programming algorithm ...
done.
CMD>PM

Programming.
Processing Object File Data ...


.
Programmed.
CMD>VC
Verifying object file CRC-16 to device ranges ...
   block 0000C080-0000C48F ...
Ok.
   block 0000C4A0-0004CC17 ...
Ok.
   Checksum Verification Successful. (Cumulative CRC-16=$C5D1)

CMD>RE

Initializing.
Target has been RESET and is active.
Disconnected from "127.0.0.1" via 127.0.0.1
Disconnected from "127.0.0.1" via 127.0.0.1
Target Disconnected.

I see nothing in the "Problems" tab besides compilation warnings.

Any idea?

Thanks

Labels (1)
0 Kudos
1 Solution
101 Views
Contributor II

Well I think it is clearer now.

First, the original .elf file is too big. I don't know if everything in the .elf file is flashed onto the board but if it is then the original .elf file is too big for the platform.

Also, the bootloader does not seem to be included into the original release .elf file.

  1. The original application .elf file is 62 MB.
  2. We then pass it through "arm-none-eabi-objcopy -O binary original.elf output.bin", which brings the output.bin file to ~260 KB (!!).
  3. Then we insert stuff to the binary (CRC and bootloader).
  4. Generating an .elf file from the result (i.e. complete application) using "arm-none-eabi-objcopy.exe --input-target=binary --output-target=elf32-little result.bin result.elf" gives an .elf file that succeeds being flashed.

View solution in original post

0 Kudos
7 Replies
101 Views
NXP TechSupport
NXP TechSupport

Hello Rudy Vigneault ,

Does your project includes debug code  like printf()  to console ?

Hope it helps


Have a great day,
TIC

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

0 Kudos
101 Views
Contributor II

Hi Alice_Yang,

Yes it does. printf are output through serial connection console though - i.e. different connection than PEMicro Multilink.

Thanks

0 Kudos
101 Views
NXP TechSupport
NXP TechSupport

Hello Rudy,

What about other simple project ? For example a LED demo ?

If the problme only for this project, you can send it to me, I will check it on my side.

BR

Alice

0 Kudos
101 Views
Contributor II

Hi Alice_Yang‌,

I did not have time to test another project yet but I noticed something interesting, that might shine a light on what is or what is not the problem.

I am able to load the release binary that I generated when I transform it to an elf file using arm-none-eabi-objcopy.exe (as described here) and then using "Flash from file..." and selecting the elf file using the "Browse" button into the "C/C++ Application" section.

Thanks,

Rudy

0 Kudos
101 Views
NXP TechSupport
NXP TechSupport

Hi Rudy,

Your original file is .bin file ? KDS can't flash .bin file .

The kds also can produce the hex elf file by itself :

pastedImage_1.png

BR

Alice

0 Kudos
101 Views
Contributor II

Hi Alice,

The original file seems to be a .elf file. In "Flash from file...", when I select "Search Project...", I see .elf files (one for debug and one for release).

Using the debug one works and the release one does nothing.

I am still investigating this on my side but I even think that the .bin I was talking about previously is generated from the .elf!! Maybe there is a modification needed (done by our setup) on the .bin before it can be used to flash.

I will let you know although it might take some time since for now I have a workaround.

Thanks,

Rudy

0 Kudos
102 Views
Contributor II

Well I think it is clearer now.

First, the original .elf file is too big. I don't know if everything in the .elf file is flashed onto the board but if it is then the original .elf file is too big for the platform.

Also, the bootloader does not seem to be included into the original release .elf file.

  1. The original application .elf file is 62 MB.
  2. We then pass it through "arm-none-eabi-objcopy -O binary original.elf output.bin", which brings the output.bin file to ~260 KB (!!).
  3. Then we insert stuff to the binary (CRC and bootloader).
  4. Generating an .elf file from the result (i.e. complete application) using "arm-none-eabi-objcopy.exe --input-target=binary --output-target=elf32-little result.bin result.elf" gives an .elf file that succeeds being flashed.

View solution in original post

0 Kudos