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

 

  

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

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

    Hello Heinz,

    I had a quick look through the downloader source and it seems like it won't be possible to implement file system support directly underneath it. Downloader framework uses "blockWrite" function of sf_firmware_image to store received data (either in the code flash and external memory), however sf_firmware_image (internal and external) are HAL-level frameworks - they don't require ThreadX. As such, they cannot have any dependencies on higher level frameworks such as FileX.

    My best recommendation would be to abandon downloader module and instead work with sf_firmware_image directly to program image from the file system into the code flash (downloading from external source into the file system on SDMMC should be possible without using any of the flashloader components). I can share an example of how this is done (programming from the file system - in my case it's USB drive), however you will not be able to use the flashloader GUI on the PC and will have to find another way of pushing program images to your board.

    Regards
  • In reply to Renesas Karol:

    Hello Karol,

    Thank you for your help.

    Can you please share me the example which you mention in your last answer for

    downloading from external source into the file system on SDMMC.

    But i still have problems to get the pure examples from the Flashloader Add-on to work.

    When i Import the projects from the Flashloader Add-on the stack section in the

    thread tab of the configuration.xml is not populated. The demo projects are throwing

    errors when i try to compile them.

     

     

    Any suggestions what I'm making wrong ?

     

    Best regards

    Heinz

     

     
     

  • In reply to HN66:

    Hello Heinz,

    You will need to take the pack from the flashloader archive from the Gallery and copy it over to internal/projectgen/arm/Packs. e2studio should be closed while this is done.

    Regards
  • In reply to Renesas Karol:

    Hello Karol,

     

    The missing pack was the problem and now i can compile all the projects.

    When i use the USB CDC Blocking Example it's working as expected, all fine.

    But the USB CDC Non-Blocking Example is crashing when i connect a USB cable.

    I start the program with a reset and it's running but at the moment i plugin the cable 

    the programm stops in the Downloader_entry function. It get's the error value

    SSP_ERR_INTERNAL from the g_sf_downloader0.p_api->open function call.

     

     

    I inserted an formatted SD Card in the DK-S7G2 and made all the required

    settings for the switches on the board.

    Am I still missing something ?

     

    Best regards

    Heinz

  • In reply to HN66:

    I debugged my USB CDC Non-Blocking problem a little bit deeper.

    The problem arises in the  call SF_FIRMWARE_IMAGE_open

     

     

    The macro SF_FIRMWARE_IMAGE_ERROR_RETURN in the slot loop throws

    the error SSP_ERR_ASSERTION. The variable values are:

     

    slot = 0

    p_cfg->p_record->image_addresses[slot] = 1048576

    p_cfg->p_memory_instances[0].start_address = 0

    p_cfg->p_memory_instances[0].slot_size = 4194304

     

     

     

    So the comparision can't be true.

    I hope this helps.

     

    Best regards

    Heinz

  • In reply to HN66:

    Hello Heinz,

    Seems like the image you've programmed (despite being linked at the correct offset) has incorrect start address value. Do you remember which values have been provided when generating BCH file?

    Regards
  • In reply to Renesas Karol:

    Hello Karol,

    I'm a little bit confused now. I haven't programmed an image or generated an BCH file so far.
    I'm just loading the downloader_usb_cdc_non_blocking in the debugger which automatically
    loads also the bootloader_usb_cdc_non_blocking file with it.
    Then i reset the debugger which should start the downloader part (as explained in the application note).
    The downloader seems to run and the led's are toggling.
    Now when i plug in the USB cable the downloader stops executing because of the error in the
    SF_FIRMWARE_IMAGE_open call.
    I haven't changed anything in bootloader/downloader combination till now.
    The properties in the Synergy configuration are as the application note describes.

    Further testing:
    When i comment out the problematic slot loop in the SF_FIRMWARE_IMAGE_open call and save the file as read only, then i can go a little further.
    Then with the Renesas Flashloader Utility i can connect and erase, but after update there is nothing on the sd card, so the bootloader has nothing to flash after restart also.

    Best regards
    Heinz
  • In reply to HN66:

    Hello Heinz,

    Have you allocated memory at 0x500 for the bootloader record? It's important that this section is always placed at this address or the bootloader/downloader will not be able to identify any images that are programmed onto the board.

    Regards
  • In reply to Renesas Karol:

    Hello Karol,

    I think the address 0x500 is already provided in the bootloader linker script.

     

     

    In the downloader linker script i can't see anything special about address 0x500.

     

     

    But as I mentioned before I'm just importing the projects provided in the gallery

    and want to use them with the development kit DK-S7G2 and I did not change anything

    in the projects, just use them as they are.

    It seem's to work until I plug in a USB cable and it stops executing because of the error in the
    SF_FIRMWARE_IMAGE_open call. I'm far away from downloading/flashing something because

    the downloader already stops at the plugin of the cable.

    Is there somthing wrong with the examples ?

     

    Nevertheless can you please provide me an example for downloading from external source into

    the file system on SDMMC as you mentioned in a previous post:

    My best recommendation would be to abandon downloader module and instead work with sf_firmware_image directly to program image from the file system into the code flash (downloading from external source into the file system on SDMMC should be possible without using any of the flashloader components). I can share an example of how this is done (programming from the file system - in my case it's USB drive), however you will not be able to use the flashloader GUI on the PC and will have to find another way of pushing program images to your board.

     

    Best regards

    Heinz

     

  • In reply to HN66:

    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

  • In reply to Renesas Karol:

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

    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

  • In reply to HN66:

    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