Search

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 06 Dec 2005 11:05 AM by  Anonymous
Using Burn to Flash in LoLo
 17 Replies
Sort:
You are not authorized to post a reply.
Author Messages

pdrosihn



New Member


Posts:
New Member


--
08 Nov 2004 03:11 PM
    Is there an apps note/ some examples for burning the example programs to flash using the BURN command in LoLo?
    Tried modifying the linker scripts to Flash and Block 2.
    Compiles/links OK but will not download the resulant ELF to ram.
    am i missing something?

    mikee@logicpd.com



    New Member


    Posts:
    New Member


    --
    09 Nov 2004 01:51 PM
    What is the error you are seeing?

    --mikee

    pdrosihn



    New Member


    Posts:
    New Member


    --
    10 Nov 2004 02:43 AM
    I Talked to Aaron and he gave me some useful info.
    Now able to compile and Burn to flash but still won't run (the original SRAM version works fine). I am a little confused about how setting the virtual memory to Flash allows it to be run out of RAM (even though you copy the program to RAM in the code, how do the variables and code re-address themselves to the RAM area?).


    What would be reallly very useful would be if you could convert one of your example demos for the SDK, the SWIM would be best, so that it can be burned to Flash and run. Then send it to me/ post as a download.

    This would give SDK users to have a known good start point for FLASH and RAM based versions of the same project.

    Could cut down on the number of overwritten BOLO/LOLO calls you get?

    regards,

    Paul

    mikee@logicpd.com



    New Member


    Posts:
    New Member


    --
    10 Nov 2004 11:06 AM
    pdrosihn,

    I'm not sure what you mean by:

    Quote:

    What would be reallly very useful would be if you could convert one of your example demos for the SDK, the SWIM would be best, so that it can be burned to Flash and run. Then send it to me/ post as a download.


    mainly because I don't know what SWIM refers to.

    However, I will try and explain what is happening when you adjust the virtual addresses of the ELF file.

    The first thing you need to understand is how the LogicLoader loads a file. To properly load and run an ELF formatted executable, LoLo performs the following steps:

      - Looks at the program's start address.
      - Based on that address, determines if the program is going to start execution from flash or RAM.

        If the program's start address is in RAM:

          For each section in the ELF file:

            - Remove the section header.
            - Copy the section's data to its proper location in RAM.


        If the program's start address is in flash:

          For each section in the ELF file:

            - Remove the section header.
            - Adjust the starting address of the section to some place in RAM.
            - Copy the section's data to this location in RAM.

    The end result of the above steps is that your program is now a raw binary image sitting someplace in the system's RAM. It has been stripped of any and all ELF file format headers. It has also been stripped of any debug symbols or other unecessary information. Therefore, it is a snapshot of how the program looks when it is executing in memory.

    The second thing you need to understand is why the LogicLoader needs to copy a flash image into RAM first. The reason this is necessary is that programming flash memory is inherently slow. Flash memory needs to be unlocked and erased before programming. Unlocking and erasing blocks of flash takes time. The time it takes is so long that the LogicLoader would drop bytes coming in over the serial port while it was trying to do this, thus corrupting your program image. That is why you need to use a seperate burn command after loading a program destined for flash memory.

    The third thing you need to understand is that NOR flash devices (such as the ones on our SDK kits) are capable of what is known as eXecute In Place (XIP). This means that programs can execute directly out of the flash device. This is as oppossed to needing to be loaded into RAM by some other program (like an operating system), or copying themselves into RAM (like our little sample application does). Because of this feature of NOR Flash, the LogicLoader doesn't make any assumptions about the program you just burned into flash. It doesn't care what this program does, or where it executes from (does it copy itself out to RAM, or eXecute In Place from the flash). The LogicLoader just knows that the starting address of the program was in Flash, so it "cached" it into RAM first and then let the user decide if he/she wants to burn it into flash or not.

    Finally, we get to your original question concerning what happens when we adjust the virtual addresses in the ELF file. Our sample application is linked to execute out of RAM. But, we don't want to download it each and every time we want to run it, so we actually want to store it in flash. So, to do this, we need to accomplish two things:

      - Write startup code that will relocate our program from flash to RAM so that the branches will work.
      - Fake out the LogicLoader so that it thinks that our program is going to start in flash.


    To do this, we adjust the virtual addresses within the ELF file.

    This does not change the way the program was linked. For instance, if the address of function foo() gets linked to 0xC0008000 and main() calls foo(), that instruction is still going to branch to the address 0xC0008000. Therefore, the code for foo() had better be existing at 0xC0008000. That is what the startup code does. It copies the code out of flash memory into RAM so it is re-located to its proper runtime location.

    This does change the start address within the ELF file's header. Thus, when LoLo loads the ELF file, it will look at the start address and assume that this program is going to start in flash.

    The reason this all works is that the startup code contains no branches. Thus, if LoLo burns the program into flash, the program can safely run through the entire assembly language startup() function without trouble. However, the relocation needs to happen before startup jumps to main(). This is because main() is going to be located at some RAM address, because that is how we linked and located the file.

    Summary:

      - The sample program is linked to run from RAM. So all addresses in the program (such as the addresses of functions, or global variables) will point to someplace in RAM.
      - We adjust the start address reported in the ELF header to point to someplace in flash.
      - LogicLoader reads the adjusted start address and determines that this is a flash address.
      - LogicLoader "caches" the program in stripped binary form someplace in RAM.
      - LogicLoader lets you burn this program into flash.
      - When you start this program, you jump to its first instruction which has been burned into flash.
      - Before the program accesses any global variables, or calls any functions, it copies its code and data sections into RAM.
      - When the program jumps to main() it is actually jumping to an address in RAM.
      - It can do the above because it copied all of the code for main() (and all other functions) into RAM before it jumped there.


    Hope this helps,
    --mikee

    Krispin Leydon



    New Member


    Posts:
    New Member


    --
    01 Dec 2005 06:41 PM
    Posted By pdrosihn on 10 Nov 2004 2:43 AM


    What would be reallly very useful would be if you could convert one of your example demos for the SDK, the SWIM would be best, so that it can be burned to Flash and run. Then send it to me/ post as a download.

    This would give SDK users to have a known good start point for FLASH and RAM based versions of the same project.





    I agree - this would be really, really useful!! (Swim is a standard demo from sharp).

    -Krispin

    mikee@logicpd.com



    New Member


    Posts:
    New Member


    --
    02 Dec 2005 07:56 AM
    Krispin,

    Are you wanting to execute in place out of flash, or simply store the program in flash and then have it run out of RAM?

    If the latter, just copy the program onto a YAFFS partition in its native ELF file format. Then have LogicLoader load it from there.

    Check the LogicLoader User Manual for complete details of how to create and use a YAFFS partition.

    --mikee

    Krispin Leydon



    New Member


    Posts:
    New Member


    --
    02 Dec 2005 08:53 AM
    Posted By mikee on 2 Dec 2005 7:56 AM
    Krispin,

    Are you wanting to execute in place out of flash, or simply store the program in flash and then have it run out of RAM?

    If the latter, just copy the program onto a YAFFS partition in its native ELF file format. Then have LogicLoader load it from there.

    Check the LogicLoader User Manual for complete details of how to create and use a YAFFS partition.

    --mikee




    Hi Mike,

    I'd actually like to know how to do both; the former for immediate testing, the latter for later use.

    I just checked the most recent Logic Loader User Manual, and there is no mention of YAFFS partitions or how to create them; is there another document you would recommend consulting?

    Additionally, if I'm trying to run the program in place from Flash - what would I need to do (aside from adjusting the base address)?

    Thanks for your help!

    -Krispin

    mikee@logicpd.com



    New Member


    Posts:
    New Member


    --
    02 Dec 2005 10:06 AM
    Actually, I didn't look closely enough at which group I was in. The 75401 is fixed at a LoLo version prior to 2.0. Therefore, it doesn't have any of the YAFFS support. Sorry for the confusion.

    You will have to do this by hand.

    To run the program from Flash, just adjust your linker script. If you look at the sample programs that come on the Zoom SDK CD, you should be able to figure out how to do both.

    What tools are you using?

    Krispin Leydon



    New Member


    Posts:
    New Member


    --
    02 Dec 2005 11:12 AM
    Posted By mikee on 2 Dec 2005 7:56 AM


    To run the program from Flash, just adjust your linker script.

    What tools are you using?




    I've tried this; in the linker script for RAM ("sdk75401_swim_gnu_ram.ld" for gnu), I changed the address from RAM to flash (from . = 0x48040000; to . = 0x40080000;), then changed the file name to "sdk75401_swim_gnu_rom.ld" so that the linker can find the script when the project is made for flash. The code compiles, links and loads, but doesn't run (when I do "load elf", "burn" and "jump" in the Tera Term window).

    Next I tried creating an additional section in the linker script, a RAM section for the code that people at Sharp thought should remain in RAM. (I did this by inserting the RAM address ". = 0x48040000;" right before the script's line ".lr_sram :"). This compiles and links, but won't load. (I get an error in the terminal window: "F.mh data is incorrect for > 1 program header(!)").

    I keep looking through the one example app that came with the LogicPD SDK, but have yet to find clues about what else to try...

    If you have any ideas about what I could try next, I'd love to hear them!

    Thanks,

    Krispin

    mikee@logicpd.com



    New Member


    Posts:
    New Member


    --
    02 Dec 2005 11:28 AM
    Okay, lets get a little more information about what is going on here. To be honest, I will do my best to help you, but as I don't actually have the SWIM application, nor did I write it, so I'm working a bit in the dark here.

    Please send me some output. Specifically, do a screen capture of LoLo downloading and burning the file. Also, send me the output of the readelf command on your file. Lets make sure that it is going where we think it is going.

    Chances are, LoLo is putting it exactly where it is supposed to be and jumping to it correctly. By the way, you should use the 'exec' command to launch it. 'Jump' will leave LoLo running in the background which is probably not what you want.

    --mikee

    Krispin Leydon



    New Member


    Posts:
    New Member


    --
    02 Dec 2005 12:18 PM
    Hi,

    Quote:

    Please send me some output. Specifically, do a screen capture of LoLo downloading and burning the file. Also, send me the output of the readelf command on your file. Lets make sure that it is going where we think it is going.


    Sure thing! Here they are:

    downloading/burning: http://www.krispinleydon.net/tesla/lolo_download_burn.jpg

    readelf output: http://www.krispinleydon.net/tesla/lolo_readelf.jpg

    If you have any ideas about where the trouble is, I'd love to hear them.

    Thanks,

    -Krispin

    mikee@logicpd.com



    New Member


    Posts:
    New Member


    --
    02 Dec 2005 04:21 PM
    Okay, that looks fine to me. It seems like LoLo knows that this image is going to flash and stores it there appropriately.

    Check the MD5SUM to ensure the image is loaded correctly. LoLo only loads the executable parts of the program, so to check it, do something like:

    - arm-elf-objcopy -O binary swim.elf swim.raw
    - md5sum swim.raw

    The output should match what LoLo prints out.

    Barring some sort of file corruption, I would say that something is wrong with the actual program. You most likely need to go into the startup code of the swim demonstration and add some code to tweak an LED or spit something out of the serial port to see what is going on.

    Beyond that, you will most likely need to talk directly to Sharp as it is their software.

    Please let me know if the MD5SUMs don't match.

    --mikee

    mikee@logicpd.com



    New Member


    Posts:
    New Member


    --
    02 Dec 2005 04:22 PM
    One more thing, do you have all of the latest versions of LoLo and the CPLD code installed??

    --mikee

    Krispin Leydon



    New Member


    Posts:
    New Member


    --
    02 Dec 2005 06:02 PM
    Posted By mikee on 2 Dec 2005 7:56 AM
    One more thing, do you have all of the latest versions of LoLo and the CPLD code installed??
    --mikee




    The latest versions are installed, and the md5sums do match. I'll dig into the startup code.

    Thanks for your help,

    -Krispin

    mikee@logicpd.com



    New Member


    Posts:
    New Member


    --
    05 Dec 2005 11:04 AM
    Probably the quickest/easiest thing to do would be to modify the startup code to just sit in an infinite loop and spit something out the serial port. LoLo will already have the serial port set up correctly, so just continuously shoving a character into the transmit register should work.

    Let me know how it goes.

    --mikee

    Krispin Leydon



    New Member


    Posts:
    New Member


    --
    05 Dec 2005 09:02 PM
    Posted By mikee on 5 Dec 2005 11:4 AM
    Probably the quickest/easiest thing to do would be to modify the startup code to just sit in an infinite loop and spit something out the serial port. LoLo will already have the serial port set up correctly, so just continuously shoving a character into the transmit register should work.

    Let me know how it goes.

    --mikee




    Thanks - thats a good idea!

    The folks at Sharp have suggested trying to load the file as an "srec" as a temporary work-around (suposedly this works on their end), and I'd like to look into this as well... Any recommendations re: converting from .elf to .srec? I've been attempting to use arm-elf-objcopy, but have not yet managed to create a loadable file. Supposedly there are at least 7 different srec formats... Which of these does LoLo accept?

    Thanks again,

    -Krispin

    mikee@logicpd.com



    New Member


    Posts:
    New Member


    --
    05 Dec 2005 09:43 PM
    I think you might be confusing the types of S-record fields in an S-record file. There are nine (I think) of those. However, to my knowledge, there is only one format for S-record files.

    Check these links for more information:



    Regardless, LoLo should understand any S-record generated by the GNU tools. I say "should" because this is probably the most infrequently format used for the LogicLoader. Therefore, it is quite possible that we've overlooked something.

    Why don't you try to link a RAM-ELF image first. Double check that it loads and runs correctly (just to make sure you haven't left some sort of cruft in your linker script). Assuming that loads and runs as expected, convert it from an ELF file to S-record format using objcopy. The command should look something like:

    arm-elf-objcopy -O srec swim.elf swim.srec

    Then try loading the newly created S-record file via LoLo and starting it. You should find that it downloads and runs correctly. Then, you can go back to trying to build a flash image.

    --mikee

    Anonymous





    Posts:


    --
    06 Dec 2005 11:05 AM
    Hi Krispin,

    I'm coming to this conversation a bit late but I thought I'd chime in.

    Have you tried the Sample Application that is posted to the downloads page?

    http://www.logicpd.com/do...mple_Application.zip

    It is a trivial hello world app that can be linked for flash or RAM.

    Thanks,
    You are not authorized to post a reply.