S7 Bootloader question

Hi,

I am working on this basic bootloader application: renesasrulz.com/.../3223 and I am trying to upload the "S7SK_HMI_MMF" project. In this case, I have to copy on a USB stick the two binaries: flash.bin and qspi_flash.bin. My question is: what are they referred to? Is the first related to the executable and the second to the GUIX resources?

In particular, I would like to try to load my own GUIX HMI project application using the bootloader: how can I generate the two .bin files to copy on the USB stick? I saw there is a .bat file that should do the work, but it seems it doesn't work. Any help?

Thanks,

regards.

  • In reply to Laboratori Elecsan:

    Hi,
    my board is a custom board, based on a PE-HMI1, in which there is a QSPI memory on it, the same that is present on the SK-S7G2 kit. However, my problem is on the software side, because I get an error building the project as described above.
    Thanks!
  • In reply to Laser:

    Hi Laser,

    Since BSP for PE-HMI1 is used, which doesn't have QSPI memory, there are no BSP file required for this module. If you're using SK-S7G2, you may see synergy/board/s7g2_sk/bsp_qspi.h and bsp_qspi.c files. These ones contain required enums etc. referenced in the r_qspi.c. Please note that bsp_qspi.h should be included in bsp.h file and the QSPI initialization function should be called in the bsp_init (bsp_init.c file). I suggest creating new BSP pack for you PE-HMI1-based board with required files for QSPI. Copying these files from SK-S7G2 BSP could be a good starting point with some changes required (e.g. #if defined(BSP_BOARD_S7G2_SK)).

    Regards,
    adboc

  • In reply to adboc:

    Hi adboc,
    you are right. I will try to do a custom BSP for the PE-HMI1 keeping in mind your suggestion. I will update about the situation soon.
    Thanks.
  • In reply to Laser:

    It's annoying that it's not possible to make changes to the drivers library files (e.g. include newly added files), are they protected? Is there a workaround for this?
  • In reply to Laser:

    Yes, you can exclude a file from build (right click > Exclude from build...), copy it to src/ directory and make required changes.

    Regards,
    adboc
  • In reply to adboc:

    Hi,

    I created a new project for PE-HMI1 platform, and I composed the configuration.xml file similarly to the SKS7_BLv2 bootloader project one. I did some changes due to the fact that the QSPI is not present in the PE-HMI1 default configuration. Building the project, some errors occur in the "usbh_thread_entry.c" file regarding FileX:

    In fact, FileX on fx block is not present. The strange is that the same errors are present in the Renesas SKS7_BLv2 bootloader, since the configuration is the same, but building the project, they don't cause any errors. Is there an explanation for this? How could I fix the problem on my project? What do I miss?

    Thank you.

  • In reply to Laser:

    Hello Laser,

    These are semantic errors raised by Eclipse Static Code Analyzer (Codan). If your project doesn't build, compiler output (in console tab) should show why.

    Regards
  • In reply to Renesas Karol:

    Hi,
    I am working on the bootloader application on a PE-HMI based platform.
    I read the documentation included in the SK bootloader by Renesas and the changes required to the S7G2.ld script. Are they the same for the PE-HMI1 platform? In case they are not, how can I change that script to make the application loaded by the bootloader?
  • In reply to Laser:

    Hello Laser,

    PE-HMI1 uses the same MCU as SK-S7 (although with few more pins). The linker script is the same between the two boards so same modifications apply to PE-HMI1.

    Regards
  • In reply to Renesas Karol:

    Hello Karol,

    I went ahead in debugging my bootloader for PE-HMI1, and I found a problem in the "Erase QSPI Flash" section. With reference to the SK bootloader application from Renesas (from which I have taken the structure), in the main_thread_entry.c there is the section:

               case ERASE_QSPI_FLASH:
               {
                   bool qspi_status;

                   uint16_t erase_count = 0;
                   uint32_t address = QSPI_BASE_ADDRESS;

                   static uint8_t toggle = 0;

                   ssp_err = g_qspi.p_api->open( g_qspi.p_ctrl, g_qspi.p_cfg );
                   if (SSP_SUCCESS != ssp_err)
                   {
                       while(1);
                   }

                   do{...

    My application stops in the while(1) because the value of ssp_err is SSP_ERR_UNSUPPORTED instead of SSP_SUCCESS. Which can be the reason for that behaviour? In the configuration.xml I enabled the QSPI in the "Pin" tab, the chip is mounted on the board (the same chip for the SK), and the build process gives no errors. On the USB key the flash.bin and flash_qspi.bin are present.

    Any advice is appreciated.

    Thank you.

  • In reply to Laser:

    Hello Laser,

    QSPI driver returns SSP_ERR_UNSUPPORTED only in 1 place in R_QSPI_Open - when manufacturer id, memory type and capacity are all zero. This is normally observed when your QSPI part is not initialized properly inside bsp_qspi.c/h. Please verify that your application performs valid initialization sequence in bsp_qspi_init. In projects for SK-S7, you can see the necessary information being read back on lines 232-234 of bsp_qspi.c.

    Regards
  • In reply to Renesas Karol:

    Thank you, now I succeded in compiling a bootloader project for PE-HMI1 platform, now I have a running GUIX application loaded by the bootloader.
    I would like to point out the following behaviour: when I load a HMI application with the bootloader, I see the images on the display flickering every time I touch the screen (so, I guess, every time the graphics is refreshed). This behaviour is not seen when the application is directly programmed by JTAG into the flash (without bootloader).
    Which can be the explanation for this flickering effect? Perhaps it is due to delays requested to access the QSPI for retrieving the GUIX graphics? Any idea to solve the problem?
    Thanks.
  • In reply to Laser:

    Hello Laser,

    When your application is directly programmed into the code flash, are resources still moved into QSPI? QSPI memory tends to be much slower than code flash however the performance should still be sufficient for rendering graphics.

    Regards
  • In reply to Renesas Karol:

    No, they aren't. When I program directly into the code flash the resources aren't moved into flash. This is one of the differences between the two situations. So, you think the increased delays cannot be the reason for the flickers?
  • In reply to Laser:

    Hello Laser,

    Apply the python script to your resources to place them in QSPI but link and program your project in the standard way (i.e. no MMF and through the debugger) - I'm interested to see whether the QSPI or MMF is causing this problem.

    Regards