• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 592 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.

Differences in code execution as a result of HPI boot vs. load from debugger

Christian Lenz
Prodigy 50 points

DSP 320C6727B

Code loaded to SRAM (IRAM) only.

I am witnessing differences in code execution depending on how the same piece of code is loaded. The code in question is designed to run entirely from IRAM, uses McASPs and other interrupt services.

Two scenarios:

A) Code loaded via CCS & JTAG debugger. A GEL file is executed that does PLL and EMIF setup (no cache or interrupt setup happens) when loading the code. Code when loaded is halted at main() ready for execution. EIR at that point is 0x2. When executing, code spawns threads which enable various interrupts (EIR=0x132) and code runs as expected.

B) Code is loaded via HPI by a PPC440. .out file is converted to .bin and loaded via a custom loader on the PPC. Code executes but doesn't quite run as expected. When halted, EIR=0x0 or EIR=0x12 (the interrupts that are not enabled here but are in scenario A are related to the functionality that is not as expected). A stage 2 bootloader is put at then end of IRAM that takes over from the DSP built-in loader, initializes the PLL and then waits for the PPC to load the main program. Before loading the main program, the PPC sets up the EMIF registers via HPI after the stage 2 loader does PLL setup. The handover from the stage 2 loader to the main program is similar to how the internal loader does it but using an area of memory at the end of IRAM. Entry point for the loader is _c_int00.

The PPC loader loads all text and initialized data segments.

I have verified most of the text segments via the debugger and proven that the resulting memory image is the same in both scenarios A and B prior to execution.

DSP code is all C++. DSP interrupts are setup in C++ object constructors.

Help?

 

  • 0
    TI__Guru* 84110 points

    Christian Lenz,

    Welcome to the TI E2E forum. I hope you will find many good answers here and in the TI.com documents and in the TI Wiki Pages. Be sure to search those for helpful information and to browse for the questions others have asked on similar topics. I recommend doing that for this topic, searching for things like "C6727 HPI boot" or "C6727 boot failure", without the quotes; it may help to use the Advanced Search and put these in the "All these words" box. Try the Wiki, too.

    Christian Lenz said:
    I have verified most of the text segments via the debugger

    Why have you not verified all of the text segments? If you use a hardware breakpoint at _c_int00, you should be able to do a memory save to a file in text format of the whole program + data, and a comparison between the two cases should be identical other than the locations modified by the bootloaders.

    Christian Lenz said:
    DSP interrupts are setup in C++ object constructors.

    I have no idea what that means. It probably does not matter if the interrupts work right in either case.

    What is EIR? Is that supposed to be IER?

    Something is different between the two, so you have to figure it out. Since you have been looking into the differences in IRAM and believe they are the same, the other choice is the registers. That would mean that something is initialized differently between the GEL and the boot process. You can look at the EMIF registers and the PLL registers in both cases and see what is different, if anything.

    The hardware breakpoint at _c_int00 is the cleanest way to get emulation control at a point where everything should be identical before running much. Another alternative is to put a spin loop either in the _c_int00 code or at the top of main.

    You could also try simplifying the GEL file down to the minimum that is required for it to work, mainly in OnTargetConnect, OnReset, OnPreFileLoaded, and OnFileLoaded.

    Let us know what you try and what you find.

    Regards,
    RandyP

     

    If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

  • 0 in reply to RandyP
    Prodigy 50 points

    Randy

     

    Thanks for the reply. It stimulated more investigation and I believe I am now looking at the following issue:

     

    When i load through the debugger, I am loading a .out file. The loader knows how to deal with all sections properly, including .cinit.

    When loading via the PPC using HPI, I am loading a .bin file that is generated using the TI Boot Assist tool. My hypothesis is that .cinit is not properly handled in this case.

     

    A couple of questions from this:

    1) the .map file shows .text and .cinit in the same memory range. .text is contiguous but .cinit has holes. Excerpt:

    .cinit     0    10001c00    000033cc     COPY SECTION
                      10001c00    00002354     A.obj (.cinit)
                      10003f54    00000004     --HOLE--
                      10003f58    0000003c     B.obj (.cinit)
                      10003f94    00000004     --HOLE--
                      10003f98    0000006c     C.obj (.cinit)
                      10004004    00000004     --HOLE--
                      10004008    0000001c     D.obj (.cinit)

    .data      0    10001c00    00000000     UNINITIALIZED

    .text      0    10001c00    0001fc20    
                      10001c00    00002e00     cc.obj (.text)
                      10004a00    00001fe0     dd.obj (.text)
                      100069e0    00001760     ee.obj (.text)
                      10008140    00001760     ff.obj (.text)
                      100098a0    000014c0     gg.obj (.text)
                      1000ad60    00000f00     hh.obj (.text)

    Can you explain this and the meaning of COPY SECTION?

    2) The Boot Assist tool has the option of specifying to add the .cinit section at the end, following the first 0x00000000 terminator. See sprab60 figure 11. Can you explain the use of this section? Are these address/value pairs that need to be copied to RAM? Figure 11 says: .cinit section load address (4 bytes, useless) <- the "useless" word is confusing.

    3) More generally, how is run-time initialization supposed to happen using the "ram auto-init model"?

     

    Thanks

    CL

  • 0 in reply to Christian Lenz
    TI__Guru* 84110 points

    1) With HPI boot, please use the -c or --rom_model .

    COPY_SECTION is explained in the Assembly Language Tools User's Guide.

    2) You may read "useless" and "not used". This behavior will change when you switch to the --rom_model.

    3) The loader must handle this model type. This behavior will change when you switch to the --rom_model.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Prodigy 50 points

    Apologies for further questions:

     

    re. 1) is --rom_model mandatory or just a better answer? In rom_model it seems to use more memory and that is a problem in our case

    re. 3) Do you mean is we use ram_model, that the loader has to then do the initialization using data in .cinit? If so, what is the format of the .cinit section? IOW what does that process look like (thus my question of address/value pairs)?

  • 0 in reply to Christian Lenz
    Prodigy 50 points

    I have found the answer to my question 3) in spru187t, section 7.8.5.

     

    Further question on this which is not clear from the text above: does .pinit also have to be dealt with by the HPI loader (in which case that's not really possible, is it?) or is it just .cinit and the rest is done at run time?

  • 0 in reply to Christian Lenz
    Prodigy 50 points

    One additional question:

     

    The format definition in spru187t section 7.8.5 specifies a .cinit record as: Length, .bss address, value

    What types are assumed for length, bss address, and value?

    Also, is the bss address absolute in memory or relative to the start of bss?

  • 0 in reply to Christian Lenz
    TI__Guru* 84110 points

     

    If you want to use the tools we offer, then use --rom_model. If you want to write your own loader, then you can do it any way you want to do it. The .cinit and .pinit sections are used only during the load process, unless you want to be able to do a soft reset by branching to _c_int00.

    If you have a .pinit section, the I would imagine your own loader would have to handle it. Why would that be more difficult than handling the .cinit section? Since you are using C++, the .pinit section will exist.

    --rom_model is by far the easiest solution.

    Christian Lenz said:

    What types are assumed for length, bss address, and value?

    Also, is the bss address absolute in memory or relative to the start of bss?

    To be honest, these questions need to go to the Compiler Forum. They will be more likely to know the specifics for these. I still recommend you use the --rom_model so you do not have to worry about it.

    Regards,
    RandyP