(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?

Hi,

The Synergy S3 devices do not have the same security and crypto capabilities as the S5 series and as such the SBM is not suitable for the S3 parts. Namely, the S3 does not have hardware support for public/private key crypto (RSA/ECC) or SHA256 hashing both of which are required by the SBM. The SBM also uses symmetric AES crypto which the S3 series does have.

Therefore, I would look at the flashloader project. This project is designed as a starting point to assist in developing a bootloader. It would be possible to add security features within the capabilities of the S3 hardware if necessary.

Below is a link to a pack file for the flashloader which can be used with versions of the SSP beyond 1.3.0.

renesasrulz.com/.../REA.Synergy_5F00_flashloader.0.0.0.pack.zip

Regards,

Ian.

Hi Ian,

thank you for your reply and the link to the pack file!
Yes I knew that only S5 MCU provide a secure bootloader function, I only want to point out that in this case the provided information are not clear compared to other modules.
So after installing the pack I can see now the regarding Renesas stacks. Is there any sample project or further documention available or can I use the document "Customizable Flashloader Solution for Synergy MCUs (R11AN0073EU0112 Rev.1.12 Dec 28, 2018)" even if it is limited to SSP 1.3.x ?

Thank you very much and best regards

Ralph

Hi Ralph,

The Flashloader is supplied as two projects used together. One is the bootloader and the other is the downloader. The downloader example is just that, responsible for downloading the new image and does nothing more than flash the board LEDs. In a real application the downloader is your application and the downloading the image will be part of it. The supplied examples use a Python script to perform the image transfer via a serial interface using the PySerial Python library. For this reason the downloader supplied must support a serial interface. There are two version supplied, one using a UART and the other using USB-CDC. The examples I am putting together (sorry for the delay I was feeling unwell on Friday) use USB-CDC and are based on the blocking example.

The bootloader as supplied operates slightly differently depending upon whether the blocking or non-blocking example is used. The blocking example as supplied separates the internal flash memory into 3 sections. One is for the bootloader. The rest is split into two equal halves called slot 0 and slot 1. The downloader is linked to run from one of these slots. So, say it is running from slot 0 then the next update will be put into slot 1 and then the next in slot 0 and so on. The bootloader when it starts looks at what it is in the two slots, performs a CRC and if both are valid it boots the one with the latest version number or the only valid one if that is he case.

For the non-blocking example the new image is downloaded into external memory. When the bootloader starts it checks the external memory for a new image and then handles the erasing of internal flash and programming of the new image.

All of this is documented in the supplied PDF but takes a few reads to get your head around! It did for me anyway.

The flashloader as supplied is unlikely to be a perfect fit but as it is supplied as full source then it can be changed as needed.

I'll post the examples as soon as I have them completed.

Ian.

downloader_usb_cdc_blocking_s3a1.zipbootloader_usb_cdc_blocking_s3a1.zipbootloader_usb_cdc_blocking_s7g2.zipdownloader_usb_cdc_blocking_s7g2.zip

Hi Ralph,

Attached are flashloader bootloader and downloader projects for the SK-S7G2 and TB-S3A1. Both are blocking using USB-CDC and the transfer interface.

Hopefully they will be useful.

Regards,

Ian.

Hi Ian,

thank you so much for your work and your support. Actually I can successfully program the bootloader and downloader to our custom board. With breakpoints  I've verified that the bootloader is called first before jumping to the downloader application with flashing leds.

But now I'm stucking in converting "downloader_usb_cdc_blocking_s3a1_crc.srec"  (or should I use the one without crc) file to BCH, the GUI always shows the error message "Error! Please fill in all the information before attempting to convert the script.".

I've attached the screenshot, but I think I've provided all necessary information.

Thanks and best regards

Ralph

Hi Ralph,

In the version of the bootloader/downloader supplied originally with the documentation has a limitation that the version downloaded by the debugger does not have the CRC in it. This is because the CRC is added in by the Python tool. So, on the debugger if the bootloader is run it will fail to call the main application because of this. So, the build step adds the CRC so it works with the debugger.

When converting the SREC file to BCH the non-CRC version should be used.

I did not use the PC GUI tool as I ran into problems initially and so called the scripts manually. Here's what I used for the S3A1 for slot 0.

C:\Python27\python.exe r_fl_mot_converter_modified.py -i downloader_usb_cdc_blocking_s3a1.srec -o downloader_usb_cdc_blocking_s3a1.bch -m 1024 -f 256 -e 0x20000 -l 0x20800 -s 0x0070000

I erased slot 0 via COM14 (-p option uses 13 (14 -1)).

C:\Python27\python.exe r_fl_serial_flash_loader.py -p 13 -c erase -b 0

Then to load it using COM14.

C:\Python27\python.exe r_fl_serial_flash_loader.py -p 13 -c load -f downloader_usb_cdc_blocking_s3a1.bch

I hope this helps.

Regards,

Ian.

Hi Ian,

thank you for providing the scripts. When I compile your S3A1 sample the .._crc.srec file is generated via the "CRC_Script" , which is included in your project folder. I've searched over and over but I was unable to find where this script is invoked and where to configure that. In your script you use the "r_fl_mot_converter_modified.py" script in the pack I've got, there is only the "r_fl_mot_converter.py" script , is there any relevant difference?

Thanks and best regards

Ralph

Hi Ralph,

 

The CRC version of the SREC file is created by an e2studio custom build phase. This can be found in the Builders section of the project's peroperties.

 

 

This is only needed when using the debugger and the first build and not when using a free running version of the donloader and/or subsequent builds.

 

Apologies for not included the newer Python file. Please find it attached. This was modified by another form user, Erik, and fixes an issue where a 4k section of flash can be mistaken for RAM and excluded from the output.

 

Regards,

 

Ian.

r_fl_mot_converter_modified.zip

Hi Ian,

thank you for providing the modified Python script! Actually I've got the problem, that your bootloader (S3A1) won't jump to my own downloader application (also S3A1), caused by different CRC values.
But the image is correct located - for my opinion - because, when I change the the crc value in the debugger, so that the values are equal, the downloader is started correctly (leds are flashing) and also the breakpoints work correctly (symbols match with .._crc_srec file).

I don't know what the reason could be, I compared everything with your project but I can't found any difference until now.
The header valid mask, image version everything is correct, but the CRC value. I use the same batch and the same values from your CRC script.

May be you have any idea?

Thanks and best regards

Ralph

Hi Ralph,

In the crc_add.bat file on the call to srec_cat.exe (line 33) temporarily remove the "2> nul" from the end of the line. This will then allow the srec_cat.exe tool to output to the build console. If there is anything going wrong with this tool it will be displayed. You can ignore the warning about a hole in the area being checksummed as the hole is where the CRC is being placed.

Regards,

Ian.

If the ID code is included in the S-Record the CRC calculate by the tool will be over a different range from the CRC calculated by the bootloader, so the CRC will be different.

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

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

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.

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

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

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

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

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

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

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

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

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