> 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