• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 97 subscribers
  • Views 1134 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP-L137 / C6747 Secondary Boot Loader

Dan Lukas
Intellectual 750 points
Other Parts Discussed in Thread: OMAP-L137

I am having problems developing a secondary boot-loader for the OMAP-L137 / C6747 processors.

 

I have written the secondary boot-loader to:

  1. Initialize the DSP (PLL, Pin-Mux, PSC’s, EMIFA, EMIFB, ect.)
  2. Initialize the UART (for debug purposes).
  3. Read the state of a multi-position hardware switch (that is on my board). Based on the state of this switch, the boot-loader will load one of several applications from Flash into system memory.
  4. It will then jump to the entry-point of that program to run it.

 

The applications are stored in the Flash in AIS file-format. The boot-loader knows were in flash each application should be located. It searches for the magic number then parses for section-load commands. It loads all sections into the correct memory locations, and then verifies the data by double-checking it with flash. It then gets the entry-point of the application from the Jump-Close command and starts running the application.

 

The secondary boot-loader runs in Shared-RAM (0x80000000). The problem that I am having is that this all works correctly if I load the application to EMIFA-SDRAM or if I load it to unused memory in Shared-RAM but, it is not reliable if I load it into DSP-RAM (0x11800000 or 0x00800000). One of the applications that I need to run is a small program that must run entirely in fast DSP-RAM.

 

 

Symptom:

Upon application of power, the secondary boot-loader will run correctly but when it makes the jump to the application (in DSP-RAM) it will either:

  1. Wind-up in never-land (trying to execute code where there is no memory).
  2. Or it will re-run the boot-loader (as if a reset was hit).

 

The interesting thing is that usually, after running the boot-loader the second time, it will jump to the entry-point correctly and the application will run fine. Once it is in this state, you can perform a warm-reset (hit the reset-button with power-on) and the boot-loader will make the jump to the application in DSP-RAM every time without a problem. It is as if running the boot-loader a second time sets a register that allows the system to boot correctly until it is powered down.

 

There is one more interesting symptom. In the secondary boot-loader, if I initialize an area of DSP_RAM (load it with zero or DEADBEEF), loading the application there will always cause the system to hang. For example, if I initialize 0x00800000 to 0x00820000, I can’t load and run my application there without it hanging every time. If I run the application in memory above this, it will work as I described before running the boot-loader twice.

 

  • 0
    Guru 26430 points

    By secondary boot-loader, do you mean the DSPUBL or ARMUBL. The pre-built UBLs both use L3 128KB shared RAM. I have replaced the DSPUBL with a bare-metal app that used the DSP L2 256KB RAM. Not problems so far. Are you using the TI supplied UBLs as a base for your code?

  • 0 in reply to Norman Wong
    Intellectual 750 points

    Norman, thanks for helping me with this problem.

    This is a DSP-UBL.

    I started working on this feature a while ago on the OMAP-L137 Evaluation Board. I had this same problem but needed to continue with my design and get circuit-boards released.  I am running my circuit design now and I still have this problem.

    I started with the UBL example. My goal was to write a UBL that would read a DIP-switch and run one of two different application programs. So I compiled the UBL to run in L3-Shared-RAM. And the applications are compiled to run in L2-DSP-RAM. The UBL is burnt into the boot area of flash (starting at address 0x0000). Applications 1 & 2 are burnt into other areas of Flash-memory.

    To duplicate my problem, your UBL will need to run in L3-Shared RAM and load / run an application in L2-DSP RAM.

    Watch the output of the UART as the UBL runs. When the board powers up, the UBL will run and when it makes the jump to your bare-metal app, the UBL will run a second time (you may have to add some delays because this happens fast). This will not occur if you hit the reset button.

    The real problem comes when you rigorously test the system. If you power the system up 10 or 20 times, every so often it will hang when is tries to jump to the application in L2-RAM. If you compile the app for SDRAM or L3-Shared RAM it will run fine.

  • 0 in reply to Dan Lukas
    Guru 26430 points

    Sorry, I'm not in position to try out your suggestion at the moment. My HW as left my desk. No time.

    Not sure if I can help. Just to clarify for others. Your DSPUBL will load an application and vector off. Are your apps for the DSP? Are you using the ARM at all? From what I can see from the UBLs is that the exception vectors are not initialized. I suspect that an exception has occurred and the ROM bootloader exception handler has taken over.

  • 0 in reply to Norman Wong
    Intellectual 750 points

    Norman,

    I am not using the ARM at all. My final design will use the C6747.

     What you are saying sounds very possible. I will start reading-up on exception vectors. Could you point me in a direction to find an example on initializing exception vectors?

     Thanks.

  • 0 in reply to Dan Lukas
    Guru 26430 points

    Embarassed to say you've reached the limit of my knowledge. My base-metal app was based upon the StarterWare code for the C6748. That code came with a interrupt vector setup. The StarterWare code sets the ISTP register to point to the a table in RAM.

    I can't think why L2 RAM would cause an exception and L3 RAM woud not. Assuming that an exception is occurring at all. Maybe try JTAG debugging to see if you catch the exact moment it goes bad. A thing to watch for with JTAG debugging is to move all you GEL script code into real code. Ensures debug and standalone runs are comparable.

  • 0 in reply to Norman Wong
    Intellectual 750 points

    I did spend some time with the debugger and it turned up something rather strange. I'm not sure if it was a debugger limitation or it points to my actual problem.

    In my first email I mentioned that "if I initialize an area of DSP_RAM (load it with zero or DEADBEEF), loading the application there will always cause the system to hang".

    To clarify this a bit, if the UBL initializes all L2-RAM to zeros. It then loads the app into L2-RAM and vectors there. The debugger will show this area of L2-RAM as zeros (NOPs) but a CCS memory window shows the correct application code in those same memory location. Is this a memory protection problem or a user level problem? Both MPUs are set for ASSUME_IS_ALLOWED.

  • 0 in reply to Dan Lukas
    Intellectual 750 points

    I am going to re-visit this and send you a screen-shot (JPG).

  • 0 in reply to Dan Lukas
    Intellectual 750 points

    OK, this is what I get if I run the UBL in debugger. This is a UBL that first sets all L2-RAM locations to "0xDEADBEEF" then later copies the application into L2-RAM. The app entry-point is 0x0080C300. Notice that the disassembler shows the L2-RAM as "0xDEADBEEF" while the memory window shows the correct application code values.I am thinking that this is somehow pointing to the source of my problem. The application has been correctly copied into L2-RAM but after the jump, the state of the processor sees what I am seeing in the disassembler window. 

  • 0 in reply to Dan Lukas
    Guru 26430 points

    Might be CCS IDE bug. The two windows are unsync'ed or not refreshed? Maybe add some code to verify the copy or test for 0xDEADBEEF. My examples do not touch the L2 config registers. Which I think means that L2 RAM is not used as cache. That's all I got.

  • 0 in reply to Norman Wong
    Intellectual 750 points

    That is true. The L137 and C6747 power up with L2 set as RAM not cache so there is no need to touch config registers.

    My UBL does verify memory after copying the Application from Flash to L2-RAM so I know the memory window is correct (as far as what is in L2-RAM). However, the disassembler window seems to be showing exactly what the processor is executing (even when I don't step through in debug mode).

    Quite perplexing.