Create Account
Search
You are here: TDG Forum  >>  NXP SOMs and Development Kits  >>  LH7A404 Card Engine and Development Kit  >>   Run an application without using bootloader?

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 Oct 2007 10:05 AM by  mikee@logicpd.com
Run an application without using bootloader?
 7 Replies
Sort:
You are not authorized to post a reply.
Author Messages
Dag
New Member
New Member
Posts:


--
05 Sep 2007 05:04 AM
    Hi everybody,
    I modifed the led_flasher sample application to do something more than just flashing a led and this works fine, both when I compile it for RAM and for flash memory. For some test purposes I want to run this application without first starting the bootloader. I therefor changed the CONFIG_APP_OFFSET variable in the makefile from 0x00100000 to 0x00000000. I load and burn the elf-file (I use Multi-ICE to restore the bootloader later), but the application does not start. Can anybody tell me what I need to do to just start the original sample application directly after reset without having the bootloader in the flash?
    Dag
    ashwinb@logicpd.com
    New Member
    New Member
    Posts:


    --
    05 Sep 2007 07:44 AM
    Dag,

    In general any Bootloader does some CPU/Memory/peripheral setup that is necessary to make things function. So if you were to want your application to be run at the reset vector, you'd have to replicate this setup procedure in your application.

    So unless there's a real reason for it, you're better of just having a boot script stored in /dev/serial_eeprom that will start your application as the first thing after boot-up.

    Regards
    Dag
    New Member
    New Member
    Posts:


    --
    05 Sep 2007 07:55 AM
    I am trying to figure out why the bootloader does not always start or if it only starts partly on some of our CPU boards. Therefor I want to have a tiny application to start to check if this has the same problem as when running with the bootloader.

    Dag
    ashwinb@logicpd.com
    New Member
    New Member
    Posts:


    --
    05 Sep 2007 12:26 PM
    Dag,

    Are you using LogicLoader on the boards, or a different boot loader? If LoLo, can you get the version.

    Regards
    Dag
    New Member
    New Member
    Posts:


    --
    06 Sep 2007 12:17 AM
    We use LoLo in our final product. We have used V2.0.4, V2.0.5 and V2.0.6. We have also briefly tried V2.3.3, but we have not released our product with this version yet.
    Dag
    ashwinb@logicpd.com
    New Member
    New Member
    Posts:


    --
    06 Sep 2007 05:54 AM
    Dag,

    Are you seeing the issue of the bootloader not loading on power-up or processor/soft resets?
    Dag
    New Member
    New Member
    Posts:


    --
    06 Sep 2007 07:51 AM
    We usen a bootscript with a "VOLO..." command and normally when we prevent the bootscript from running by holding down the "q"-key from TeraTerm we can use the LoLo command from TeraTerm. (The script also sends information to the screen during a normal boot without the "q"-key.) On the unit that fails nothing is shown in TeraTerm at all. It does not matter how we do the reset. Same result when we unplug power and starts from scratch as when we use the reset button.
    Dag
    mikee@logicpd.com
    New Member
    New Member
    Posts:


    --
    06 Oct 2007 10:05 AM
    Dag,

    It almost sounds like LoLo is getting corrupted on these units. Have you tried probing the boot block of flash with a JTAG to checksum the memory in some way?

    I guess I would start by taking a good and bad unit that both started off working. Then connect a JTAG and dump the contents of the flash memory that contains LoLo into a couple of files. Then MD5SUM or run some other comparison to see if they are the same.

    If they aren't, then I imagine that somehow LoLo wasn't programmed correctly - or was somehow corrupted during run time.

    --mikee
    You are not authorized to post a reply.

    Forums NXP SOMs and Development Kits LH7A404 Card Engine and Development Kit