Author Topic: SW uploads to SPI FLASH  (Read 26141 times)

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
SW uploads to SPI FLASH
« on: August 13, 2007, 12:05:29 AM »
Hi All

I have managed to add a boot loader to the M5223X demo project which allows SW uploads to an external SPI FLASH.
It posts the file to the start of SPI FLASH and the boot loader reads this and programs it to program FLASH.
I believe that it is compatible with AT45DB011B, AT45DB021B, AT45DB041B, AT45DB041D, AT45DB081B, AT45DB081D, AT45DB161D but I have only actually tested with AT45DB041B.
An encryption option is also included so that the distributed code is not readable at any stage until it is extracted by the boot loader to its final destination in FLASH.

I have had to increase the boot loader space to 4k since the SPI driver and FLASH driver are needed at the same time and the 2k mark was easily passed…

What I haven’t done is used the SPI FLASH for anything other than the SW upload so the application will still have to sort the general use out itself. My solution was to define a file (HS.bin in the demo project) which is diverted to the SPI FLASH rather than the internal FLASH file system. This works fine for the SW upload but is far from a general solution for application data saving and retrieval along side an internal file system!!

Nevertheless it enables full 256k (minus Bootloader and any file system space) SW uploads and so opens up some interesting new possibilities. This should be included in the next M5223X SP.

Regards

Mark

P.S. See also the general discussion about external SPI FLASH in  http://www.utasker.com/forum/index.php?topic=4.0

Offline Kremer

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: SW uploads to SPI FLASH
« Reply #1 on: August 22, 2007, 03:34:49 PM »
 Hi Mark

 Thank you for the help supplied on freescale´s forum about my bootloader question.
 Finally i had time to do it and this topic shows exactly what i did here.
 I did the bootloader using the same ammount of flash you used (0x1000) and the user code is stored by the user application on a SPI serial flash (m25P40 from ST), so it´s able to store full 256K of user program, like you already said, minus bootloader size (4K).
 I have one question. In your code, the serial flash load with user code to be flashed into CF internal flash is user code responsibility or your bootloader has an ethernet code wich handles the transfer between a binary file from a PC to the serial flash, and after do it it flashes de internal memory?
 In my case, the user code is responsible for load the serial flash, and the bootloader only checks the serial flash and then flash the internal memory.
 The thing works smoothly. Thank you.

 Regards

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: SW uploads to SPI FLASH
« Reply #2 on: August 22, 2007, 04:41:32 PM »
Hi Kremer

The uTasker (Bare-minimum) Boot loader works exactly as yours does. The boot loader itself is entirely useless - it needs to be loaded together with the first application and the application is then responsible for loading the new code to the correct SPI FLASH location in the correct format.

This means that the boot loader is as small as absolutely possible (that is where the "Bare-minimum" comes from since it really only does that what is absolutely necessary to ensure that the function works reliably). However it ensures that it is not possible for a card to be left in an unusable condition - it checks that the new code is really correct (checks a signature and CRC-16) and then deletes the old code. It then copies the new code to its operating position before again checking its contents to ensure that there was no error during the copy. Only then will it delete the backup of the code so that it doesn't try to load it again at the next reset.
This means that it can always recover should there be a crash or power down at any part of the update process.

The uTasker demo project supports upload of the new code via FTP and HTTP Post method. Before the code is posted it is converted using a supplied utility so add a signature and the CRC-16 (this ensures that no malicious code can be uploaded since only the owner of the Boot SW knows the matching signature - configured on a project basis). It can optionally encrypt the code content so that it can be distributed in a form where the machine code can not be read and reverse engineered).

The only thing that can go wrong is if the developer distributes a new application code which then doesn't allow a subsequent update - for example the code is faulty and doesn't run or crashes when uploads are attempted - or in which the upload support has been removed or forgotten... But since this should only happen in a development environment (before a new release is really made) it is easily corrected by loading the correction using BDM.

The second major advantage of being able to upload complete project code is in the fact that all code can be upgraded, including the operating system and the TCP/IP stack. I remember when first starting out with the technique I found a bug which would cause uploads of files from a certain size to fail - I was testing uploads via the Internet and the test device was in another town. By compiling a stripped down project but still with the upload support via HTTP Post I could get the upload size small enough that it avoided the error. The new code had the correction in it so subsequently I could upload the complete project correctly. It did take a bit of time to realsie what was going on and checking the correction in the uTasker simulator before risking it but it was a good feeling to have been able to do a remote correction like that - it always makes me think of the Mars missions where hardware and software errors in the devices on the planet must somehow be overcome (although on a rather more modest scale...).

The next M5223X service pack includes the SPI FLASH based uploader support plus various other stuff is planned for the end of this week.

I couldn't get hold of any m25P40 so have only the AT45DB support at the moment. I didn't look at the difference but if I can get hold of a couple I hope to be able to add them to it for the next time. I wonder whether Freescale has an offering (seeing as it is used to update the code to a Freescale processor...)?

Regards

Mark



Offline Kremer

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: SW uploads to SPI FLASH
« Reply #3 on: August 22, 2007, 05:15:23 PM »

It then copies the new code to its operating position before again checking its contents to ensure that there was no error during the copy. Only then will it delete the backup of the code so that it doesn't try to load it again at the next reset.


 Hum, i don´t do a second checksum after flashing the internal coldfire flash. I think is better do it to be sure the code was correct copied from serial flash to internal flash. Nice!!! ;)
 I´m using CRC and some guardwords to ensure there is a valid code on serial flash, like you mentioned, but the transfer and serial flash contents are not encrypted like you did, so the serial flash holds the exact program image contents. Maybe i should modify it too.
 In my case, i developed a c++ program that opens a .bin file generated by the compiler i use (CW 6.4) and build the exact file image from this .bin file, wich isn´t the exact file image since it holds extra information including an address word and a block size word, for each code block in the file, so copying the exact .bin generated by codewarrior to internal flash doesn´t work. After doing it, the user can open an ethernet connection with the card and send the file image. It´s really fast.
 I think these extra information words were implemented to guide the flash programmer routine in codewarrior software. I don´t know if you know what i´m talking about, since i don´t know if you use codewarrior too. Anyway, now my product is pretty decent, so thanks for the help again.

 Regards

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: SW uploads to SPI FLASH
« Reply #4 on: August 22, 2007, 05:59:47 PM »
Hi Kremer

I am still using CW6.3 and the binary file can be copied directly - either there was a change in CW6.4 or there is an option in CW to activate extra information in the file - which I can't find in CW6.3.

There are details about the uTasker BM-boot loader on the documents page:
http://www.utasker.com/docs/uTasker/uTaskerBootLoader.PDF - general
http://www.utasker.com/docs/uTasker/BM-Booloader_for_M5223X.PDF - specific for M5223X

These need updating to include SPI FLASH and encryption.

I created also a converter called "uTaskerConvert.exe" and this takes the binary generated by CW6.3 and converts it to the downloadable file

Eg. bat file to do it
uTaskerConvert.exe uTasker_BM.elf.bin H_Upload.bin -0x1234 -a748b6531124

It takes the input file uTasker_BM.elf.bin and generates H_Upload.bin
It adds a magic number 0x1234 (can be used to ensure compatible project is being loaded) and signs the file with the signature a748b6531124 (length is adjustable)

When encryption is required, it is used like this
uTaskerConvert.exe uTasker_BM.elf.bin H_Upload.bin -0x1234 -a748b6531124 -7182721288ba5e71829f8092aab5 -18bb -12ae
7182721288ba5e71829f8092aab5, 18bb and 12ae are three parts to a user definable encryption key. When I update the boot loader documentation there will be more details about how the encryption operates and how the keys are used.

In all case the magic numbers and keys must match with the value compiled in the boot loader used for a particular project.

Regards

Mark

Offline Kremer

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: SW uploads to SPI FLASH
« Reply #5 on: August 23, 2007, 01:12:25 PM »
 Hi Mark

 Actually we bought a full standard license for codewarrior and we received the 6.4. So i had to remove the 6.3 to avoid any problem. When i had 6.3 installed, i just used the BDM to flash my devices, so i hadn´t worried about the .bin contents and never took a look on it.
 On 6.4, checking the Project Settings (Alt+F7), on Linker - Coldfire Linker tab, there is a checkbox to "Generate Binary File", wich i set to generate the .bin file wich i use to generate the file image (I´m sure there is this checkbox on 6.3). Also, on the right side of this tab there is a text box to set the "Max Bin Record Length", wich gives you the size of each record block i mentioned on the previous post.
 So, my first try (because my ignorance), was to flash the exact .bin generated by CW6.4. Well, it didn´t work, so i had to scratch this .bin file and my only clue was that _SP_INIT should be the first word on that file, and the word 0x00001008 should be right after it. For my surprise, there was 2 extra words on the first 2 positions. The word 0x00001000 and 0x000000FC, then the _SP_INIT and 0x00001008 words. So i realized the first extra word was the memory position and the second word was the exact number set on "Max Bin Record Length", and they were spread over the whole file. So after removing all those words and flashing the device, everything went smooth.
 I noticed some minor differences on 6.4 from 6.3 regarding the Flash Programmer, wich now seems to do some clock checking before do something else. But maybe there are "invisible" changes on it.
 I dont know, maybe those extra information on .bin file are only inserted if the .lcf file of the compiled project tell the linker the flash doesn´t start on 0x00000000 address. In my case, my bootloader project has a .lcf with a flash start address on that position, but my main application project has it´s lcf file setting the falsh start to 0x00001000.

MEMORY
{
    program    (RWX) : ORIGIN = 0x00001000,  LENGTH = 0x0003F000
    vector_ram (RW)  : ORIGIN = 0x20000000,  LENGTH = 0x00000400
    ram        (RW)  : ORIGIN = 0x20000400,  LENGTH = 0x00007C00
}


SECTIONS
{
    ___IPSBAR           = 0x40000000;

    ___SRAM             = 0x20000000;
    ___SRAM_SIZE        = (32 * 1024);

    ___FLASH            = 0x00001000;
    ___FLASH_SIZE       = (256 * 1024);

    ___VECTOR_RAM       = ___SRAM;

.............

 Regards


Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: SW uploads to SPI FLASH
« Reply #6 on: August 23, 2007, 04:36:53 PM »
Kremer

I don't have CW6.4 to verify but it is true that the CW6.3 also has the settings "Generate Binary Image" and "Max Bin record length" is set to 252 (0xfc).
However when I look at the content of the generate BIN file (project starting at 0x1000) it starts with

0x20008000   // stack pointer initialisation
0x00001008   // first program address
0x46fc2700   // move.w   #0x2700,sr (this is at 0x1008 on the target and is this the first program instruction)
etc.

MEMORY
{
    flash   (RX)   : ORIGIN = 0x0001000, LENGTH = 0x0003F000
    vectorram(RWX) : ORIGIN = 0x20000000, LENGTH = 0x00000400
    sram   (RWX)  : ORIGIN = 0x20000400, LENGTH = 0x00007C00       
    ipsbar  (RWX)  : ORIGIN = 0x40000000, LENGTH = 0x0
}

Therefore there are no blocks generated with my version/project. There are a number of people using the uTasker boot loader and I haven't heard of a problem with the conversion utility. Possibly no one is using CW6.4 or there is another explanation (?)

I think that Freescale may be the best to ask. If CW6.4 and CW6.3 prove to generate different binary files it will of course be quite a nuisance since the utility will somehow need to know which type it is to do the conversion correctly.

If you find out why it is happening please tell me!!!

Regards

Mark

Offline Kremer

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: SW uploads to SPI FLASH
« Reply #7 on: August 24, 2007, 02:53:28 AM »
 Hi Mark

 I'll try to figure out what's happening or whatever i did to generate this thing. For now take a look how it is on those jpg's.
 This is the raw bin image, wich contains the address word and the block size. This file is 127296 bytes long.



 And this is the exact file image with 123376 bytes long.


 Any news i'll post here.
 
Regards

Offline Kremer

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: SW uploads to SPI FLASH
« Reply #8 on: August 24, 2007, 06:58:45 PM »
 Hi Mark

 I opened a service request on freescale and indeed there are changes on the linker from 6.4 to previous versions. I requiered a software modification on codewarrior to include on project setting configuration a filed to revert the bin generation to the old fashion way. But for now, we have to live with that, and i think you´ll need to adapt your code to deal with it.  :'(

 Here is the freescaler´s answer:
"
In reply to your Service Request SR 1-380979511:

Basically the Codewarrior for Coldfire 6.4v is based on the same compiler/linker as 6.3 but with the bunch of bugs fixed from 6.3v including on it, you can read all the bugs fixed from 6.3 in your releases notes file, installed on your Codewarrior for Coldfire/ Releases notes directory.

The main issue concerning the raw images changes, and I think this apply to your case, is the generation of raw bin image, was fixed until the 6.4 build 1 is that CWCF6.3v; The linker generates a Bin file which follows a Motorola Standard; The differences are address and length fields in the Moto image. Changes of the linker were required, for CWCF6.4

Hope this helps

Thank you for your interest in Freescale Semiconductor products and for the opportunity to serve you.

"

 Regards

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: SW uploads to SPI FLASH
« Reply #9 on: August 24, 2007, 07:55:30 PM »
Hi Kremer

That seems to explain things.

Any yes, the converter will need to be able to do an intermediate conversion to the RAW binary. I think that I will add a flag which can be set in the bat file for anyone using CW6.4.
The same conversion utility is being used also for ARM processors (it is not processor specific) so this will make it flexible.

If any one using CW6.4 wants to use the BM-Boot loader please generate the code using CW and send me the file so that i can check that it works correctly. Thanks

Mark

Offline Kremer

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: SW uploads to SPI FLASH
« Reply #10 on: August 24, 2007, 09:14:15 PM »
 Since you don´t have the 6.4, do you need a .bin file generated by it? If you want it to start your workaround for this odd thing i can send a .bin file to you. Just give me your e mail.

 Regards

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: SW uploads to SPI FLASH
« Reply #11 on: August 24, 2007, 11:14:24 PM »
Hi

I received the file and have added the conversion ready for when it will some day be needed ...!

One thing to note is that the Motorola Binary format uses addressable binary blocks so it is theoretically possibe for there to be holes in it (that is holes between two blocks where there is no data specified). Therefore I have also respected this and filled these with 0xff if the do occur (there were no holes in the test file you sent me though).

This means that a Motorola Binary file with a few bytes of binary data at the address 0x0 and then more data at 0x100000 is small. The resulting RAW binary has to contain data between 0x0 and 0x100000 as well so will be much larger (this is also what happens with S-Recs etc. since they can also have data holes in them). This is therefore a possible advantage of the Motorola binary format.

Regards

Mark

Offline Kremer

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: SW uploads to SPI FLASH
« Reply #12 on: August 26, 2007, 04:46:00 PM »
 Hi Mark

 You are right assuming that is possible to have holes on it. To be honest, there are some thing´s that i still didn´t understand on this binary file.
 As an example, there are a bunch of 0x00000000 in the middle of my real application (not any example) wich i really don´t know what is. The strange fact is those sine and length words don´t appear in that 0 area and stop happening on the file before it. I think it is the .rodata area, but haven´t really worried about to decode it because i did my algorithm and it worked nice and since my goal isn´t to supply it to an end user, but for my field people wich will do the card installing, test and maintenance.
 But this week i´ll take a deep look into it and try to do a better job over it, but you know, there are many different points from project to project starting with memory configuration and on...
 Tomorrow i´ll send you the converted bin file that i didn´t sent with the raw bin on last mail, since i´m out of the office, thanks GOD :)

 Regards

Offline john_k

  • Newbie
  • *
  • Posts: 4
    • View Profile
Re: SW uploads to SPI FLASH
« Reply #13 on: February 18, 2011, 09:36:09 AM »
Hi Mark,
    I using the CW7.1 with the MCF52235 which I also facing the some problem with extra byte generate by the CW bin generate (0x00fc).
    When I using the utaskercombine (utasker_boot.bin + utasker_bm.bin) which the program can't work. Please advice anyway to solve this problem?
     Thanks.
      John

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: SW uploads to SPI FLASH
« Reply #14 on: February 18, 2011, 12:34:33 PM »
Hi John

Make sure that you have the latest uTaskerCombine.exe ("uTaskerCombine - v" shows the version number- the present version is V1.1).
This version is attached.

If this doesn't help some more information will be needed to help.

Regards

Mark