- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've been trying to set up a two-stage bootloader for an FX3 device using the example code "Fx3BootAppGcc", but for the life of me I can't figure out how I'm meant to compile or store the main application so that the bootloader can load it. So far, I have the following questions:
- Can multiple .img files be loaded onto the same EEPROM, or would they need to be consolidated into a single image?
- If multiple .img files cannot coexist on the same EEPROM, is it possible to output a compiled binary in a different file format that is able to be added in parallel to other files?
- Are there any changes I should make to the toolchain in order to generate applications capable of being loaded by a second-stage bootloader?
- Should I change the initialization of the application loaded by the bootloader? (i.e. not call CyFx3BootDeviceInit() if the bootloader already called it)
- Is FX3 capable of using position independent code?
- Can an application which uses the boot_fw API be loaded from a second-stage bootloader, or is a ThreadX-enabled application necessary?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
The second stage bootloader is compiled and linked with cyfx3.ld file under the boot_fw folder in the SDK.
Here we have defined the memory space where the firmware image file for the SSBL(Second Stage Bootloader) has to be placed.
The control center takes care of the addresses and the program entry of the application firmware image files in the control transfer
Hence, just make sure that the .ld file of the boot_fw is linked with the SSBL.
1. Yes, multiple .img files can be placed onto the same EEPROM, just make sure that the firmware image files are in two different pages.
2. There is no need to make any change in the toolchain.
4. Can you please explain what you mean by this question?
3 and 5. boot_fw APIs cannot be used in the application firmware, threadX enabled application is recommended.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
The second stage bootloader is compiled and linked with cyfx3.ld file under the boot_fw folder in the SDK.
Here we have defined the memory space where the firmware image file for the SSBL(Second Stage Bootloader) has to be placed.
The control center takes care of the addresses and the program entry of the application firmware image files in the control transfer
Hence, just make sure that the .ld file of the boot_fw is linked with the SSBL.
1. Yes, multiple .img files can be placed onto the same EEPROM, just make sure that the firmware image files are in two different pages.
2. There is no need to make any change in the toolchain.
4. Can you please explain what you mean by this question?
3 and 5. boot_fw APIs cannot be used in the application firmware, threadX enabled application is recommended.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4. Can you please explain what you mean by this question?
I am interested in dynamically loading objects at runtime, which usually requires the object to be compiled as PIC (in the optimization tab of the C/C++ Build settings). My specific hope is to be able to separately store individual thread binaries to allow the RTOS to load or unload them at runtime (as opposed to requiring a duplicate RTOS binary for every firmware image); I realize that this is asking a bit much of an embedded system, though, so I wanted to see if it's even possible before I start completely redesigning my firmware.
3 and 5. boot_fw APIs cannot be used in the application firmware, threadX enabled application is recommended.
Some of the applications I'm working with are very lightweight and don't really benefit from threaded execution, so I'm trying to find a way to exclude the RTOS if possible; is there no way to do this in an application loaded by a second-stage bootloader?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
1. I don't think it would be possible to dynamically link individual RTOS thread binaries to a firmware at runtime.
2. It is recommended to use RTOS and thus the application firmware for the application. Boot_fw library has a limitation on the USB capabilities and other peripherals and will not support USB compliance.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you, I think you just saved me from several weeks of tinkering with this system.