topic Re: Bootloader_s32K how it works for S32K144 in S32 Design Studio

Bootloader_s32K how it works for S32K144

mrajanna — Fri, 24 Nov 2017 10:18:24 GMT

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

Re: Bootloader_s32K how it works for S32K144

jiri_kral — Fri, 24 Nov 2017 12:49:23 GMT

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

Re: Bootloader_s32K how it works for S32K144

mrajanna — Mon, 27 Nov 2017 11:05:03 GMT

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

Re: Bootloader_s32K how it works for S32K144

jiri_kral — Mon, 27 Nov 2017 12:01:22 GMT

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

Re: Bootloader_s32K how it works for S32K144

jiri_kral — Mon, 27 Nov 2017 12:24:34 GMT

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

Re: Bootloader_s32K how it works for S32K144

mrajanna — Thu, 30 Nov 2017 06:03:59 GMT

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

Re: Bootloader_s32K how it works for S32K144

jiri_kral — Thu, 30 Nov 2017 09:47:18 GMT

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

Re: Bootloader_s32K how it works for S32K144

mrajanna — Mon, 04 Dec 2017 12:14:11 GMT

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

Re: Bootloader_s32K how it works for S32K144

jiri_kral — Mon, 04 Dec 2017 14:30:36 GMT

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

Re: Bootloader_s32K how it works for S32K144

mrajanna — Thu, 07 Dec 2017 07:32:18 GMT

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

Re: Bootloader_s32K how it works for S32K144

jiri_kral — Thu, 07 Dec 2017 08:10:47 GMT

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

Re: Bootloader_s32K how it works for S32K144

mrajanna — Thu, 07 Dec 2017 09:29:42 GMT

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

Re: Bootloader_s32K how it works for S32K144

jiri_kral — Thu, 07 Dec 2017 14:25:01 GMT

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

Re: Bootloader_s32K how it works for S32K144

mrajanna — Fri, 08 Dec 2017 07:34:37 GMT

Hi Jiri,

From C program, I got to know bin file size is "35084".

When I use this file size, my loop is not getting break. It is reporting timeout error.

Please find below source code snippet and error.

******************************************************************************************************************

#define BUFFER_SIZE 35084u /* Size of data source */

uint8_t sourceBuffer[BUFFER_SIZE];

for( ;; )
{
LPUART_DRV_ReceiveDataBlocking(INST_LPUART1, &sourceBuffer, BUFFER_SIZE,10);
while(LPUART_DRV_GetReceiveStatus(INST_LPUART1, &bytesRemain) != STATUS_SUCCESS);
break;
}

******************************************************************************************************************

Any workaround for this problem?

Thanks

Mohan

Re: Bootloader_s32K how it works for S32K144

jiri_kral — Fri, 08 Dec 2017 09:00:11 GMT

Hi Mohan,

you need to put way bigger timeout in your receive function. Transfering 35kB takes at least 3+ sec. You also have to count time between receive start and clicking on Send button in your terminal. For testing purposes - 20 000 ms is good value.

Jiri

Re: Bootloader_s32K how it works for S32K144

mrajanna — Fri, 08 Dec 2017 09:28:01 GMT

Hi Jiri,

I tried with 20000,30000,50000 timeout values but still no luck. There is still timeout error.

for( ;; )

{

//LPUART_DRV_ReceiveData(INST_LPUART1, &sourceBuffer, BUFFER_SIZE);

LPUART_DRV_ReceiveDataBlocking(INST_LPUART1, &sourceBuffer, BUFFER_SIZE,30000);

while(LPUART_DRV_GetReceiveStatus(INST_LPUART1, &bytesRemain) != STATUS_SUCCESS);

break;

}

I have attached bin file, can you suggest exact timeout value to receive this file if possible?

Thanks

Mohan

Re: Bootloader_s32K how it works for S32K144

jiri_kral — Fri, 08 Dec 2017 09:40:29 GMT

Hi,

for me is 30s okay, receive ends with STATUS_SUCCESS and RAM is filled up:

In attachment is modified lp_uart_echo example which I used for test.

Jiri

Re: Bootloader_s32K how it works for S32K144

mrajanna — Tue, 12 Dec 2017 06:22:27 GMT

Hi Jiri,

I am trying to flash hello sample project binary from my boot loader to pflash at address 0x6000.

I generated hello.bin file using below command. The size is around 2KB.

C:\NXP\S32DS_ARM_v2.0\Cross_Tools\gcc-arm-none-eabi-4_9\bin>arm-none-eabi-objcopy.exe -O binary C:\Users\MKumar4\Desktop\S32_Arm_2.0_workspace\hello\Debug\hello.elf hello.bin

I could successfully receive the hello.bin over uart and flash to sixth sector(6*4096 = 0x6000)

After flashing, below assembly instruction seems to be not working, I mean boot loader to application firmware jump is not successful.

==> __asm__("b 0x6000");

If I am correct and above assembly instruction was successful, then hello.bin should be running in infinite loop(i.e, glowing LED on SW2 button press). This is not happening.

I have attached hello.elf and hello.bin files for your reference.

Thanks

Mohan

Re: Bootloader_s32K how it works for S32K144

jiri_kral — Wed, 13 Dec 2017 12:55:37 GMT

Hi Mohan,

it looks like that you just built hello example project and you are trying to flash it from address 0x6000. Above is in one answer that you need to modify linker file (for reference you can look at boot loader example - also mentioned above).

If your bin file is flashed from address 0x6000 - on that address starts IRQ Vector table. Executable code starts from 0x0410 + 0x6000 address and on this address is Reset handler. Entry point (main function) is on address 0x6000 + 0x0480 in your case. In attachment is object dump (arm-none-eabi-objdump.exe -d -x hello.elf) output from your hello.elf.

Jiri

Re: Bootloader_s32K how it works for S32K144

mrajanna — Thu, 14 Dec 2017 06:39:06 GMT

Hi Jiri,

Thanks for making the subject clear.

After reading your mail, I went through linker scripts for boot loader and hello. Both the linker scripts are using same memory location addresses. So definitely there is memory conflict.

I am attaching linker scripts of boot loader and hello for your reference(without modification).

Now I can change linker script of hello. I shall retain memory range for SRAM_L. Whether below modification is correct in hello linker script ?

MEMORY
{
/* Flash */
m_interrupts          (RX) : ORIGIN = 0x00006000, LENGTH = 0x00000400
m_flash_config        (RX) : ORIGIN = 0x00006400, LENGTH = 0x00000010
m_text                (RX) : ORIGIN = 0x00006410, LENGTH = 0x0007FBF0

/* SRAM_L */
m_data (RW) : ORIGIN = 0x1FFF8000, LENGTH = 0x00008000

/* SRAM_U */
m_data_2 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00007000
}

With above changes, it is still not working.

I have minimal knowledge on linker scripts. Can I get your help to modify hello linker script.

Thanks

Mohan