Questions about the Synergy Flash Loader Add-on

Hello Heinz,

It's possible to integrate downloader into your bootloader and have a single slot for your application. The only restriction is such that decision whether to boot the download or your application will have to be done before entering ThreadX kernel. Good place for this is R_BSP_WarmStart (with post-C argument). Blocking downloader should program incoming data directly into the application slot.

Regards

Hello Karol,

Thank you for your quick answer.

One Little question again:
Do you see any possibility for changing nonblocking Bootloader/Downloader combination
so that it is usable with a FAT formatted SD Card ?

Bigger problem:
Before changing anything i tried to test the Flashloader Add-on from the Gallery as they are.
But when i Import those Projects like bootloader_uart_non_blocking etc.. i see that the
stack section in the thread tab of the configuration.XML is not populated.
The only popualted thread is the HAL/Common, all other threads like blinky or downloader
are empty.
The Compiler then of course throws a lot of errors.

I also installed the Flashloader_pack1.2.0b1.exe which is required.

Any suggestions ?

Best regards

Heinz

Hello Heinz,

What error value do you see in SF_FIRMWARE_IMAGE_open? I recommend that you build all of the bootloader examples using O0 optimization.

I'm attaching a project that implements integrated bootloader/download solution with USB mass storage. The project is work in progress, so you'll notice that it looks for file to program into QSPI but doesn't do anything with it - my plan was to write a fail-safe copy into QSPI you can restore from later. Currently, when S4 or S5 is held on reset, the programmer will look for USB mass storage device (blinking green) with "img#mcu.bch" file  that will be used to program the microcontroller. After this is done, the device will reset and boot into your application.

s7_sk_ux_mass_host_boot_nano_1_2_0_wip.zip

Regards

Hello Karol,

The problem was the optimization, the imported projects set it to O2,
with O0 optimization it's working now.
Thank you very much for your support and the provided project,
i think it will be a good starting point for the bootloader configuartion
we need.

Best regards
Heinz

Hallo Karol,

I'm testing your demo now but i run into some problems with the BCH file generation.

I build a little test_blinky program and change the linker script so that the flash origin is at

0x40000 as it is needed for your demo.

But when i run the python script r_fl_mot_convert.py it throws me errors.

 

Can you explain me what is going wrong?
I also don't how to set parameter -l HEADERLOC, what offset should i set to this ?
In the examples of the bootloader/downloader application it's set to flash origin + 0x800
but why ?

Best regards
Heinz

Hello Heinz,

All client applications that can be dispatched from the bootloader must provide an application header which is inserted with sf_firmware_image_internal instance. You will also need to insert additional section at 0x800, just before .text:

. = __ROM_Start + 0x800;
KEEP(*(.sf_firmware_image_file_header*))

Unfortunately this will also add CRC and FLASH drivers, regardless of whether your client actually performs self-programming or not (you may have it in the bootloader like in my example).

Regards

Hallo 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 ?

 

Best regards

Heinz

 

 

 

Hello Heinz,

"Address/Pointer to Firmware Image Records" should be set to 0x800.

Regards

Hello Karol,

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.

 

Best regards

Heinz

 

 

Hello Karol,

 

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)

{

   app_set_status(APP_ERR_FLASH);

   break;

}

 

if (    SSP_SUCCESS == status

     || SSP_ERR_IMAGE_ALREADY_EXISTS == status)

{

   app_set_status(APP_STAGE_DONE);

   tx_thread_sleep(200);

   // NVIC_SystemReset();

 

   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 */

      g_sf_bootloader_mcu.p_api->close(g_sf_bootloader_mcu.p_ctrl);

      break;

      }

   }

   else

   {

   /* Notify the bootloader that open failed */

   break;

   }

}

...

 

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 ?

 

4861.boot_src.zip

Best regards.

Heinz

   

 

 

Hello Heinz,

Bootloader is not capable of jumping from ThreadX applications, hence using SystemReset is the safest way to launch an application. Code to start another application was shared by Gary in this thread: renesasrulz.com/.../27524 , however this approach is not recommended as few (important) things are already initialized at this point.

Regards

Hello Karol,

Thank you for your explanation, i use the SystemReset as you provide it in your demo.
In the R_BSP_Warmstart routine i use the Software Reset Detect Flag to determine if a power on of
the board has occured, which always first has to enter the bootloader code, or the Software Reset which
then starts the app. Now all works as expected.

Thanks a lot.

Best regards
Heinz

Hello Heinz,

As an alternative to reset flag, you can simply put a known value in Standby SRAM (i.e. at 0x200FE0000), which is enabled out of reset and preserved as long as the device is powered.

Regards

Hello Karol,

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?

Hi 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*))

in the linker script?

Regards,
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.

Hi JasonP,

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:

Regards,
adboc

Hi JasonP,

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:

Regards,
adboc

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.

• This function returns SSP_INVALID_ADDRESS (decimal value 22)
• Function call to sf_firmware_image_locate_memory_instance() at line 603 in sf_firmware_image.c is the return value origin.

 

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.

Hi JasonP,

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.

Regards,
adboc

Is it possible to share your project?

adboc,

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).

usbBootscripts.zip

Hi DJervis11, JasonP,

Please find a project:

S7_SK_bootloader_app_image_1_3_0.zip

Regards,
adboc

Thank you!

Thanks!

I was able to get the example up and running, and convert it to be used with the the PK-S5D9.

Thank you for the support!

Hi adboc
How the USB bootloader will jump from bootloader to this image app ?