Hi,
Can I get any guide to understand the working scenario of boot loader example.
Background:
I am designing and implementing the boot loader, primary responsibility of boot loader will be to update MCU firmware to flash memory.
Boot loader shall be receiving MCU firmware binary(segregated into 'X' parts ) sequentially over UART from teraterm/putty.
I don't have prior experience of writing boot loader. Any guide would be very much helpful to me.
I have gone through flash_partitioning_s32k144 example and comfortable in reusing it for flash programming.
Also please suggest which format of binary is good to consider, i.e srec,hex,bin,..... ?
Thanks
Mohan
Solved! Go to Solution.
Hi Mohan,
yes - that's way how for example RAppID bootloader works. Boot loader part is flashed from 0x0000 to 0x2000 and bootloader is flashing application from 0x2000 address.
After reset is RAppID bootloader waiting for new firmware till timeout occurs. Then is executed application (if it is present).
In your case may be better idea (to save boot time) after reset check some GPIO pin (set by master MCU as a update request flag) - if the update is not requested - execute your existing firmware without any delay (if is present in the Flash memory).
Jiri
Hello Jiri,
Are you passing the bin file directly over UART?.We need to do some parsing right?
Can I transfer hex file (Intel Hex format)?
Hi,
actually - Mohan's project in this thread is something like very basic example. In my opinion best file format for bootloader app is s-record. Anyway - you can use intel .hex file too, but you need to convert text in .hex file into binary on bootloader side. With almost very same effort you can implement s-record parser.
Jiri
Thank you Jiri.
Hi Jiri,
That's awesome.
But it is not working for me. Please see below screenshot.
Whether something I am missing. I am testing on S32K144 EVB.
Thanks
Mohan
What about data in sourceBuffer? It is possible that your terminal is not sending binary file properly. I'm using RealTerm
and S32K144 EVB too.
Jiri
Hi Jiri,
Yes problem was with Teraterm.
RealTerm looks more robust while sending binary data over serial.
Yes now I could successfully make a jump from boot loader to application.
Thanks
Mohan
Hi mohan
I am trying to build Boot_loader.zip project but its creating errors for me.Please have a look at errors
Vishakh
Hi Mohan,
you can look at this presentation - Overview of RAppID Bootloader|NXP for more info.
Example project is empty project configured for RAppID BL Tool. Inside project is testing .srec file (located in project's Debug folder) . If you have S32K144 EVB - please download updated Bootloader file (rbf). Copy this .rbf file into mass storage device on your S32K144 (on my machine it is drive D:\ ). Restart your EVB.
Modify bootloader.rbl file to point on testing .srec (I copied the file into C:\NXP folder on my machine)
Start RAppID BL Tool and open modified bootloader.rbl file and press Start Boot Loader button.
If you wanna use RAppID BL Tool - starting with Bootloader_S32K example is good idea.
If you like to write your own bootloader - the implementation is up to you (as I mentioned in different thread). You also need to write PC side application. In my opinion .srec file is best format for bootloader. It can be easily parsed and contains addresses.
Jiri
Hello sir,
As m using s32k144 EVB .as per the steps given i copied the bootloader_S32.rbf file into mass storage of EVB.Now it turn to BOOTLOADER and now it is not coing out of bootloader mode even i unpulged USB as well reset the Board.Every time it is showing BOOTLOADER folder. How can I get back to normal mode because i m unable flash it as it is in BOOTLOADER mode.
Looking for the support !!
Thanks !!
Hi Jiri,
Thank you very much for sharing the information.
With your example, I understand we are not flashing bootloader as we are directly copying bootloader file(.rbf file) into mass storage device i.e, S32K144.
We are only flashing application file(bootloader_S32K.srec) using RAappID BL tool. Can I get any guide on how this works internally.
To be more specific, In my requirement architecture would be FOTA(firmware on the air) update. Bootloader in S32K144 MCU would receive application firmware in chunks over UART.
As of now we don't have boot loader. So I want to implement boot loader and on top of that I should support firmware update.
Thanks
Mohan
Here is application note - Serial bootloader for MPC5748G. Hope it helps to understand how bootloader works https://www.nxp.com/docs/en/application-note/AN5319.pdf
Hi Jiri,
In S32K144 MCU, whether can we have both boot loader executing from flash memory and updating of application firmware taking place to flash memory at the same time ?
Please guide the best approach whether executing boot loader from SRAM or flash memory, which is good option on S32K144.
This is to understand fundamental Read-while-write operation of flash memory in S32K144 MCU.
Thanks
Mohan
Hi Mohan,
yes - that's way how for example RAppID bootloader works. Boot loader part is flashed from 0x0000 to 0x2000 and bootloader is flashing application from 0x2000 address.
After reset is RAppID bootloader waiting for new firmware till timeout occurs. Then is executed application (if it is present).
In your case may be better idea (to save boot time) after reset check some GPIO pin (set by master MCU as a update request flag) - if the update is not requested - execute your existing firmware without any delay (if is present in the Flash memory).
Jiri
Hi Jiri,
I could write small boot loader that flashes the received application firmware from teraterm over UART to flash memory(10th sector = 10*4096 = 40960). How can I jump to this address from boot loader on S32K144?
Thanks
Mohan
Hi Mohan,
you can use inline asm branch instruction - in case that you are using C language and on address 0xA000 is entry point (main) function of your firmware:
__asm__("b 0xA000");
Jiri
Hi Jiri,
Can you guide me how to receive and parse SREC file over uart. So after parsing the SREC file, I should flash the file to flash memory.
Thanks
Mohan
Hi Mohan,
In your case - flashing one kind of application (your firmware) - with known format (or the format can be coordinated with existing bootloader) - is easier way transfer binary file without any parsing. You need server side application (on PC or your master MCU) which is sending portion of data per client request. You also need to check if the data are okay (CRC/Verification read...). In ideal case (bin file never exceed 64kB) you can use minimalistic settings - copy data from UART directly into RAM then flash data from RAM into PFLASH and verify with Server if the data are correct. In this case it is possible use binary file send from terminal.
Using srec is more universal - but more complicated. You will need server side application which is sending data on client (S32K144) request (for example one srec line). On client side you need to identify type of line (S0-S9), extract addess, data and check CRC. You also need to convert text data into binary format.
You can start with srec description here SREC (file format) - Wikipedia
Jiri
Hi Jiri,
Assume I have bin file of size 35KB.
Which UART functions should I use to receive complete file in one shot. This is only for testing purpose.
Later I shall implement that you suggested like part by part with proper acknowledgements.
For example:
How I can use below functions to receive complete bin file of 35KB in one shot.
LPUART_DRV_ReceiveData(INST_LPUART1, &sourceBuffer, ???????);
while(LPUART_DRV_GetReceiveStatus(INST_LPUART1, &bytesRemain) != STATUS_SUCCESS);
Thanks
Mohan
Hi,
you can use something like
LPUART_DRV_ReceiveData(INST_LPUART1, bin_data, BIN_LEN);
where BIN_LEN is size of binary file and bin_data is global array uint8_t bin_data[BIN_LEN].
If you don't know size - you can add some timeout in receive-done-check loop and use bin_data array with some MAX_BIN_LEN constant (for exampe 0xC000).
Normally is RAM divided into two sections - m_data and m_data_2 - first one with 0x8000 size and second with 0x7000 size. In attachment is modified linker file with m_data section only. RAM size is 0xF000.
Jiri
Hi,
the rbf file is standard .srec file and it is bootloader for S32K144. Easiest way how to flash this file into S32K144 is copy it into mass storage device on EVB - the srec will be automatically flashed after reset. You can flash it by S32DS too.
You can see (from .srec file) that bootloader occupied memory from 0x0000 up to 0x2000. You can also see that uploaded application starts on 0x2000 address (normally application starts after flash config on 0x0410 address).
There is no source code available for RAppID bootloader. In your case (updating firmware by other MCU) - you need to write your own bootloader for S32K144 and other side for your master MCU.
You can find tutorials on Internet related to bootloader for ARM - like this ARM: How to write a bootloader or How to develop and debug BOOTLOADER + APPLICATION systems on ARM Cortex-M devices
Jiri