Reply by karthikbg February 1, 20072007-02-01
> Why are you debugging the BootROM? It's ROM and therefore cannot be > changed so I don't understand why you'd be "debugging" it.
My Boot ROM can be fused through my Flash Programmer/Burner into a particular Block of Flash Memory. So, it can be programmed/changed and flashed into Flash Memory using my Flash Programmer/Flash Burner utility that will be running from RAM. BootROM will get executed on Reset. (I am not talking about TI's Boot Code here).
> > Furthermore, you mentioned that the BootROM worked perfectly and > transferred your secondary bootloader from flash into RAM. > > So what is the problem that you're trying to find?
Yes, BootROM is working perfectly. Yes, It is copying the Bootloader into RAM perfectly. The Problem is - The Bootloader uses the SRAM contents and validates for certain versioning . Based on the validation output, it will be copying one of the 2 applications to RAM from Flash Memory. But, those SRAM contents get corrupted . So, my Bootloader copies the same application from Flash to RAM for all scenarios. So, i need to check if there is something happening at the point the Boot ROM gives control to the BootLoader. So, i need to debug these stuffs. In the same manner , i need to analyse if there is some data corruption while the Bootloader(Secondary Bootloader) is handling the control to the Application as some Memory Contents that are to be used by the Application appear corrupted.
> You're talking about so many things I can't figure out what you're > having the problem with. Is your problem that you cannot set a > breakpoint inside your secondary bootloader in order to debug it? If > that's the case you need to use a hardware breakpoint. You can do that > by going to Debug->Breakpoints and making sure the type is "H/W > Breakpoint". The reason you need a hardware breakpoint is because a > software breakpoint works by writing a special opcode into the RAM. > When the BootROM runs and copies in your code it will blow away that > special opcode and hence you won't halt. If you put a hardware > breakpoint there you should be able to debug your secondary bootloader.
Fine, I will Try this 'Hardware Breakpoint' . While trying to Look into the Hardware breakpoint, I got interesting info . Pls find it below : " When debugging code where instructions are copied (Scatterloading), modified or the processor MMU remaps areas of memory, HW breakpoints should be used. In these scenarios SW breakpoints are unreliable as they may be either lost or overwritten. "
> I don't have any answers for you regarding the debug of two applications > simultaneously. In general this should not need to be done. You should > be able to debug the bootloader independent from the application.
It is possible to do simultaneious debugging and it is achievable. I believe that if the Program Memory Contents of 2 applications reside together in RAM. Then it is possible to do that. (That is - there should not be clash in Memory Allocations for these 2 applications using Linker Command Files / Linker Scripts . These independent Linker Scripts should be designed in that manner to avoid Memory Overlapping ). The symbol information of both the applications can be loaded . (There will not be any overwritting of symbol information by one project over the other !! ) Data Memory (Heap, Stack ) are the areas of concern. But, i think, these will not get corrupted. Because, these are spaces that are used completely by Bootloader(Project 1) first, then these will completely used by application later( Project 2). Unless , the application does not switch back to the Bootloader , these Data Memory (Stack, Heap) will not get corrupted. So, It is possible. What do you think ? Any other ideas ? Kindly let me know. Thx in advans, Karthik Balaguru
Reply by Brad Griffis January 31, 20072007-01-31
karthikbg wrote:
> Hi, > > The Boot ROM has the basic intialisaton stuffs and is copying the > Bootloader from the Flash to RAM , then it invokes the Bootloader > that > will run in RAM.(Transferring control to the Entry point of > Bootloader). The Bootloader copies > my MainApplication from Flash to RAM and invoke the MainApplication in > RAM. (Transferring control to the Entry Point of MainApplication). > All the above operations are working perfectly. > > But, If i debug the BootROM , i am unable to trace/debug the Exact > point at which it handles the control to the Bootloader as both are > separate projects.
Why are you debugging the BootROM? It's ROM and therefore cannot be changed so I don't understand why you'd be "debugging" it. Furthermore, you mentioned that the BootROM worked perfectly and transferred your secondary bootloader from flash into RAM. So what is the problem that you're trying to find?
> In Reality, the BootROM calls the Bootloader and > Bootloader is getting executed succesffuly. But, While debugging, As > soon as the control moves from BootROM to Bootloader , i am unable to > place breakpoints and debug the flow of Bootloader. In the same > manner, if i place breakpoints and debug the bootloader, i am unable > to get control over the MainApplication as these both are separate > projects.
You're talking about so many things I can't figure out what you're having the problem with. Is your problem that you cannot set a breakpoint inside your secondary bootloader in order to debug it? If that's the case you need to use a hardware breakpoint. You can do that by going to Debug->Breakpoints and making sure the type is "H/W Breakpoint". The reason you need a hardware breakpoint is because a software breakpoint works by writing a special opcode into the RAM. When the BootROM runs and copies in your code it will blow away that special opcode and hence you won't halt. If you put a hardware breakpoint there you should be able to debug your secondary bootloader.
> I had the below thoughts, but there are other interesting issues/ > problems that i have stated below : > 1) The Makefile should be properly generating the symbols info of all > the projects. (.out should > be proper with debug / symbol information) . This is done. > 2) The symbols of other project(Project to which control should be > transferred) should be > present at the time of handing the control from one project to > another project. > (This can be done by adding the symbols via 'Add Symbols' option > in CCS. But care should > be taken that the symbol of Project 1 should not be getting > overwritten with Project 2 to > have control over debugger.) > > Issues : > But, here also, there is a scenario like, 2 applications using the > same Memory Areas (Data > Memory Section.) So, I think In that case, the first project's > symbols will > get overwritten with the next project's symbols that are loaded > after loading the first project's > symbols . > > Actually, the first project invokes the second project and after > that control does not return > back to the first Project. > So, i have to place a breakpoint in the first project exactly at > the place it calls the second > project. At that point of time(while the debugger stops at the > Breakpoint where the second > project is being called ), i may need to load the symbols of the > second project . But, i > suspect even now that the symbols of the Second Project may corrupt > the First Project's > symbols as it must be in memory at the point of transferring > control to Second Project . > And this is the Problem now . What could be the solution ? > > Any other ideas for resolving this issue of Debugging Multiple > Projects ? I do not find any > info with respect to debugging Multiple Projects in CCS (Code Composer > Studio). > I use CCS and XDS510-USB for OMAP. > > Could someone here help me in resolving this issue ? > > Thx in advans, > Karthik Balaguru >
I don't have any answers for you regarding the debug of two applications simultaneously. In general this should not need to be done. You should be able to debug the bootloader independent from the application.
Reply by karthikbg January 31, 20072007-01-31
Hi,

The Boot ROM has the basic intialisaton stuffs and is copying the
Bootloader from the Flash to RAM , then it invokes the Bootloader
that
will run in RAM.(Transferring control to the Entry point of
Bootloader). The Bootloader copies
my MainApplication from Flash to RAM and invoke the MainApplication in
RAM. (Transferring control to the Entry Point of MainApplication).
All the above operations are working perfectly.

But, If i debug the BootROM , i am unable to trace/debug the Exact
point at which it handles the control to the Bootloader as both are
separate projects. In Reality, the BootROM calls the Bootloader   and
Bootloader is getting executed succesffuly. But, While debugging, As
soon as the control moves from BootROM to Bootloader , i am unable to
place breakpoints and debug the flow of  Bootloader.  In the same
manner, if i place breakpoints and debug the bootloader, i am unable
to get control over the MainApplication as these both are separate
projects.

I had the below thoughts, but there are other interesting issues/
problems that i have stated below :
1) The Makefile should be properly generating the symbols info of all
the projects. (.out should
    be proper with debug / symbol information) . This is done.
2) The symbols of other project(Project to which control should be
transferred) should be
    present at the time of handing the control from one project to
another project.
    (This can be done by adding the symbols via 'Add Symbols' option
in CCS. But care should
     be taken that the symbol of Project 1 should not be getting
overwritten  with Project 2 to
    have control over debugger.)

Issues :
    But, here also, there is a scenario like, 2 applications using the
same Memory Areas (Data
    Memory Section.) So, I think In that case, the first project's
symbols will
    get overwritten with the next project's symbols that are loaded
after loading the first project's
    symbols .

   Actually, the first project invokes the second project and after
that control does not return
   back to the first Project.
   So, i have to place a breakpoint in the first project exactly at
the place it calls the second
   project. At that point of time(while the debugger stops at the
Breakpoint where the second
   project is being called ), i may need to load the symbols of the
second project . But, i
   suspect even now that the symbols of the Second Project may corrupt
the First Project's
   symbols as it must be in memory at the point of transferring
control to Second Project .
   And this is the Problem now . What could be the solution ?

Any other ideas for resolving this issue of Debugging Multiple
Projects ? I do not find any
info with respect to debugging Multiple Projects in CCS (Code Composer
Studio).
I use CCS and XDS510-USB for OMAP.

Could someone here help me in resolving this issue ?

Thx in advans,
Karthik Balaguru