Questions about the Synergy Flash Loader Add-on

Hello,

 

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

 

 

Best regards

Heinz

 

  

  • In reply to Renesas Karol:

    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

     

     

     

  • In reply to HN66:

    Hello Heinz,

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

    Regards
  • In reply to Renesas Karol:

    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

     

     

  • In reply to HN66:

    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

       

     

     

  • In reply to HN66:

    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
  • In reply to Renesas Karol:

    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
  • In reply to HN66:

    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
  • In reply to Renesas Karol:

    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?

  • In reply to JasonP:

    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

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

  • In reply to JasonP:

    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

  • In reply to 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.

  • In reply to JasonP:

    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

  • In reply to adboc:

    Is it possible to share your project?
  • In reply to adboc:

    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