Hello All,
First of all thanks for the support and responses you guys are giving, its really appreciable :smileyhappy: .
And now jumping to the queries.
I am working with MKL25Z64VLK4 and KBOOT.
and i have few queries related to the space taken from flash of the controller by KBOOT's final binary and they are as below.
1) Does KBOOT share the memory from controller's flash or it uses any other way ?
If the above is true then ,
2) How much memory it will occupy from controller's flash after compiling and flashing it into controller's flash as it is ( with out removing DEBUG as well as other peripheral's support ) if we go with the .srec format. ?
3) How would i be able to minimize the final space taken by the KBOOT after compiling it, if i would only be needing I2C peripheral's support and also i would not be needing DEBUG functionality ?
I saw the KBOOT 's reference guide and followed the suggested steps from chapter number 10- "Creating a custom flash-resident boot-loader" but though even i m not sure that the memory occupation has been reduced.
4) Is there any way to see the actual used memory from Flash of the controller after flashing the KBOOT's binary into controller i.e any utility or any document. ?
5) Will KBOOT remain in the flash memory after loading the user application if i use KBOOT to load the user application ?
Any help on these above topics will be great appreciable.
Thanks & Reagrds,
Rutvij.
Solved! Go to Solution.
Hello Rutvij Trivedi,
The community is glad to help :smileyhappy:
Responding to your questions:
1) The KL25 does not have a dedicated ROM memory, so yes, the bootloader takes part of the MCU's flash memory.
2) I made the test building the bootloader projects with IAR and KDS. These were my results:
IAR: 22,928 bytes
KDS: 22,716 bytes
So the flash used with default features is almost 23 KB.
3) As you mention, the file bootloader_config.h file can be used to customize the project according to your requirements. After reducing the project to only using I2C, these were my results:
IAR: 13,068 bytes
KDS: 12,796 bytes
So approximately 13 KB.
4) Easiest way is to check the size after build process.
-> In IAR you can see the size at the end of the file <project>.map:
-> In KDS refer to this tutorial (the part about Eclipse with GNU ARM Eclipse plugins): GNU Additional Tools: Create Flash Image, Print Size and Extended Listing Options | MCU on Eclipse
Then you will have the size printed in the console output:
5) Yes, for KL25 you use the KBOOT flash resident bootloader which stays in Flash and it is available for application upgrades.
Regards!,
Jorge Gonzalez
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hello Rutvij Trivedi,
The community is glad to help :smileyhappy:
Responding to your questions:
1) The KL25 does not have a dedicated ROM memory, so yes, the bootloader takes part of the MCU's flash memory.
2) I made the test building the bootloader projects with IAR and KDS. These were my results:
IAR: 22,928 bytes
KDS: 22,716 bytes
So the flash used with default features is almost 23 KB.
3) As you mention, the file bootloader_config.h file can be used to customize the project according to your requirements. After reducing the project to only using I2C, these were my results:
IAR: 13,068 bytes
KDS: 12,796 bytes
So approximately 13 KB.
4) Easiest way is to check the size after build process.
-> In IAR you can see the size at the end of the file <project>.map:
-> In KDS refer to this tutorial (the part about Eclipse with GNU ARM Eclipse plugins): GNU Additional Tools: Create Flash Image, Print Size and Extended Listing Options | MCU on Eclipse
Then you will have the size printed in the console output:
5) Yes, for KL25 you use the KBOOT flash resident bootloader which stays in Flash and it is available for application upgrades.
Regards!,
Jorge Gonzalez
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Jorge Gonzalez,
Thank you very much for your support and valuable response its very appreciable
:smileyhappy:.
Hi Jorge Gonzalez,
Can you help me here ?
My query is if i am going to generate the binary developed from c++ source would it anyway affect the KBOOT i am asking this because if i generate the binary using c++ source and tries to dump it into frdm-kl25z using "KinetisUpdater.exe" utility it does not work but if generate the binary using C source (same RGB LED code.) and if i use the same utility to dump the binary it works just fine. Here I observed the major difference into binaries size even c binary's size is 3KB and C++ binary's size is 11KB.
Now my questions related to queries are .
1) Is there anything i am missing here or really the language matters here?
2) Also now if the languages affecting in this scenario then is there any way to make c++ user application to work with KBOOT?
Please let me know if you need more information from my side.
Thanks & Regards,
Rutvij.
Hello Rutvij:
The bootloader will load any application's binary disregarding of the language. The issue must be in your application itself.
The first thing to do would be to test the application without the bootloader present, placing the application at the start of flash as normal.
Regards!
Jorge Gonzalez