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

 

  

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

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

Children