Well, I have a production version of my code compiling and linking, but it
doesn't run when I load it across the PCI bus although it does run if I
load
it via Code Composer. The DSP is a 320C6416 and it is a Spectrum Digital
development board.
I have set the DIP switches on that board for a PCI boot, and Bit 2 of the
HDCR register is being set, which indicates the DSP recognizes that it is
supposed to be a PCI boot. So that appears to be OK.
Per SPRU-581C section 11, the linux host does a warm reset of the DSP by
writing Bit 0 of the HDCR register. It then writes page 0 into DSPP.
Then, the program code is transferred to the DSP where it is loaded starting
at location 0x0.
Finally, the linux host interrupts the DSP by writing Bit 1 of the HDCR
register.
The program is now supposed to begin executing at location 0x0.
However, the program does NOT begin executing. As near as I can tell, the DSP
does not emerge from reset. The program IS being written; it seems to match
bit for bit what gets loaded when Code Composer does it, but it just does not
execute.
This suggests that there is some register configuration that isn't called
out
clearly in SPRU-581C that I am not accomplishing.
I have tried two variants of this; warm reset followed by program load
followed by interrupt and program load followed by warm reset followed by
interrupt. Neither is working.
This has to be something simple; it works when Code Composer does it.
Can anyone here tell me what I am missing?
Thanks.
Jim
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video
Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
PCI booting of production code
Started by ●March 12, 2008
Reply by ●March 12, 20082008-03-12
Jim,
On 3/12/08, jim wrote:
>
> Well, I have a production version of my code compiling and linking, but
> it
> doesn't run when I load it across the PCI bus although it does run if I
> load
> it via Code Composer. The DSP is a 320C6416 and it is a Spectrum Digital
> development board.
>
> I have set the DIP switches on that board for a PCI boot, and Bit 2 of the
>
> HDCR register is being set, which indicates the DSP recognizes that it is
> supposed to be a PCI boot. So that appears to be OK.
>
> Per SPRU-581C section 11, the linux host does a warm reset of the DSP by
> writing Bit 0 of the HDCR register. It then writes page 0 into DSPP.
>
> Then, the program code is transferred to the DSP where it is loaded
> starting
> at location 0x0.
>
> Finally, the linux host interrupts the DSP by writing Bit 1 of the HDCR
> register.
>
> The program is now supposed to begin executing at location 0x0.
>
> However, the program does NOT begin executing. As near as I can tell, the
> DSP
> does not emerge from reset. The program IS being written; it seems to
> match
> bit for bit what gets loaded when Code Composer does it, but it just does
> not
> execute.
>
> This suggests that there is some register configuration that isn't called
> out
> clearly in SPRU-581C that I am not accomplishing.
>
> I have tried two variants of this; warm reset followed by program load
> followed by interrupt and program load followed by warm reset followed by
> interrupt. Neither is working.
>
> This has to be something simple; it works when Code Composer does it.
>
> Can anyone here tell me what I am missing?
>
I am not sure off hand if you are missing anything - I think that you are on
the right track.
You should be able to verify your theory by performing the following steps:
1. Leave CCS up and connected to the target. Perform a 'Run Free' - this
should cause CCS to 'leave the target alone'.
2. Load the target via PCI and attempt to start it.
3. Goto CCS and hit halt. If it is setting at 0, the target received the
warm reset but the Host interupt sequence was not successful. If it is at
another address, you may have gotten a 'bad load'.
4. If the PC was at 0, you should be able to run from CCS [and it should
work].
This doesn't help your problem if your theory is correct, but it might help
verify it.
mikedunn
Thanks.
>
> Jim
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
On 3/12/08, jim wrote:
>
> Well, I have a production version of my code compiling and linking, but
> it
> doesn't run when I load it across the PCI bus although it does run if I
> load
> it via Code Composer. The DSP is a 320C6416 and it is a Spectrum Digital
> development board.
>
> I have set the DIP switches on that board for a PCI boot, and Bit 2 of the
>
> HDCR register is being set, which indicates the DSP recognizes that it is
> supposed to be a PCI boot. So that appears to be OK.
>
> Per SPRU-581C section 11, the linux host does a warm reset of the DSP by
> writing Bit 0 of the HDCR register. It then writes page 0 into DSPP.
>
> Then, the program code is transferred to the DSP where it is loaded
> starting
> at location 0x0.
>
> Finally, the linux host interrupts the DSP by writing Bit 1 of the HDCR
> register.
>
> The program is now supposed to begin executing at location 0x0.
>
> However, the program does NOT begin executing. As near as I can tell, the
> DSP
> does not emerge from reset. The program IS being written; it seems to
> match
> bit for bit what gets loaded when Code Composer does it, but it just does
> not
> execute.
>
> This suggests that there is some register configuration that isn't called
> out
> clearly in SPRU-581C that I am not accomplishing.
>
> I have tried two variants of this; warm reset followed by program load
> followed by interrupt and program load followed by warm reset followed by
> interrupt. Neither is working.
>
> This has to be something simple; it works when Code Composer does it.
>
> Can anyone here tell me what I am missing?
>
I am not sure off hand if you are missing anything - I think that you are on
the right track.
You should be able to verify your theory by performing the following steps:
1. Leave CCS up and connected to the target. Perform a 'Run Free' - this
should cause CCS to 'leave the target alone'.
2. Load the target via PCI and attempt to start it.
3. Goto CCS and hit halt. If it is setting at 0, the target received the
warm reset but the Host interupt sequence was not successful. If it is at
another address, you may have gotten a 'bad load'.
4. If the PC was at 0, you should be able to run from CCS [and it should
work].
This doesn't help your problem if your theory is correct, but it might help
verify it.
mikedunn
Thanks.
>
> Jim
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●March 13, 20082008-03-13
Jim,
> Subject: Re: PCI booting of production code
> Posted by: "Michael Dunn" m...@gmail.com mikedunn.0101
> Date: Wed Mar 12, 2008 3:58 pm ((PDT))
>
> Jim,
>
> On 3/12/08, jim wrote:
>>
>> Well, I have a production version of my code compiling and linking, but it
>> doesn't run when I load it across the PCI bus although it does run if I load
>> it via Code Composer. The DSP is a 320C6416 and it is a Spectrum Digital
>> development board.
>>
>> I have set the DIP switches on that board for a PCI boot, and Bit 2 of the
>>
>> HDCR register is being set, which indicates the DSP recognizes that it is
>> supposed to be a PCI boot. So that appears to be OK.
>>
>> Per SPRU-581C section 11, the linux host does a warm reset of the DSP by
>> writing Bit 0 of the HDCR register. It then writes page 0 into DSPP.
>>
>> Then, the program code is transferred to the DSP where it is loaded starting
>> at location 0x0.
>>
>> Finally, the linux host interrupts the DSP by writing Bit 1 of the HDCR
>> register.
>>
>> The program is now supposed to begin executing at location 0x0.
>>
>> However, the program does NOT begin executing. As near as I can tell, the DSP
>> does not emerge from reset. The program IS being written; it seems to match
>> bit for bit what gets loaded when Code Composer does it, but it just does not
>> execute.
>>
>> This suggests that there is some register configuration that isn't called out
>> clearly in SPRU-581C that I am not accomplishing.
>>
>> I have tried two variants of this; warm reset followed by program load
>> followed by interrupt and program load followed by warm reset followed by
>> interrupt. Neither is working.
>>
>> This has to be something simple; it works when Code Composer does it.
>>
>> Can anyone here tell me what I am missing?
>> I am not sure off hand if you are missing anything - I think that you are on
> the right track.
> You should be able to verify your theory by performing the following steps:
> 1. Leave CCS up and connected to the target. Perform a 'Run Free' - this
> should cause CCS to 'leave the target alone'.
> 2. Load the target via PCI and attempt to start it.
> 3. Goto CCS and hit halt. If it is setting at 0, the target received the
> warm reset but the Host interupt sequence was not successful. If it is at
> another address, you may have gotten a 'bad load'.
> 4. If the PC was at 0, you should be able to run from CCS [and it should
> work].
>
> This doesn't help your problem if your theory is correct, but it might help
> verify it.
I wold like to add a few points to check in addition to what Mike has already
pointed out:
* to take very closest(!) look on what the startup code (running at 0x00) does.
Most commonly it jumps to _c_int00, but this is absolutely not always so. The
startup may perform a multitude of actions before handing out control to
the C starting point.
* how does the EMIF get configured: is it being done by the host side PCI
driver that on the boot phase accesses the non-prefetchable memory or, is it
being performed by the startup code (see above). Either way, the registers
have to be correctly set.
* there are various configuration options of the device that are explained in
the data sheet (SPRS146 for the TMS320C6416) that have to be checked:
* device configuration on p.37 of sprs146k.pdf
* multiplexed pins on p.41
* clock pll on p.68
* bootmode on p.77
after getting out of reset, the cpu generally needs to set up multiplexed
pins, enable all the necesary peripherals that might not be enabled by default,
init emif registers, cleanup spurious interrupts, etc etc...
CCS uses a gel file with instructions to set all/or some of these, it also
automatically sets pce to _c_int00 (once I tried to debug a naked asm code
without _c_int00 - it was fun! :), so that a lot of initializing procedures
go in the CCS background and do not require the uses or application code
intervention.
Rgds,
Andrew
> mikedunn
>
> Thanks.
>>
>> Jim
>> --
> www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
>
> Messages in this topic (2)
> ________________________________________________________________________
> ________________________________________________________________________
>
> Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
>
>
> Subject: Re: PCI booting of production code
> Posted by: "Michael Dunn" m...@gmail.com mikedunn.0101
> Date: Wed Mar 12, 2008 3:58 pm ((PDT))
>
> Jim,
>
> On 3/12/08, jim wrote:
>>
>> Well, I have a production version of my code compiling and linking, but it
>> doesn't run when I load it across the PCI bus although it does run if I load
>> it via Code Composer. The DSP is a 320C6416 and it is a Spectrum Digital
>> development board.
>>
>> I have set the DIP switches on that board for a PCI boot, and Bit 2 of the
>>
>> HDCR register is being set, which indicates the DSP recognizes that it is
>> supposed to be a PCI boot. So that appears to be OK.
>>
>> Per SPRU-581C section 11, the linux host does a warm reset of the DSP by
>> writing Bit 0 of the HDCR register. It then writes page 0 into DSPP.
>>
>> Then, the program code is transferred to the DSP where it is loaded starting
>> at location 0x0.
>>
>> Finally, the linux host interrupts the DSP by writing Bit 1 of the HDCR
>> register.
>>
>> The program is now supposed to begin executing at location 0x0.
>>
>> However, the program does NOT begin executing. As near as I can tell, the DSP
>> does not emerge from reset. The program IS being written; it seems to match
>> bit for bit what gets loaded when Code Composer does it, but it just does not
>> execute.
>>
>> This suggests that there is some register configuration that isn't called out
>> clearly in SPRU-581C that I am not accomplishing.
>>
>> I have tried two variants of this; warm reset followed by program load
>> followed by interrupt and program load followed by warm reset followed by
>> interrupt. Neither is working.
>>
>> This has to be something simple; it works when Code Composer does it.
>>
>> Can anyone here tell me what I am missing?
>> I am not sure off hand if you are missing anything - I think that you are on
> the right track.
> You should be able to verify your theory by performing the following steps:
> 1. Leave CCS up and connected to the target. Perform a 'Run Free' - this
> should cause CCS to 'leave the target alone'.
> 2. Load the target via PCI and attempt to start it.
> 3. Goto CCS and hit halt. If it is setting at 0, the target received the
> warm reset but the Host interupt sequence was not successful. If it is at
> another address, you may have gotten a 'bad load'.
> 4. If the PC was at 0, you should be able to run from CCS [and it should
> work].
>
> This doesn't help your problem if your theory is correct, but it might help
> verify it.
I wold like to add a few points to check in addition to what Mike has already
pointed out:
* to take very closest(!) look on what the startup code (running at 0x00) does.
Most commonly it jumps to _c_int00, but this is absolutely not always so. The
startup may perform a multitude of actions before handing out control to
the C starting point.
* how does the EMIF get configured: is it being done by the host side PCI
driver that on the boot phase accesses the non-prefetchable memory or, is it
being performed by the startup code (see above). Either way, the registers
have to be correctly set.
* there are various configuration options of the device that are explained in
the data sheet (SPRS146 for the TMS320C6416) that have to be checked:
* device configuration on p.37 of sprs146k.pdf
* multiplexed pins on p.41
* clock pll on p.68
* bootmode on p.77
after getting out of reset, the cpu generally needs to set up multiplexed
pins, enable all the necesary peripherals that might not be enabled by default,
init emif registers, cleanup spurious interrupts, etc etc...
CCS uses a gel file with instructions to set all/or some of these, it also
automatically sets pce to _c_int00 (once I tried to debug a naked asm code
without _c_int00 - it was fun! :), so that a lot of initializing procedures
go in the CCS background and do not require the uses or application code
intervention.
Rgds,
Andrew
> mikedunn
>
> Thanks.
>>
>> Jim
>> --
> www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
>
> Messages in this topic (2)
> ________________________________________________________________________
> ________________________________________________________________________
>
> Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
>
>
Reply by ●March 16, 20082008-03-16
On Thursday 13 March 2008 12:58:26 Andrew Nesterov wrote:
> Jim,
>
> > Subject: Re: PCI booting of production code
> > Posted by: "Michael Dunn" m...@gmail.com mikedunn.0101
> > Date: Wed Mar 12, 2008 3:58 pm ((PDT))
> >
> > Jim,
> >
> > On 3/12/08, jim wrote:
> >> Well, I have a production version of my code compiling and linking,
> >> but it doesn't run when I load it across the PCI bus although it does
> >> run if I load it via Code Composer. The DSP is a 320C6416 and it is a
> >> Spectrum Digital development board.
> >>
> >> I have set the DIP switches on that board for a PCI boot, and Bit 2 of
> >> the
> >>
> >> HDCR register is being set, which indicates the DSP recognizes that it
> >> is supposed to be a PCI boot. So that appears to be OK.
> >>
> >> Per SPRU-581C section 11, the linux host does a warm reset of the DSP by
> >> writing Bit 0 of the HDCR register. It then writes page 0 into DSPP.
> >>
> >> Then, the program code is transferred to the DSP where it is loaded
> >> starting at location 0x0.
> >>
> >> Finally, the linux host interrupts the DSP by writing Bit 1 of the HDCR
> >> register.
> >>
> >> The program is now supposed to begin executing at location 0x0.
> >>
> >> However, the program does NOT begin executing. As near as I can tell,
> >> the DSP does not emerge from reset. The program IS being written; it
> >> seems to match bit for bit what gets loaded when Code Composer does it,
> >> but it just does not execute.
> >>
> >> This suggests that there is some register configuration that isn't
> >> called out clearly in SPRU-581C that I am not accomplishing.
> >>
> >> I have tried two variants of this; warm reset followed by program load
> >> followed by interrupt and program load followed by warm reset followed
> >> by interrupt. Neither is working.
> >>
> >> This has to be something simple; it works when Code Composer does it.
> >>
> >> Can anyone here tell me what I am missing?
> >
> > I am not sure off hand if you are missing anything - I think that you are
> > on the right track.
> > You should be able to verify your theory by performing the following
> > steps: 1. Leave CCS up and connected to the target. Perform a 'Run Free'
> > - this should cause CCS to 'leave the target alone'.
> > 2. Load the target via PCI and attempt to start it.
> > 3. Goto CCS and hit halt. If it is setting at 0, the target received the
> > warm reset but the Host interupt sequence was not successful. If it is at
> > another address, you may have gotten a 'bad load'.
> > 4. If the PC was at 0, you should be able to run from CCS [and it should
> > work].
> >
> > This doesn't help your problem if your theory is correct, but it might
> > help verify it.
>
> I wold like to add a few points to check in addition to what Mike has
> already pointed out:
>
> * to take very closest(!) look on what the startup code (running at 0x00)
> does. Most commonly it jumps to _c_int00, but this is absolutely not always
> so. The startup may perform a multitude of actions before handing out
> control to the C starting point.
>
Startup code is set up by ccs. I don't really know what all it does except
that when ccs loads the program, it runs. When I load it across the PCI bus,
it doesn't run.
> * how does the EMIF get configured: is it being done by the host side PCI
> driver that on the boot phase accesses the non-prefetchable memory or, is
> it being performed by the startup code (see above). Either way, the
> registers have to be correctly set.
>
It is getting configured however ccs does that. The host driver does NOT do
it, and it happens in the startup code if the default ccs implementation does
this.
Presently, this is what I am investigating; if need be I can have this
configuration handled either by my linux host driver or (more likely) by the
userspace program that sits behind the driver and actually loads the program.
> * there are various configuration options of the device that are explained
> in the data sheet (SPRS146 for the TMS320C6416) that have to be checked: *
> device configuration on p.37 of sprs146k.pdf
> * multiplexed pins on p.41
> * clock pll on p.68
> * bootmode on p.77
I did not have this doc, and after a bit of a google search I was able to find
it. I am now reviewing it, but mostly it has to do with hardware
configuration. I am not configuring a naked chip here; this is a development
board. I did have to jumper the PCI enable to make that work but everything
else is handled by DIP switches...and they appear to be set correctly.
> after getting out of reset, the cpu generally needs to set up multiplexed
> pins, enable all the necesary peripherals that might not be enabled by
> default, init emif registers, cleanup spurious interrupts, etc etc...
>
> CCS uses a gel file with instructions to set all/or some of these, it also
> automatically sets pce to _c_int00 (once I tried to debug a naked asm code
> without _c_int00 - it was fun! :), so that a lot of initializing procedures
> go in the CCS background and do not require the uses or application code
> intervention.
>
This is what I am trying to figure out now. This does seem to require me to
learn the GEL language though. That is more of a nuisance than I had
expected.
Thanks to both you and Mike.
> Rgds,
>
> Andrew
>
> > mikedunn
> >
> >
> >
> > Thanks.
> >
> >> Jim
> >
> > --
> > www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
> Jim,
>
> > Subject: Re: PCI booting of production code
> > Posted by: "Michael Dunn" m...@gmail.com mikedunn.0101
> > Date: Wed Mar 12, 2008 3:58 pm ((PDT))
> >
> > Jim,
> >
> > On 3/12/08, jim wrote:
> >> Well, I have a production version of my code compiling and linking,
> >> but it doesn't run when I load it across the PCI bus although it does
> >> run if I load it via Code Composer. The DSP is a 320C6416 and it is a
> >> Spectrum Digital development board.
> >>
> >> I have set the DIP switches on that board for a PCI boot, and Bit 2 of
> >> the
> >>
> >> HDCR register is being set, which indicates the DSP recognizes that it
> >> is supposed to be a PCI boot. So that appears to be OK.
> >>
> >> Per SPRU-581C section 11, the linux host does a warm reset of the DSP by
> >> writing Bit 0 of the HDCR register. It then writes page 0 into DSPP.
> >>
> >> Then, the program code is transferred to the DSP where it is loaded
> >> starting at location 0x0.
> >>
> >> Finally, the linux host interrupts the DSP by writing Bit 1 of the HDCR
> >> register.
> >>
> >> The program is now supposed to begin executing at location 0x0.
> >>
> >> However, the program does NOT begin executing. As near as I can tell,
> >> the DSP does not emerge from reset. The program IS being written; it
> >> seems to match bit for bit what gets loaded when Code Composer does it,
> >> but it just does not execute.
> >>
> >> This suggests that there is some register configuration that isn't
> >> called out clearly in SPRU-581C that I am not accomplishing.
> >>
> >> I have tried two variants of this; warm reset followed by program load
> >> followed by interrupt and program load followed by warm reset followed
> >> by interrupt. Neither is working.
> >>
> >> This has to be something simple; it works when Code Composer does it.
> >>
> >> Can anyone here tell me what I am missing?
> >
> > I am not sure off hand if you are missing anything - I think that you are
> > on the right track.
> > You should be able to verify your theory by performing the following
> > steps: 1. Leave CCS up and connected to the target. Perform a 'Run Free'
> > - this should cause CCS to 'leave the target alone'.
> > 2. Load the target via PCI and attempt to start it.
> > 3. Goto CCS and hit halt. If it is setting at 0, the target received the
> > warm reset but the Host interupt sequence was not successful. If it is at
> > another address, you may have gotten a 'bad load'.
> > 4. If the PC was at 0, you should be able to run from CCS [and it should
> > work].
> >
> > This doesn't help your problem if your theory is correct, but it might
> > help verify it.
>
> I wold like to add a few points to check in addition to what Mike has
> already pointed out:
>
> * to take very closest(!) look on what the startup code (running at 0x00)
> does. Most commonly it jumps to _c_int00, but this is absolutely not always
> so. The startup may perform a multitude of actions before handing out
> control to the C starting point.
>
Startup code is set up by ccs. I don't really know what all it does except
that when ccs loads the program, it runs. When I load it across the PCI bus,
it doesn't run.
> * how does the EMIF get configured: is it being done by the host side PCI
> driver that on the boot phase accesses the non-prefetchable memory or, is
> it being performed by the startup code (see above). Either way, the
> registers have to be correctly set.
>
It is getting configured however ccs does that. The host driver does NOT do
it, and it happens in the startup code if the default ccs implementation does
this.
Presently, this is what I am investigating; if need be I can have this
configuration handled either by my linux host driver or (more likely) by the
userspace program that sits behind the driver and actually loads the program.
> * there are various configuration options of the device that are explained
> in the data sheet (SPRS146 for the TMS320C6416) that have to be checked: *
> device configuration on p.37 of sprs146k.pdf
> * multiplexed pins on p.41
> * clock pll on p.68
> * bootmode on p.77
I did not have this doc, and after a bit of a google search I was able to find
it. I am now reviewing it, but mostly it has to do with hardware
configuration. I am not configuring a naked chip here; this is a development
board. I did have to jumper the PCI enable to make that work but everything
else is handled by DIP switches...and they appear to be set correctly.
> after getting out of reset, the cpu generally needs to set up multiplexed
> pins, enable all the necesary peripherals that might not be enabled by
> default, init emif registers, cleanup spurious interrupts, etc etc...
>
> CCS uses a gel file with instructions to set all/or some of these, it also
> automatically sets pce to _c_int00 (once I tried to debug a naked asm code
> without _c_int00 - it was fun! :), so that a lot of initializing procedures
> go in the CCS background and do not require the uses or application code
> intervention.
>
This is what I am trying to figure out now. This does seem to require me to
learn the GEL language though. That is more of a nuisance than I had
expected.
Thanks to both you and Mike.
> Rgds,
>
> Andrew
>
> > mikedunn
> >
> >
> >
> > Thanks.
> >
> >> Jim
> >
> > --
> > www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
Reply by ●March 16, 20082008-03-16
Jim,
On Sat, Mar 15, 2008 at 2:52 PM, jim wrote:
>
> On Thursday 13 March 2008 12:58:26 Andrew Nesterov wrote:
> > Jim,
> >
> > > Subject: Re: PCI booting of production code
> > > Posted by: "Michael Dunn" m...@gmail.com mikedunn.0101
> > > Date: Wed Mar 12, 2008 3:58 pm ((PDT))
> > >
> > > Jim,
> > >
> > > On 3/12/08, jim wrote:
> > >> Well, I have a production version of my code compiling and linking,
> > >> but it doesn't run when I load it across the PCI bus although it does
> > >> run if I load it via Code Composer. The DSP is a 320C6416 and it is a
> > >> Spectrum Digital development board.
> > >>
> > >> I have set the DIP switches on that board for a PCI boot, and Bit 2 of
> > >> the
> > >>
> > >> HDCR register is being set, which indicates the DSP recognizes that it
> > >> is supposed to be a PCI boot. So that appears to be OK.
> > >>
> > >> Per SPRU-581C section 11, the linux host does a warm reset of the DSP by
> > >> writing Bit 0 of the HDCR register. It then writes page 0 into DSPP.
> > >>
> > >> Then, the program code is transferred to the DSP where it is loaded
> > >> starting at location 0x0.
> > >>
> > >> Finally, the linux host interrupts the DSP by writing Bit 1 of the HDCR
> > >> register.
> > >>
> > >> The program is now supposed to begin executing at location 0x0.
> > >>
> > >> However, the program does NOT begin executing. As near as I can tell,
> > >> the DSP does not emerge from reset. The program IS being written; it
> > >> seems to match bit for bit what gets loaded when Code Composer does it,
> > >> but it just does not execute.
> > >>
> > >> This suggests that there is some register configuration that isn't
> > >> called out clearly in SPRU-581C that I am not accomplishing.
> > >>
> > >> I have tried two variants of this; warm reset followed by program load
> > >> followed by interrupt and program load followed by warm reset followed
> > >> by interrupt. Neither is working.
> > >>
> > >> This has to be something simple; it works when Code Composer does it.
> > >>
> > >> Can anyone here tell me what I am missing?
> > >
> > > I am not sure off hand if you are missing anything - I think that you are
> > > on the right track.
> > > You should be able to verify your theory by performing the following
> > > steps: 1. Leave CCS up and connected to the target. Perform a 'Run Free'
> > > - this should cause CCS to 'leave the target alone'.
> > > 2. Load the target via PCI and attempt to start it.
> > > 3. Goto CCS and hit halt. If it is setting at 0, the target received the
> > > warm reset but the Host interupt sequence was not successful. If it is at
> > > another address, you may have gotten a 'bad load'.
> > > 4. If the PC was at 0, you should be able to run from CCS [and it should
> > > work].
> > >
> > > This doesn't help your problem if your theory is correct, but it might
> > > help verify it.
> >
> > I wold like to add a few points to check in addition to what Mike has
> > already pointed out:
> >
> > * to take very closest(!) look on what the startup code (running at 0x00)
> > does. Most commonly it jumps to _c_int00, but this is absolutely not always
> > so. The startup may perform a multitude of actions before handing out
> > control to the C starting point.
> >
> Startup code is set up by ccs. I don't really know what all it does except
> that when ccs loads the program, it runs. When I load it across the PCI bus,
> it doesn't run.
> > * how does the EMIF get configured: is it being done by the host side PCI
> > driver that on the boot phase accesses the non-prefetchable memory or, is
> > it being performed by the startup code (see above). Either way, the
> > registers have to be correctly set.
> >
> It is getting configured however ccs does that. The host driver does NOT do
> it, and it happens in the startup code if the default ccs implementation does
> this.
>
> Presently, this is what I am investigating; if need be I can have this
> configuration handled either by my linux host driver or (more likely) by the
> userspace program that sits behind the driver and actually loads the program.
> > * there are various configuration options of the device that are explained
> > in the data sheet (SPRS146 for the TMS320C6416) that have to be checked: *
> > device configuration on p.37 of sprs146k.pdf
> > * multiplexed pins on p.41
> > * clock pll on p.68
> > * bootmode on p.77
>
> I did not have this doc, and after a bit of a google search I was able to find
> it. I am now reviewing it, but mostly it has to do with hardware
> configuration. I am not configuring a naked chip here; this is a development
> board. I did have to jumper the PCI enable to make that work but everything
> else is handled by DIP switches...and they appear to be set correctly.
> > after getting out of reset, the cpu generally needs to set up multiplexed
> > pins, enable all the necesary peripherals that might not be enabled by
> > default, init emif registers, cleanup spurious interrupts, etc etc...
> >
> > CCS uses a gel file with instructions to set all/or some of these, it also
> > automatically sets pce to _c_int00 (once I tried to debug a naked asm code
> > without _c_int00 - it was fun! :), so that a lot of initializing procedures
> > go in the CCS background and do not require the uses or application code
> > intervention.
> >
> This is what I am trying to figure out now. This does seem to require me to
> learn the GEL language though. That is more of a nuisance than I had
> expected.
This is both the blessing and curse of CCS. TI or a board vendor
supplies a GEL file that twiddles some bits and sets up the EMIF.
This allows users to "write some useful code" on day one without
breaking out a bunch of documents and trying to figure out how to 'set
the right bits'. It is usually great - until the time comes to run
what you think is 'working embedded code'. There doesn't seem to be
much emphasis that CCS 'does some magic' that will need to be
replicated in code at some point in time. The good news is that the
important stuff in the GEL file [usually EMIF setup, cache
configuration, PPL setup, etc.] is very 'C like' and is easily
translated to C - once you figure out that you need to do it.
Good luck in the home stretch,
mikedunn
> Thanks to both you and Mike.
>
> > Rgds,
> >
> > Andrew
> >
> > > mikedunn
> > >
> > >
> > >
> > > Thanks.
> > >
> > >> Jim
> > >
> > > --
> > > www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
> > >
> > > Messages in this topic (2)
> > > ________________________________________________________________________
> > > ________________________________________________________________________
> > >
> > > Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video
> > > Transcoding Solution for Commercial & Consumer End Equipment:
> > > www.ti.com/dm6467
> > >
> > >
> > >
> > >
> > >
> > >
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
On Sat, Mar 15, 2008 at 2:52 PM, jim wrote:
>
> On Thursday 13 March 2008 12:58:26 Andrew Nesterov wrote:
> > Jim,
> >
> > > Subject: Re: PCI booting of production code
> > > Posted by: "Michael Dunn" m...@gmail.com mikedunn.0101
> > > Date: Wed Mar 12, 2008 3:58 pm ((PDT))
> > >
> > > Jim,
> > >
> > > On 3/12/08, jim wrote:
> > >> Well, I have a production version of my code compiling and linking,
> > >> but it doesn't run when I load it across the PCI bus although it does
> > >> run if I load it via Code Composer. The DSP is a 320C6416 and it is a
> > >> Spectrum Digital development board.
> > >>
> > >> I have set the DIP switches on that board for a PCI boot, and Bit 2 of
> > >> the
> > >>
> > >> HDCR register is being set, which indicates the DSP recognizes that it
> > >> is supposed to be a PCI boot. So that appears to be OK.
> > >>
> > >> Per SPRU-581C section 11, the linux host does a warm reset of the DSP by
> > >> writing Bit 0 of the HDCR register. It then writes page 0 into DSPP.
> > >>
> > >> Then, the program code is transferred to the DSP where it is loaded
> > >> starting at location 0x0.
> > >>
> > >> Finally, the linux host interrupts the DSP by writing Bit 1 of the HDCR
> > >> register.
> > >>
> > >> The program is now supposed to begin executing at location 0x0.
> > >>
> > >> However, the program does NOT begin executing. As near as I can tell,
> > >> the DSP does not emerge from reset. The program IS being written; it
> > >> seems to match bit for bit what gets loaded when Code Composer does it,
> > >> but it just does not execute.
> > >>
> > >> This suggests that there is some register configuration that isn't
> > >> called out clearly in SPRU-581C that I am not accomplishing.
> > >>
> > >> I have tried two variants of this; warm reset followed by program load
> > >> followed by interrupt and program load followed by warm reset followed
> > >> by interrupt. Neither is working.
> > >>
> > >> This has to be something simple; it works when Code Composer does it.
> > >>
> > >> Can anyone here tell me what I am missing?
> > >
> > > I am not sure off hand if you are missing anything - I think that you are
> > > on the right track.
> > > You should be able to verify your theory by performing the following
> > > steps: 1. Leave CCS up and connected to the target. Perform a 'Run Free'
> > > - this should cause CCS to 'leave the target alone'.
> > > 2. Load the target via PCI and attempt to start it.
> > > 3. Goto CCS and hit halt. If it is setting at 0, the target received the
> > > warm reset but the Host interupt sequence was not successful. If it is at
> > > another address, you may have gotten a 'bad load'.
> > > 4. If the PC was at 0, you should be able to run from CCS [and it should
> > > work].
> > >
> > > This doesn't help your problem if your theory is correct, but it might
> > > help verify it.
> >
> > I wold like to add a few points to check in addition to what Mike has
> > already pointed out:
> >
> > * to take very closest(!) look on what the startup code (running at 0x00)
> > does. Most commonly it jumps to _c_int00, but this is absolutely not always
> > so. The startup may perform a multitude of actions before handing out
> > control to the C starting point.
> >
> Startup code is set up by ccs. I don't really know what all it does except
> that when ccs loads the program, it runs. When I load it across the PCI bus,
> it doesn't run.
> > * how does the EMIF get configured: is it being done by the host side PCI
> > driver that on the boot phase accesses the non-prefetchable memory or, is
> > it being performed by the startup code (see above). Either way, the
> > registers have to be correctly set.
> >
> It is getting configured however ccs does that. The host driver does NOT do
> it, and it happens in the startup code if the default ccs implementation does
> this.
>
> Presently, this is what I am investigating; if need be I can have this
> configuration handled either by my linux host driver or (more likely) by the
> userspace program that sits behind the driver and actually loads the program.
> > * there are various configuration options of the device that are explained
> > in the data sheet (SPRS146 for the TMS320C6416) that have to be checked: *
> > device configuration on p.37 of sprs146k.pdf
> > * multiplexed pins on p.41
> > * clock pll on p.68
> > * bootmode on p.77
>
> I did not have this doc, and after a bit of a google search I was able to find
> it. I am now reviewing it, but mostly it has to do with hardware
> configuration. I am not configuring a naked chip here; this is a development
> board. I did have to jumper the PCI enable to make that work but everything
> else is handled by DIP switches...and they appear to be set correctly.
> > after getting out of reset, the cpu generally needs to set up multiplexed
> > pins, enable all the necesary peripherals that might not be enabled by
> > default, init emif registers, cleanup spurious interrupts, etc etc...
> >
> > CCS uses a gel file with instructions to set all/or some of these, it also
> > automatically sets pce to _c_int00 (once I tried to debug a naked asm code
> > without _c_int00 - it was fun! :), so that a lot of initializing procedures
> > go in the CCS background and do not require the uses or application code
> > intervention.
> >
> This is what I am trying to figure out now. This does seem to require me to
> learn the GEL language though. That is more of a nuisance than I had
> expected.
This is both the blessing and curse of CCS. TI or a board vendor
supplies a GEL file that twiddles some bits and sets up the EMIF.
This allows users to "write some useful code" on day one without
breaking out a bunch of documents and trying to figure out how to 'set
the right bits'. It is usually great - until the time comes to run
what you think is 'working embedded code'. There doesn't seem to be
much emphasis that CCS 'does some magic' that will need to be
replicated in code at some point in time. The good news is that the
important stuff in the GEL file [usually EMIF setup, cache
configuration, PPL setup, etc.] is very 'C like' and is easily
translated to C - once you figure out that you need to do it.
Good luck in the home stretch,
mikedunn
> Thanks to both you and Mike.
>
> > Rgds,
> >
> > Andrew
> >
> > > mikedunn
> > >
> > >
> > >
> > > Thanks.
> > >
> > >> Jim
> > >
> > > --
> > > www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
> > >
> > > Messages in this topic (2)
> > > ________________________________________________________________________
> > > ________________________________________________________________________
> > >
> > > Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video
> > > Transcoding Solution for Commercial & Consumer End Equipment:
> > > www.ti.com/dm6467
> > >
> > >
> > >
> > >
> > >
> > >
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●March 18, 20082008-03-18
Actually, I am now reading this program in a hex editor since, upon further
review, I have determined that _c_int00 is a named section that should be
present someplace in the program file.
Well, I have found it, but the label (which is 8 bytes long) is not word
aligned.
Should I branch the program to the BYTE that immediately follows the label, or
to the first complete 2 byte WORD that follows the label, or to the first 4
byte LONGWORD that follows the label?
Specifically, this label starts at location 0x3020d and finishes at 0x30214.
So the first byte after the label is 0x30215, which is not correct alignment,
but I do not know if the processor cares. The first word after the label is
0x30216 and the first longword is 0x30218.
And how do I set the PC from outside anyway?
review, I have determined that _c_int00 is a named section that should be
present someplace in the program file.
Well, I have found it, but the label (which is 8 bytes long) is not word
aligned.
Should I branch the program to the BYTE that immediately follows the label, or
to the first complete 2 byte WORD that follows the label, or to the first 4
byte LONGWORD that follows the label?
Specifically, this label starts at location 0x3020d and finishes at 0x30214.
So the first byte after the label is 0x30215, which is not correct alignment,
but I do not know if the processor cares. The first word after the label is
0x30216 and the first longword is 0x30218.
And how do I set the PC from outside anyway?
Reply by ●March 18, 20082008-03-18
OK. Following the GEL file, I am now initializing just about everything that
the GEL file initializes at the time that CC loads the program. I am setting
all the EMIF registers from the host and also clearing the L1 and L2 cache
from the host. Then I interrupt the DSP which is supposed to bring it out of
reset.
What happens then is that the program starts at location 0, with the following
code:
.word 0x003400c2
[ B1] STB.D2T2 SP,*+DP[0x5043]
LDBU.D2T1 *+DP[0x280,A0
|| CMPEQ.L1 A0,A0,A0
.word 0x11a3001c
SUB2.L1 A0,A2,A2
|| [!B2] SET.S1 A16,0,19,A31
Then there are a number of NOP statements, followed by other code.
Now, the first 0x200 bytes is supposed to be the interrupt vector table, and
it had been my thought that this first segment of code should have a jump to
_c_int00 (which is supposed to be at 0x14300 in this program), but I sure
don't see anything that looks like a jmp instruction.
Also, this code executes to location 0x100 then halts. So it apparently is
trying to execute data when it emerges from reset.
Now, the gel file sets IER to zero and sets IFR to zero. I do not see
anyplace where the program counter is set by the gel file, but I suppose that
is being done in the background somehow.
So, now my questions are : How do I access IER, IFR, and PC from my linux
host so that I can initialize them?
On Thursday 13 March 2008 12:58:26 you wrote:
> CCS uses a gel file with instructions to set all/or some of these, it also
> automatically sets pce to _c_int00 (once I tried to debug a naked asm code
> without _c_int00 - it was fun! :), so that a lot of initializing procedures
> go in the CCS background and do not require the uses or application code
> intervention.
the GEL file initializes at the time that CC loads the program. I am setting
all the EMIF registers from the host and also clearing the L1 and L2 cache
from the host. Then I interrupt the DSP which is supposed to bring it out of
reset.
What happens then is that the program starts at location 0, with the following
code:
.word 0x003400c2
[ B1] STB.D2T2 SP,*+DP[0x5043]
LDBU.D2T1 *+DP[0x280,A0
|| CMPEQ.L1 A0,A0,A0
.word 0x11a3001c
SUB2.L1 A0,A2,A2
|| [!B2] SET.S1 A16,0,19,A31
Then there are a number of NOP statements, followed by other code.
Now, the first 0x200 bytes is supposed to be the interrupt vector table, and
it had been my thought that this first segment of code should have a jump to
_c_int00 (which is supposed to be at 0x14300 in this program), but I sure
don't see anything that looks like a jmp instruction.
Also, this code executes to location 0x100 then halts. So it apparently is
trying to execute data when it emerges from reset.
Now, the gel file sets IER to zero and sets IFR to zero. I do not see
anyplace where the program counter is set by the gel file, but I suppose that
is being done in the background somehow.
So, now my questions are : How do I access IER, IFR, and PC from my linux
host so that I can initialize them?
On Thursday 13 March 2008 12:58:26 you wrote:
> CCS uses a gel file with instructions to set all/or some of these, it also
> automatically sets pce to _c_int00 (once I tried to debug a naked asm code
> without _c_int00 - it was fun! :), so that a lot of initializing procedures
> go in the CCS background and do not require the uses or application code
> intervention.
Reply by ●March 18, 20082008-03-18
Jim,
On 3/17/08, jim wrote:
> OK. Following the GEL file, I am now initializing just about everything that
> the GEL file initializes at the time that CC loads the program. I am setting
> all the EMIF registers from the host and also clearing the L1 and L2 cache
> from the host. Then I interrupt the DSP which is supposed to bring it out of
> reset.
>
> What happens then is that the program starts at location 0, with the following
> code:
>
> .word 0x003400c2
> [ B1] STB.D2T2 SP,*+DP[0x5043]
> LDBU.D2T1 *+DP[0x280,A0
> || CMPEQ.L1 A0,A0,A0
> .word 0x11a3001c
> SUB2.L1 A0,A2,A2
> || [!B2] SET.S1 A16,0,19,A31
This is messed up - especially the '.word. You should have a valid
vector table beginning at 0. Interrupts are vectored in at each 0x20
address. Address 0 usually has a branch to c_int00 [or your proam
entry point if different].
To make this happen one usually reserves a section of memory for the
vectors in the linker command file and includes an '.asm' file with
code to handle each interrupt. The code should fit in one fetch packet
[32 bytes] and usually contains a branch for complex interrupt
handlers.
This would explain your symptoms - you never executed you code from 0
with CCS. BTW, you can specify an alternate entry point [like
'_RESET_' at address 0] when debugging embedded code.
>
> Then there are a number of NOP statements, followed by other code.
>
> Now, the first 0x200 bytes is supposed to be the interrupt vector table, and
> it had been my thought that this first segment of code should have a jump to
> _c_int00 (which is supposed to be at 0x14300 in this program), but I sure
> don't see anything that looks like a jmp instruction.
The 'jump' [or branch in TI terms] must be placed there by the developer.
>
> Also, this code executes to location 0x100 then halts. So it apparently is
> trying to execute data when it emerges from reset.
One problem with the c6416 is that it will fetch and try to execute
any bit pattern that is present. The instruction set is NOT
protected/fully decoded [there is no such thing as an 'illegal
instruction' - it always tries to execute any bit pattern]. If you
did a 'run' from CCS, the DSP will continue trying to execute until it
hits a sw breakpoint [bit 28 set]. The other alternative is that it
eats a bit pattern that causes the DSP to lockup or spin in a loop.
>
> Now, the gel file sets IER to zero and sets IFR to zero. I do not see
> anyplace where the program counter is set by the gel file, but I suppose that
> is being done in the background somehow.
The CCS loader will ID the entry point in the COFF file and CCS will
set the PC to that value.
>
> So, now my questions are : How do I access IER, IFR, and PC from my linux
> host so that I can initialize them?
You can init the IER and IFR in your 'reset handler' at address 0.
When you get this setup, you will not have to worry about the PC.
mikedunn
>
> On Thursday 13 March 2008 12:58:26 you wrote:
>
> > CCS uses a gel file with instructions to set all/or some of these, it also
> > automatically sets pce to _c_int00 (once I tried to debug a naked asm code
> > without _c_int00 - it was fun! :), so that a lot of initializing procedures
> > go in the CCS background and do not require the uses or application code
> > intervention.
> >
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
On 3/17/08, jim wrote:
> OK. Following the GEL file, I am now initializing just about everything that
> the GEL file initializes at the time that CC loads the program. I am setting
> all the EMIF registers from the host and also clearing the L1 and L2 cache
> from the host. Then I interrupt the DSP which is supposed to bring it out of
> reset.
>
> What happens then is that the program starts at location 0, with the following
> code:
>
> .word 0x003400c2
> [ B1] STB.D2T2 SP,*+DP[0x5043]
> LDBU.D2T1 *+DP[0x280,A0
> || CMPEQ.L1 A0,A0,A0
> .word 0x11a3001c
> SUB2.L1 A0,A2,A2
> || [!B2] SET.S1 A16,0,19,A31
This is messed up - especially the '.word. You should have a valid
vector table beginning at 0. Interrupts are vectored in at each 0x20
address. Address 0 usually has a branch to c_int00 [or your proam
entry point if different].
To make this happen one usually reserves a section of memory for the
vectors in the linker command file and includes an '.asm' file with
code to handle each interrupt. The code should fit in one fetch packet
[32 bytes] and usually contains a branch for complex interrupt
handlers.
This would explain your symptoms - you never executed you code from 0
with CCS. BTW, you can specify an alternate entry point [like
'_RESET_' at address 0] when debugging embedded code.
>
> Then there are a number of NOP statements, followed by other code.
>
> Now, the first 0x200 bytes is supposed to be the interrupt vector table, and
> it had been my thought that this first segment of code should have a jump to
> _c_int00 (which is supposed to be at 0x14300 in this program), but I sure
> don't see anything that looks like a jmp instruction.
The 'jump' [or branch in TI terms] must be placed there by the developer.
>
> Also, this code executes to location 0x100 then halts. So it apparently is
> trying to execute data when it emerges from reset.
One problem with the c6416 is that it will fetch and try to execute
any bit pattern that is present. The instruction set is NOT
protected/fully decoded [there is no such thing as an 'illegal
instruction' - it always tries to execute any bit pattern]. If you
did a 'run' from CCS, the DSP will continue trying to execute until it
hits a sw breakpoint [bit 28 set]. The other alternative is that it
eats a bit pattern that causes the DSP to lockup or spin in a loop.
>
> Now, the gel file sets IER to zero and sets IFR to zero. I do not see
> anyplace where the program counter is set by the gel file, but I suppose that
> is being done in the background somehow.
The CCS loader will ID the entry point in the COFF file and CCS will
set the PC to that value.
>
> So, now my questions are : How do I access IER, IFR, and PC from my linux
> host so that I can initialize them?
You can init the IER and IFR in your 'reset handler' at address 0.
When you get this setup, you will not have to worry about the PC.
mikedunn
>
> On Thursday 13 March 2008 12:58:26 you wrote:
>
> > CCS uses a gel file with instructions to set all/or some of these, it also
> > automatically sets pce to _c_int00 (once I tried to debug a naked asm code
> > without _c_int00 - it was fun! :), so that a lot of initializing procedures
> > go in the CCS background and do not require the uses or application code
> > intervention.
> >
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●March 18, 20082008-03-18
> Date: 18-Mar-2008 08:35:27 -0700
> From: Michael Dunn Jim,
>
> On 3/17/08, jim wrote:
>
>> Actually, I am now reading this program in a hex editor since, upon
>> further
>> review, I have determined that _c_int00 is a named section that should be
>> present someplace in the program file.
>>
>> Well, I have found it, but the label (which is 8 bytes long) is not word
>> aligned.
>> This doesn't sound right. It should be word aligned [00 in the lower 2 bits]
> at a minimum.
> Your previous post indicated that it was -
> "_c_int00 (which is supposed to be at 0x14300 in this program)"
> Are you sure that it is not your editor?? Are you looking at the memory from
> the Linux PC??
> The CCS memory viewer should show you the correct bits and labels.
>
> mikedunn
Hi Mike,
I guess that these are the coff symbols (which are in fact just character
strings associated with labels addresses for debug/memory display) that
were randomly interpreted as labels themselves.
I found it (a while back) that moving from a high level abstracted programming
to a low-level control code is not an easy step. I'd say that even coding a
math algorithm in assembly is still another way of thinking than doing a
control code both in C or assembly. Playing with it eventually got me along
learning curve...
Cheers,
Andrew
>
>> Should I branch the program to the BYTE that immediately follows the
>> label, or
>> to the first complete 2 byte WORD that follows the label, or to the first
>> 4
>> byte LONGWORD that follows the label?
>>
>> Specifically, this label starts at location 0x3020d and finishes at
>> 0x30214.
>> So the first byte after the label is 0x30215, which is not correct
>> alignment,
>> but I do not know if the processor cares. The first word after the label
>> is
>> 0x30216 and the first longword is 0x30218.
>>
>> And how do I set the PC from outside anyway?
> From: Michael Dunn Jim,
>
> On 3/17/08, jim wrote:
>
>> Actually, I am now reading this program in a hex editor since, upon
>> further
>> review, I have determined that _c_int00 is a named section that should be
>> present someplace in the program file.
>>
>> Well, I have found it, but the label (which is 8 bytes long) is not word
>> aligned.
>> This doesn't sound right. It should be word aligned [00 in the lower 2 bits]
> at a minimum.
> Your previous post indicated that it was -
> "_c_int00 (which is supposed to be at 0x14300 in this program)"
> Are you sure that it is not your editor?? Are you looking at the memory from
> the Linux PC??
> The CCS memory viewer should show you the correct bits and labels.
>
> mikedunn
Hi Mike,
I guess that these are the coff symbols (which are in fact just character
strings associated with labels addresses for debug/memory display) that
were randomly interpreted as labels themselves.
I found it (a while back) that moving from a high level abstracted programming
to a low-level control code is not an easy step. I'd say that even coding a
math algorithm in assembly is still another way of thinking than doing a
control code both in C or assembly. Playing with it eventually got me along
learning curve...
Cheers,
Andrew
>
>> Should I branch the program to the BYTE that immediately follows the
>> label, or
>> to the first complete 2 byte WORD that follows the label, or to the first
>> 4
>> byte LONGWORD that follows the label?
>>
>> Specifically, this label starts at location 0x3020d and finishes at
>> 0x30214.
>> So the first byte after the label is 0x30215, which is not correct
>> alignment,
>> but I do not know if the processor cares. The first word after the label
>> is
>> 0x30216 and the first longword is 0x30218.
>>
>> And how do I set the PC from outside anyway?
Reply by ●March 18, 20082008-03-18
Jim,
On 3/17/08, jim wrote:
> Actually, I am now reading this program in a hex editor since, upon
> further
> review, I have determined that _c_int00 is a named section that should be
> present someplace in the program file.
>
> Well, I have found it, but the label (which is 8 bytes long) is not word
> aligned.
>
This doesn't sound right. It should be word aligned [00 in the lower 2 bits]
at a minimum.
Your previous post indicated that it was -
"_c_int00 (which is supposed to be at 0x14300 in this program)"
Are you sure that it is not your editor?? Are you looking at the memory from
the Linux PC??
The CCS memory viewer should show you the correct bits and labels.
mikedunn
> Should I branch the program to the BYTE that immediately follows the
> label, or
> to the first complete 2 byte WORD that follows the label, or to the first
> 4
> byte LONGWORD that follows the label?
>
> Specifically, this label starts at location 0x3020d and finishes at
> 0x30214.
> So the first byte after the label is 0x30215, which is not correct
> alignment,
> but I do not know if the processor cares. The first word after the label
> is
> 0x30216 and the first longword is 0x30218.
>
> And how do I set the PC from outside anyway?
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
On 3/17/08, jim wrote:
> Actually, I am now reading this program in a hex editor since, upon
> further
> review, I have determined that _c_int00 is a named section that should be
> present someplace in the program file.
>
> Well, I have found it, but the label (which is 8 bytes long) is not word
> aligned.
>
This doesn't sound right. It should be word aligned [00 in the lower 2 bits]
at a minimum.
Your previous post indicated that it was -
"_c_int00 (which is supposed to be at 0x14300 in this program)"
Are you sure that it is not your editor?? Are you looking at the memory from
the Linux PC??
The CCS memory viewer should show you the correct bits and labels.
mikedunn
> Should I branch the program to the BYTE that immediately follows the
> label, or
> to the first complete 2 byte WORD that follows the label, or to the first
> 4
> byte LONGWORD that follows the label?
>
> Specifically, this label starts at location 0x3020d and finishes at
> 0x30214.
> So the first byte after the label is 0x30215, which is not correct
> alignment,
> but I do not know if the processor cares. The first word after the label
> is
> 0x30216 and the first longword is 0x30218.
>
> And how do I set the PC from outside anyway?
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
