AN2720 Bootloader

[williamskj]

Hi,

I'm trying to write an ethernet bootloader for the NE64.
I've looked at a load of application notes for bootloaders, in particular AN2720.

My understanding so far....
The NE64 has just a single 64K block of flash memory. You cannot execute code in the flash block while you are erasing or programming anywhere else in the flash block. AN2720 gets around this using the DoOnStack function which executes the critical parts of the flash erase/programming code from the stack rather than flash.

I have some basic questions....
1) If I am using this functionality to re-program the whole flash block, how do I avoid overwriting the AN2720 C functions still in flash and still needing to be used ?
2) Can I reserve some flash memory and force these functions to reside there ?
3) Can I force the linker to always place the bootloader code part of my application at a certain absolute address and the rest of my application code to follow on from there ?

Thanks for any help,

Karl

[UK_CF_FAE]

HI Karl,

Thanks for your interest in the NE64. I think that you are going to have some problems implementing a Ethernet bootloader.

Sure, the flash on a NE64 can be programmed in situ (but with the code running from RAM) however, you're going to need some form of stack running, to be able to download  the code. Problem is, the stack will be larger than the RAM on the NE64. You're gonna need to download a page at a time (512 bytes, as I recall), cache that in RAM, then jump to RAM and write the new code, but this is all hideous. As you said, how do you ensure that you don't erase/program something that you need to go back to.

A more elegant solution would be with the ColdFire MCF52235 device, with 256kbytes of flash, arranged as 2 banks. You can run code from one flash bank and reprogram the other, and the InterNiche Niche_Lite stack easily fits into one bank. That's just what we did with the Ethernet Seminar lab material back in 2Q06 - the stack lived in one bank and the webpages in the dynamic flash file system live in the other bank.

[UK_CF_FAE]

... but to address your linker question, have a look at the #pragma CODESEG documentation in the linker manual.

In your code, you'll say

#pragma CODE_SEG MY_STUFF  //place this function where I say

void MyFunction(void)

#pragma CODE_SEG DEFAULT

.... and in the linker command file

SECTIONS

...

   MY_SPACE = READ_ONLY 0x8000 TO 0x8100;  //this is the properties for my memory area

PLACEMENT

....

   MY_STUFF INTO MY_SPACE

[williamskj]

Thanks for this information. I'd actually opened a Service Request with Freescale and they said the same thing but I've not had a chance to try it out yet.

This ethernet bootloader does seem a bit challenging, particularly for an embedded novice. I was suspicious from the start because there's no evidence anywhere of anybody having done this yet.

Unfortunately I have no choice but to persevere with the NE64 - its way too late for the hardware design to change to a ColdFire processor now.

I'm having enough problems just getting AN2720 to work on the NE64. I've got another Service Request open with Freescale on this. They've replicated the problem and its been referred to the hardware engineers. I will post again if anything useful comes back from this.

[dkelly]

Thought it best to reawaken this thread rather than start another separate as that which preceded me should be of help to future readers.

AN2720 v2 was recently released. I don't have a copy of v1 but I have inherited a project which uses a bootloader obviously derived from AN2720.

Source code files for AN2720 include the following snippet:

EVEN ;Make code start word aliened
SpSub:
ldab SpSubEnd-SpSub+3,sp ;get PPAGE back from stack
stab PPAGE ;Store the PPAGE address

But in the pdf version it says:

ldab SpSubEnd-SpSub+2,sp ;get PPAGE back

Am guessing the source version is correct.


Second question is about flash.c. In the pdf file Flash_Write_Word() converts 24 bit far_address into 16 bit address. Tests address for odd. Then the pdf version passes 16 bit address to DoOnStack() which is declared:

extern DoOnStack(unsigned int *far address);

DoOnStack() is used with far_address everywhere else in the pdf other than Flash_Write_Word(). Source file versions pass far_address. So what is the point in making a 16 bit address out of the 24 bit far_address?

Once again it appears the source code is most correct and pdf is less correct. Correct?

[williamskj]

To be honest, we gave up on this. I'm not saying its not possible but there were too many discouraging comments from far more experienced Freescale experts. In our case it was a 'nice to have' feature and we could not justify the effort when there was a real risk that we would not succeed. Good luck with it though !

[dkelly]

In my case I can't give up, have several thousand of these fielded and have to figure out what is happening. The bootloader/updater is based on AN2720 but gets the new firmware image from an Atmel Dataflash on SPI.

Thinking it best that I study AN2546 and AN3391 to create a bootloader that runs completely out of RAM. But have to understand my existing bootloader well enough to cause it to install the new.