I have questions about the Flash Loader Add-on provided in the galllery.
When i use the blocking Bootloader/Downloader combination then the
maximal size for the user application is approximately :
(Flash size of the chip - bootloader section) / 2
Because the Downloader need's space in internal Flash to store the
transfered app Image, which the Bootlaoder after the next reset
then can store in the desired destination and start it.
If i want to use the nearly the whole Flash size of the chip for my
application (with some reserved space for bugfixing/changes of course)
i need to use a external memory device like qspi chip / SD card etc. with
the nonblocking Bootloader/Downloader combination.
Am i right with my assumption or have i overlooked something ?
We are already using an SD-card in our application but this is holding
app specific data like language- and json-files and is FAT32 formatted.
Is it possible to change the nonblocking Bootloader/Downloader combi
so that it is usable with a FAT formatted SD card ?
Text of the Application note:
"The application data is stored directly onto the SD card and does
NOT use a file system. A developer could store images anywhere on an SD card but the logical place to begin
storing images is at address location 0x0."
In reply to Renesas Karol:
Thank you for your quick answer.
Now it's going a little further. I make the changes and add sf_firmware_Image_internal instance to my
test_blinky project. Now I'm able to run the python script and your demo application is working.
But after successfully programming my test_blinky it makes a reset to start the app and then in the
R_BSP_WarmStart Routine the call g_sf_bootloader_mcu.p_api->appStart(g_sf_bootloader_mcu.p_ctrl)
returns status 713 wich means:
#define SSP_ERR_NO_FLASH_IMAGES ((ssp_err_t)713) ///< No images found in internal mcu flash
and so my app doesn't get started.
This is my sf_firmware_Image_internal setting:
I don't know if it's needed to set the start address and the size of the flash in this instance.
Any suggestions ?
In reply to HN66:
Now it work's.
In addition to your hint it's also necessary to set the Image Identifier field to a value not 0.
Thank's a lot.
I'm trying to customize your bootloader demo for our board now.
Switching from USB to SD Card and all worked as expected.
But when i change the procedure a little i run in a problem.
I just wan't to start the app in the bootloader directly without an additional reset
as in your demo:
status = g_sf_firmware.p_api->close(g_sf_firmware.p_ctrl);
if (SSP_SUCCESS != status)
if ( SSP_SUCCESS == status
|| SSP_ERR_IMAGE_ALREADY_EXISTS == status)
status = g_sf_bootloader_mcu.p_api->open(g_sf_bootloader_mcu.p_ctrl, g_sf_bootloader_mcu.p_cfg);
if (SSP_SUCCESS == status)
status = g_sf_bootloader_mcu.p_api->appStart(g_sf_bootloader_mcu.p_ctrl);
if (SSP_SUCCESS != status)
/* Notify the bootloader that appStart failed */
/* Notify the bootloader that open failed */
But when i do so the App Start fails. When i debug the appStart call
the function pointer has the right address 0x40004 as it should be, but the
app crashes. When i alternatively go trough the reset and call the App Start in
R_BSP_WarmStart like in your demo all works fine, the address in the function pointer is
also 0x40004. Is there a deeper meaning why your demo choose the way
with reset and App Start in R_BSP_WarmStart after flashing ?
The other bootloader demos also do the App Start in main of the Programm.
I don't want to use the way with the additional reset sequence, because it's
easier when the bootloader itself looks for an image, and after flashing he calls
the app directly.
Do you have an explanation for this issue ?
I am attempting to use the example project provided by you in this thread for the flashloader and reading a firmware update via USB mass storage.
I was able to import, setup and compile the example project using SSP 1.3.3 successfully (e2studio version 5.4.0.023).
When I build the project and attempt to generate a .bch file to use, I get the following error using the python script:
Did I miss a parameter or a step?
In reply to JasonP:
You provided that an image header is located at 0x40800, but the script cannot find it there. Is .sf_firmware_image_file_header section in your linker script located at 0x40000 + 0x800? Does the flash area for your application start at 0x40000 and you've got:
/* Flash Loader App Header at 0x800. This offset is fixed in sf_firmware_image.h and in XML */. = __ROM_Start + 0x800;KEEP(*(.sf_firmware_image_file_header*))
/* Flash Loader App Header at 0x800. This offset is fixed in sf_firmware_image.h and in XML */
. = __ROM_Start + 0x800;
in the linker script?
In reply to adboc:
Thanks for you reply adboc.
I checked everything and noticed that the 0x40800 was incorrect, and changed it to 0x800. I now get the following error when converting the srec to bch file:
In the synergy configuration, I do not see any property that allows me to set the "valid mask" value.
Valid mask is stored in an image header. You provided the executable address at 0x40000 and the image header at 0x800 - I wonder if these are right values.
Could you show a linker script used for builiding the image? Has the image a valid image header? If the application includes an instance of sf_firmware_image module, it should be automatically generated in synergy_gen/common_data.c:
If not, you should provide at least a minimal header:
I was able to get the bch file to convert successfully, but I had to do something different, as illustrated below.
I added an additional g_sf_firmware_image_internal to the HAL/Common Stacks. Was this the correct thing to do?
I am now able to run the application, and load the bch file from the flash drive, but the firmware still does not update.
The application runs, reads data from the USB and then fails in the g_sf_firmware.p_api->blockWrite() function.
I also removed the additional g_sf_firmware_image_internal in the HAL/Common modules and implemented the minimal header that you mentioned and the same SSP_INVALID_ADDRESS is returned by the same function mentioned previously.
I've managed to properly load an image using Karol's USB bootloader, here are steps to reproduce:
1. USB bootloader is configured to read an application image from 0x040000, size 0x3C0000, number of slots: 1.
So the application image should be linked using the following options:
Additionally, in an application linker script put a section as suggested earlier:
After linker script changes, you may need to perform a clean build (Project > Clean... and select building the project).
2. Convert SREC to BCH using these options:
3. Copy BCH file to USB disk and rename it to "img#mcu.bch".
4. Attach USB disk to SK-S7G2, the image should be loaded properly.
I was able to read the image from the flash drive successfully, but the call to status = g_sf_bootloader_mcu.p_api->appStart( g_sf_bootloader_mcu.p_ctrl ); returns SSP_ERR_NO_FLASH_IMAGES (713), in the bsp_warmstart.c file at line 37.
Attached are the linker files used to create the debug project (S7G2.ld) and the appplication bch file (S7G2_app.ld).