custom bootloader using FNET2.4.0

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

custom bootloader using FNET2.4.0

1,621 Views
nikhilsarnaik
Contributor III

Hello all,

Need some info on using ethernet bootloader  provided in FNET 2.4.0. Its a bit tricky what I am trying to do but let me explain.

 

Here is what I am trying to do

I have built a two stage custom bootloader for K60

STAGE 1:

this will be primary bootloader stored in protected area in at the start of flash.

the task of thos bootloader is just to copy the application binary image stored in external spi flash into the main code space.

And just jump to the address.

 

STAGE 2:

This is recovery mechanism where the primary bootloader will load the image of FNET ethernet bootloader from the external storage into code space instead of the application image.

 

This is where I am getting struck.

Stage 1 works OK for me as I can upload the application image from the external SPI flash into the main code space and run it without any problems.

But when I upload the image of FNET ethernet bootloader and try to run it, I get stuck in "default_isr entered on vector 3". which probably because I am not jumping at the correct address.

 

I have attached the linker files for reference

Original Attachment has been moved to: sec_btl.icf.zip

Original Attachment has been moved to: application_linker.icf.zip

Original Attachment has been moved to: prim_btl.icf.zip

0 Kudos
7 Replies

1,254 Views
UK_CF_FAE
NXP Employee
NXP Employee

Hi Nikhil,

Quick question for clarification.... what is the jump address that you're using when you want to jump to the ethernet bootloader? Since this is a 32-bit machine, Cortex-M4 expects the jump address to be word-aligned. All instructions are either 16- or 32-bit in size and so the destination _address_ is even. BUT!!!! the architecture requires that the jump address is specified to be odd because the address0 bit is used to signal to the core that the instruction is a Thumb instruction.

BOOT> erase all <<<<<<<<<<<<<<<<<<<<<<<<<<< Type this

Erasing...

0x00000000 to 0x0000BFFF skipped

0x0000C000 to 0x0007F7FF erased

0x0007F800 to 0x0007FFFF skipped

BOOT> tftp blinky_fnet.srec 192.168.0.10 <<<<<<<<<<<<<<<<< Type this

Press [Ctr+C] to cancel.

TFTP downloading 'blinky_fnet.srec' (srec) from 192.168.0.10: |

Entry point set to 0x0000C46D

TFTP completed (121654 bytes)

BOOT> set go 0xc421

go      : 0xC421


Mark

0 Kudos

1,254 Views
nikhilsarnaik
Contributor III

Hi Mark,

Thanks for the reply,

Since I am loading the ethernet bootlaoder image at 0x4000, I used 0x4421 as jump address

also tries 0x4001 but in both cases i get stuck in the default_isr.

Nikhil

0 Kudos

1,254 Views
UK_CF_FAE
NXP Employee
NXP Employee

OK, I understand. Is the ethernet bootloader recompiled to run at base address 0x4000?  Where is it's vector table located, and how is this managed in your configuration. Finding the right entry point can be hard (without the complication of needing an odd address). If you want to share with me privately the output map file from the FNET project targetted to 0x4000 then I can see if I can determine the entry point.

At this stage we are assuming that the code is jumping from the primary bootloader to the FNET bootloader and getting the address wrong. Since the primary bootloader is loading the application firmware OK, your process must be correct. How did you determine the entry point for the application firmware?.

0 Kudos

1,254 Views
UK_CF_FAE
NXP Employee
NXP Employee

Hi,

Thanks for sending me the map files for the app, primary and secondary bootloaders. The secondary bootloader contains all of the FNET image.
It's main.c appears to be located at fb61, but I suspect that you will want to start before that. Symbol _main is set to fb73. __startup is fa39. You have the source code, and you know how the MCU is configured by the primary bootloader. If the clocks and peripherals are set up correctly for the secondary bootloader, you could begin at _main. However, if the secondary bootloader needs to make some configuration of the chip, then _startup could be a good place to start, or someplace after that. Be careful of some of the write-once registers.

Your jump to 0x4421 as the start address appears to be near the start of module fnet_tcp  in function fnet_tcp_init which starts at 4411.

0 Kudos

1,254 Views
nikhilsarnaik
Contributor III

Thanks Mark for your inputs

I tried jumping at both _main and __startup addresses, but neither of them worked.

Jump to _main cause processor to go into default ISR.

However when I jump to __startup 0xfa39 the processor does not enter the default ISR, which made me think it is not initializing properly as you suggested. I tried jumping __low_level_init  0xfb77 and that just restarted the primary bootloader.

Nikhil

0 Kudos

1,254 Views
nikhilsarnaik
Contributor III

OK, I understand. Is the ethernet bootloader recompiled to run at base address 0x4000?

A: I did re-link the FNET bootloader to start at 0x4000 by modifying the start address as you can see in the linker file attached. Should I do any modifications at compilation as well?

Where is it's vector table located, and how is this managed in your configuration. Finding the right entry point can be hard (without the complication of needing an odd address).

A: I did not change anything in the FNET bootlaoder except in the linker file. I suspect that is the problem. Do I need to realocate the vector table. If yes can you please give me some pointers to do that?

If you want to share with me privately the output map file from the FNET project targetted to 0x4000 then I can see if I can determine the entry point.

A: Yes I can cretainly send the output map file via email.

At this stage we are assuming that the code is jumping from the primary bootloader to the FNET bootloader and getting the address wrong. Since the primary bootloader is loading the application firmware OK, your process must be correct. how did you determine the entry point for the application firmware?.

A: Again I as the application is stored at 0x4000 instead of 0xC000, I first tried using 0x4001 as entry point which did not work. then I used the base address as 0x4421 instead of 0xC421 and that worked perfectly OK. Although I did not get why the it worked because I am not using the ROM bootloader vector table. So that is still a mystery to me.

Thanks for looking into the matter

Nikhil

0 Kudos

1,254 Views
nikhilsarnaik
Contributor III

Also I must mention that the primary bootloader is basically a stripped down version based on the same fnet_demo project, where I removed all the services from the fnet stack except the serial services and fnet_mem drivers and used the same startup files.

Nikhil

0 Kudos