Help using two-stage bootloader

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
NTaub
Level 1
Level 1
First like received First like given 5 replies posted

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:

  1. Can multiple .img files be loaded onto the same EEPROM, or would they need to be consolidated into a single image?
    1. 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?
  2. Are there any changes I should make to the toolchain in order to generate applications capable of being loaded by a second-stage bootloader?
  3. Should I change the initialization of the application loaded by the bootloader? (i.e. not call CyFx3BootDeviceInit() if the bootloader already called it)
  4. Is FX3 capable of using position independent code? 
  5. Can an application which uses the boot_fw API be loaded from a second-stage bootloader, or is a ThreadX-enabled application necessary?
0 Likes
1 Solution
AliAsgar
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 750 replies posted

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

View solution in original post

0 Likes
4 Replies
AliAsgar
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 750 replies posted

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

0 Likes
NTaub
Level 1
Level 1
First like received First like given 5 replies posted

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?

0 Likes
AliAsgar
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 750 replies posted

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

NTaub
Level 1
Level 1
First like received First like given 5 replies posted

Thank you, I think you just saved me from several weeks of tinkering with this system.

0 Likes