(Nano-)Bootloader, Flashloader (<=SSP 1.3.0), Downloader, Secure Boot Manager (S5 only): Please advise what to choose for a S3A1 UART/USB field update?

We started in 2016 with S7 and S3 µC and developed our own boards, since that we are waiting for an easy to implement and maintainable bootloader/flashloader.

Every time in the last years when I've visited the Renesas booth on embedded world, they guys told me that an useable bootloader framework will be offered in the future.

Then finally when Renesas provides a bootloader/flashloader, Renesas - as far as I know - stopped the support with SSP 1.3.0., why?

May be I'm the only developer, who is confused which bootloader to choose now, ensuring support by Renesas also in future SSP versions.

So I'm not misunderstood, I have to say that I really appreciate SSP and also the support here in RenesasRulz, but regarding the subject bootloader I can't see a really clear and future-proof concept compared to other SSP modules.

E.g. ST provides CAN/Ethernet/USB/UART bootloader versions for their STM32 Cortex M series, why it is not possible to provide something similar for the Synergy family?

Background of this post is, that we actually have to plan a project for huge number of devices, installed all over the country in the next years, but being now unsure which solution we should choose.

What other piece of advice can you give us than to implement the bootloader itself?

Thank you very much and best regards

Ralph

  • In reply to Jeremy:

    Thank you for your replies!

    Yes,  Jeremy you are right, after adding "NOLOAD" in the linker script to the ID code,  they weren't part of crc calculation any longer and crc values are equal now!

    I've compiled the flashloader projekt with Visual studio and replaced "r_fl_mot_converter.py" with "r_fl_mot_converter_modified.py".

    But nevertheless, if I wan't to convert the srec file into a bch file or if I want to connect to the S3A1 MCU nothing happens, no entry to the log window (only after saving the default options):

     

    So actually I'm still stucking in the flashloader app! I hope I'm not to annoying, but I'm very grateful for any support!

    Thanks and best regards

    Ralph

  • In reply to Ralph:

    The python scripts need to be in the same directory as the executable. If I debug the GUI under VS I see :-

    If I leave the python scripts in their default location.

    If I then copy the scripts into the directory where the .exe is (while still debugging under VS):-

    The GUI runs as expected :-

     

    pyserial and modcrc need to be downloaded and installed in python as well.

  • In reply to Jeremy:

    Hi Jeremy,

    thank you very much for your very helpful reply!

    I've copied the files and installed pyserial and modcrc successfully, so far so good.

     

    But the visual studio output window shows the following syntax errors:

     The first one is shown when I press the convert button,  the 2nd one when I press the connect button. Do you have any idea what's going wrong?

     

    Thank you and best regards!

    Ralph

  • In reply to Ralph:

    Which version of Python are you using? I see :-

    When I try to open an invalid s-record file. The flashloader documentation shows :-

     

    I am using python 2.7.16

  • In reply to Jeremy:

    Hi Jeremy,

    thanks again for your advice! I've installed Python V3.8, which is obviously not compatible with the actual provided flashloader scripts.
    But indeed with Python Version 2.7.16 it works so far (convert and connect), during the day I will also test the download function...

    Thank you and best regards

    Ralph
  • In reply to Ralph:

    Hi Jeremy,

    with Python Version 2.7.16 the programming of the MCU slots works as well. Thanks a lot for your support!

    Best regards

    Ralph

  • In reply to Ralph:

    Hi Jeremy,
    may be you have an idea concerning the following problem: I would like to use threads in our own bootloader (e.g. for USB), but as soon as I add a single thread (only with one tx_thread_sleep()) , the bootloader doesn't jump to the application anymore (I've checked the jump address, all seems to be correct).
    First I thought it is because of active interrupts in the background (I had the same effect with pure "HAL"-bootloader, if I didn't close all running timer before jumping to the application, it fails), but I saw just before the bootloader performs the jump to the appliction, all INT's were disabled.

    Is there any possibility to use threads in the bootloader and if yes, what issue I have to take care of, that the application jump succeeds?

    Thank you and best regards

    Ralph
  • In reply to Ralph:

    Yes it is possible to use ThreadX in the bootloader, you just have to make sure the device is in the correct state before you jump to the application. The CPU will need to be in the state it is at start up (using the correct stack etc), the MPU stack monitor will need to be disabled (both the PSP and MSP stack monitor will be enabled in an SSP 1.7.0 threadX based project), peripheral drivers closed so no interrupts occurs (this will also mean the Systick timer).
  • In reply to Jeremy:

    Hi Jeremy,

    I found this piece of code in the forum and would like to ask , whether this is it, what I have to do before I jump to the applicatiopn, but unfortunately "_ux_system_host" is marked as an undeclared symbol from the compiler. I don't know where it is decalred?

    if( DISABLE == EnableDisable )
    {
    /** Store the interrupt state */
    old_primask = __get_PRIMASK();

    /* Disable other threads whilst flash erasing */
    // tx_thread_suspend(&_ux_system_host->ux_system_host_hcd_thread );

    /* Disable the SysTick timer */
    control_reg_value = SysTick->CTRL;
    SysTick->CTRL = 0;
    NVIC_DisableIRQ( SysTick_IRQn ); /* Disable the SysTick timer IRQ */
    NVIC_ClearPendingIRQ( SysTick_IRQn ); /* Clear any pending SysTick timer IRQ */

    __disable_irq(); /* Disable interrupts */
    }

    Thank you and best regards

    Ralph
  • In reply to Ralph:

    Hi Jeremy,

    I've added "USB on ux" to my idle thread in the configurator, after this "_ux_system_host" was declared and I could compile the project, but the jump to application failed again.

    Thank you and best regards

    Ralph
  • In reply to Ralph:

    Do you disable the Stack monitor before doing the jump from the bootloader to the application :-

    R_SPMON->MSPMPUCTL = 0xA500; /* Enable writes to MSP SPMON registers */
    R_SPMON->PSPMPUCTL = 0xA500; /* Enable writes to PSP SPMON registers */

    R_SPMON->MSPMPUCTL = (uint16_t)0x0000; /* Disable MSP monitoring */
    R_SPMON->PSPMPUCTL = (uint16_t)0x0000; /* Disable PSP monitoring */

    __set_CONTROL(0); // Set the CPU to use MSP stack

    __ISB(); //Ensure instructions use the new stack setting
  • In reply to Jeremy:

    Hi Jeremy,
    thanks a lot for your support!!! Now the jump works, also staying in Bootloader in case jump fails!
    Next step is customizing the downloading and flashing function...

    Best regards
    Ralph
  • In reply to Jeremy:

    Hi Jeremy,

    in the meanwhile I've nearly finished my bootloader in that way, that the bootloader itself receives the raw main application bin file from a small PC application via USB or UART and writes it directly to the internal code flash and then jumps to the main application, so far so very good!

    Actually I use as main application the tiny downloader application provided by the sample from Renesas. The application consits only of a blinky function and one thread with the sf_downloader framework, which I don't use due to the fact, that the downloading job is performed by the bootloader itself.

    In my bootloader solution - If I understand it correct - I only use the "sf_firmware_image_file_header" generated by the sf_downloader framework and inserted at memory address ". = __ROM_Start + 0x800;" via the linker script , which is used from the bootloader to detect whether a valid main application is stored in the internal code flash or not. For my opionion the remainig features (including comms and mcu memory, ... ) of sf_downloader framework won't be used and are not necessary in my case.

    So my question is: Is there any possibility to provide only the "sf_firmware_image_file_header", with its data, whithout adding the complete sf_downloader framework (including comms and memory, ... ).
    And if yes, how can I ensure that the "sf_firmware_image_file_header" struct is filled with the correct values or how can I do that manually (e.g. own struct with the same members)?

    I hope my description is not too confused to understand my issue.

    Thank you and best regards
    Ralph
  • In reply to Ian:

    Hi Ian, your answers are helping me to run the flashloader on s5d9 pk but i wanna run it with ssp 1.5.2 is it possible? because when flasing the code it throws this message: "having built not-active build configuation "Debug_slot0" " what is the problem ? Could help me please?
  • In reply to Ian:

    Hello Ian please can you provide me with uart exemples? am working with ssp 1.5.2 thank you !