It looks like the cyelftool.exe generates the .hex file, but I can't see in the documentation any description of that process.
Wow, looks like I stumped the experts.
You can implement bootloader-bootloadable architecture to meet the driver update requirement.
- As you pointed out, bootloader can contain the main firmware which uses functions in bootloadable image. Function pointers can be used to call functions from the other application flash area. However, you would need to know the function pointers and approximate API flash consumption while developing the main firmware.
- You can keep the design simple and straight forward by combining the driver part and the main firmware. This combined bootlodable image can be sent over communication protocol for bootloading. In this case bootloader will consist of bootloader component+communcation protocol+necessary services.
- You can also use dual-application bootloader option, which allows two bootloadable applications to reside in flash. You can either seperate out main firmare and driver as two images. Or use dual applications as two versions of combined main firmware+driver image. The later is useful for designs that require a guarantee that there is always a valid application that can be run.
PSoC Creator generates bootloader+bootloadable combined hex image and bootloadable code+data file (.cyacd format) as part of build process. Please use Bootloader Code Examples for PSoC® 3/PSoC 4/ PSoC 4BLE/PSoC 5LP to understand more details on bootloader architecture.
Thanks for your response! You helped with the ida to maybe use dual boatloader. I have done boat-loaders in the past to replace the whole firmware. Unfortunately, the drivers need to be loaded by the main firmware as needed and may possibly contain a combination of drivers. Combining the drivers and firmware into one image is not really feasible due to the use cases I am addressing.
Are you saying that I could use the dual image to load the main firmware and the other image would be the driver? How would I go about preparing the driver hex? That is actually the piece I am most confused by because I am not sure how the cyelftool.exe and rest of tool chain works. I was having a hard time finding detailed documentation on it.
To combine dual-application hex files, refer Combine Dual-application Bootloadable Hex Files for Production Programming– KBA224390
Please refer to sections: 8.1 Project Files, 7.2 Adding Bootloadable Applications, 8 Loading Your Projects into PSoC of https://www.cypress.com/documentation/application-notes/an73854-psoc-3-psoc-4-and-psoc-5lp-introduction-bootloaders for more detials on various files.
I really appreciate your response. You mention combining the applications? That seams to be opposite of what I am trying to do. Did I miss something? I really need to know how to locate an external set of code so that I can load it later without replacing the main firmware which needs to keep running. This is a dynamic load.
Could you please confirm what you meant by dynamic load? Is it bootloading over communication protocol or programming over SWD?
If it's bootloading; as elaborated in shared documents, bootloadable project creates .cyacd file which contains only the bootloadable project. Bootloadable hex file is different from normal project as it combines both bootloader and bootloadable. However, .cyacd contains code and data for bootloadable project only.