Bootloader_s32K how it works for S32K144

cancel
Showing results for 
Search instead for 
Did you mean: 

Bootloader_s32K how it works for S32K144

Jump to solution
31,714 Views
Contributor V

Hi,

Can I get any guide to understand the working scenario of boot loader example.

pastedImage_1.png

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

Labels (3)
1 Solution
181 Views
NXP Employee
NXP Employee

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 

View solution in original post

39 Replies
163 Views
Contributor V

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;
}

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

 

pastedImage_1.png

Any workaround for this problem?

Thanks

Mohan

0 Kudos
163 Views
NXP Employee
NXP Employee

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

0 Kudos
163 Views
Contributor V

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

0 Kudos
163 Views
NXP Employee
NXP Employee

Hi, 

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

pastedImage_1.png

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

Jiri 

163 Views
Contributor V

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 

0 Kudos
142 Views
NXP Employee
NXP Employee

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

142 Views
Contributor III

Hi Jiri

I am able to parse s record file and received over UART. I am storing from 0x6000 on wards. Can you please elaborate what all changes we need to do for jumping into user application from boot-loader application (linker and start up codes).

__asm__("b 0x6480") this instruction can be used to jump to application ,but how we can fix the address?.

How we can reallocate vector table?

I have minimal knowledge on boot loader.

Regards

Vishakh

0 Kudos
142 Views
Contributor V

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

0 Kudos
142 Views
NXP Employee
NXP Employee

Hi Mohan, 

your linker files looks okay. Are you jumping into hello main function? (if nothing changes - from last time __asm__("b 0x6480");  

Are you able debug what's going on? 

Jiri

142 Views
Contributor V

Hi Jiri,

I could successfully receive hello.bin file. But receive buffer is all zeros. This could be one reason.

Function calls to erase and program flash memory(address = 0x6000, size = 2000) is all success.

After writing hello.bin to pflash, I see only zeroes at 0x6480(below screenshot). I have doubt on whether bin file was properly generated from elf file.

pastedImage_1.png

After pressing F8, I see program stops in DefaultISR(below screenshot).

pastedImage_2.png

Do you have any comments please.

If you don't mind can you please try once on your setup ?

Thanks

Mohan

0 Kudos
142 Views
NXP Employee
NXP Employee

Hi Mohan, 

the bin file (from attachment above) is okay - you can check it in some hex editor (for example VIM):

pastedImage_1.png

You can see that modified lpuart echo example (attached above too) can receive bin data correctly - on screenshot you can see vector table in memory view - in the RAM. I'm using RealTerm for transfering binary files. 

 Can you share your project? 

Jiri

0 Kudos
142 Views
Contributor V

Hi Jiri,

I am attaching the project file. Please find the same.

With this boot loader I want to flash application firmware(hello.bin).

Linker scripts for boot loader and hello were added in previous thread.

For your reference:

You can do fresh build of sample hello project from sample and create hello.elf file. Then you can create bin from elf with below command.

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

Thanks

Mohan

0 Kudos
142 Views
NXP Employee
NXP Employee

Thanks for sharing the project. So - I fixed some stuff - the main issue was enabled IRQ during flash operation. Now can be bin data  flashed: 

pastedImage_1.png

After jump to 0x6480 is the hello project running (you can see blue LED turned on/off by button). 

Jiri

142 Views
Contributor III

Hi Jiri

I am trying to execute the same file you have attached here.I am able to read the binary file through UART but branching instruction is not success.Please find the error log.error.png

0 Kudos
142 Views
NXP Employee
NXP Employee

Hi, 

it looks like that you are jumping into interrupt vector table instead of main (or your entry point). 

Jiri 

0 Kudos
142 Views
NXP Employee
NXP Employee

Well, try to check if your main() function is really on address where you are jumping. 

0 Kudos
142 Views
Contributor III

Hi Jiri

Please find the attached log.error1.png

0 Kudos
142 Views
Contributor III

Hi Jiri

I am using the same code attached in this thread .

0 Kudos
142 Views
Contributor III

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

0 Kudos
142 Views
NXP Employee
NXP Employee

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

0 Kudos