I am having a problem programming a board that is based on the 6713
dsp. The hardware was not developed by me, and is based on a board
similar to http://www.dsignt.de/products/dmodule/d6713.htm including a
bios/bootloader by the same company.
I am having a repeatability problem when debugging code that is using
interrupts. The issue that I see is that the code uses both timers,
though only one has an interrupt handler installed, I believe the other
timer is used for signaling an outside device. I have recently changed
so that the serial port input is handled via interrupts instead of
polling.
I have gone through the code to make sure that I'm initializing all of
my variables.
I am developing this in code composer studio.
I reset the CPU and let the processor run free, to make sure that the
bios has had a chance to initialize anythign it needs to do. I then do
a compile and load of my program in the code composer studio. (I have
it set to automaticaly load the program when it successfuly builds the
project.) About half the time It doesn't respond to interrupts on the
UART. Simply halting and reloading the program makes it respond to UART
interrupts. When it is responding to UART interrupts it's not
responding to timer interrupts.
Can anyone suggest what I can look for to figure out why it might be
different when I reload the same compiled image over the JTAG pot a
second time?
Wim.
interrupt issues on board based on 6713 chip
Started by ●August 21, 2006
Reply by ●August 22, 20062006-08-22
Wim-
> I am having a problem programming a board that is based on the 6713
> dsp. The hardware was not developed by me, and is based on a board
> similar to http://www.dsignt.de/products/dmodule/d6713.htm including a
> bios/bootloader by the same company.
>
> I am having a repeatability problem when debugging code that is using
> interrupts. The issue that I see is that the code uses both timers,
> though only one has an interrupt handler installed, I believe the other
> timer is used for signaling an outside device. I have recently changed
> so that the serial port input is handled via interrupts instead of
> polling.
>
> I have gone through the code to make sure that I'm initializing all of
> my variables.
>
> I am developing this in code composer studio.
>
> I reset the CPU and let the processor run free, to make sure that the
> bios has had a chance to initialize anythign it needs to do. I then do
> a compile and load of my program in the code composer studio. (I have
> it set to automaticaly load the program when it successfuly builds the
> project.) About half the time It doesn't respond to interrupts on the
> UART. Simply halting and reloading the program makes it respond to UART
> interrupts. When it is responding to UART interrupts it's not
> responding to timer interrupts.
Is this with CCS v3.1? If so, what we found is the "auto load" function
may have some timing issue. We found it to be more reliable to download
the program manually, and *always* make sure the previous run has been
halted and a Reset CPU has been performed.
Also it helped that all TI patches were downloaded and installed for v3.1.
Even with this, we still have not reached the same "each download performs
the same every time" reliability as we have for CCS v2.2x.
-Jeff
> I am having a problem programming a board that is based on the 6713
> dsp. The hardware was not developed by me, and is based on a board
> similar to http://www.dsignt.de/products/dmodule/d6713.htm including a
> bios/bootloader by the same company.
>
> I am having a repeatability problem when debugging code that is using
> interrupts. The issue that I see is that the code uses both timers,
> though only one has an interrupt handler installed, I believe the other
> timer is used for signaling an outside device. I have recently changed
> so that the serial port input is handled via interrupts instead of
> polling.
>
> I have gone through the code to make sure that I'm initializing all of
> my variables.
>
> I am developing this in code composer studio.
>
> I reset the CPU and let the processor run free, to make sure that the
> bios has had a chance to initialize anythign it needs to do. I then do
> a compile and load of my program in the code composer studio. (I have
> it set to automaticaly load the program when it successfuly builds the
> project.) About half the time It doesn't respond to interrupts on the
> UART. Simply halting and reloading the program makes it respond to UART
> interrupts. When it is responding to UART interrupts it's not
> responding to timer interrupts.
Is this with CCS v3.1? If so, what we found is the "auto load" function
may have some timing issue. We found it to be more reliable to download
the program manually, and *always* make sure the previous run has been
halted and a Reset CPU has been performed.
Also it helped that all TI patches were downloaded and installed for v3.1.
Even with this, we still have not reached the same "each download performs
the same every time" reliability as we have for CCS v2.2x.
-Jeff
Reply by ●August 22, 20062006-08-22
Wim-
> I am using CCS 3.1.23, and I believe I have installed all of the
> updates, though I always get confused when I visit the TI site as to
> which items have been installed, and which might need to be installed or
> reinstalled.
Ok.
> It's good to know of one more example of the tools for dsp development
> not being up to the standards I've come to expect from software
> development in general.
Well please don't mis-understand me. I think CCS is an excellent package:
full-featured, easy-to-use, and for the most part reliable and
dependable. CCS pretty much dominates other DSP and FPGA development IDEs
I've seen (which is at this point is a couple of dozen). The debug /
hardware aspects of a cross-environment IDE are always the most difficult
for a chip vendor to implement flawlessly, plus TI has a wide range of
chips and emulators to support. For example, we didn't see the same
inconsistencies with our C641x boards as we did with C6711/13.
That said, it would be nice if upgrading from v2.2x to v3.1 didn't cause
any new hiccups to appear. For our C671x development we're staying with
v2.2x in the lab currently until v3.2 is more reliable. But for C55x and
C64x, we've moved to v3.1/v3.2.
-Jeff
> I am using CCS 3.1.23, and I believe I have installed all of the
> updates, though I always get confused when I visit the TI site as to
> which items have been installed, and which might need to be installed or
> reinstalled.
Ok.
> It's good to know of one more example of the tools for dsp development
> not being up to the standards I've come to expect from software
> development in general.
Well please don't mis-understand me. I think CCS is an excellent package:
full-featured, easy-to-use, and for the most part reliable and
dependable. CCS pretty much dominates other DSP and FPGA development IDEs
I've seen (which is at this point is a couple of dozen). The debug /
hardware aspects of a cross-environment IDE are always the most difficult
for a chip vendor to implement flawlessly, plus TI has a wide range of
chips and emulators to support. For example, we didn't see the same
inconsistencies with our C641x boards as we did with C6711/13.
That said, it would be nice if upgrading from v2.2x to v3.1 didn't cause
any new hiccups to appear. For our C671x development we're staying with
v2.2x in the lab currently until v3.2 is more reliable. But for C55x and
C64x, we've moved to v3.1/v3.2.
-Jeff
Reply by ●August 22, 20062006-08-22
Jeff Brower wrote:
>> I am having a problem programming a board that is based on the 6713
>> dsp. The hardware was not developed by me, and is based on a board
>> similar to http://www.dsignt.de/products/dmodule/d6713.htm including a
>> bios/bootloader by the same company.
>>
>> I am having a repeatability problem when debugging code that is using
>> interrupts. The issue that I see is that the code uses both timers,
>> though only one has an interrupt handler installed, I believe the other
>> timer is used for signaling an outside device. I have recently changed
>> so that the serial port input is handled via interrupts instead of
>> polling.
>>
>> I have gone through the code to make sure that I'm initializing all of
>> my variables.
>>
>> I am developing this in code composer studio.
>>
>> I reset the CPU and let the processor run free, to make sure that the
>> bios has had a chance to initialize anythign it needs to do. I then do
>> a compile and load of my program in the code composer studio. (I have
>> it set to automaticaly load the program when it successfuly builds the
>> project.) About half the time It doesn't respond to interrupts on the
>> UART. Simply halting and reloading the program makes it respond to UART
>> interrupts. When it is responding to UART interrupts it's not
>> responding to timer interrupts.
>>
>
> Is this with CCS v3.1? If so, what we found is the "auto load" function
> may have some timing issue. We found it to be more reliable to download
> the program manually, and *always* make sure the previous run has been
> halted and a Reset CPU has been performed.
>
> Also it helped that all TI patches were downloaded and installed for v3.1.
>
> Even with this, we still have not reached the same "each download performs
> the same every time" reliability as we have for CCS v2.2x.
>
> -Jeff
>
I am using CCS 3.1.23, and I believe I have installed all of the
updates, though I always get confused when I visit the TI site as to
which items have been installed, and which might need to be installed or
reinstalled.
It's good to know of one more example of the tools for dsp development
not being up to the standards I've come to expect from software
development in general.
>> I am having a problem programming a board that is based on the 6713
>> dsp. The hardware was not developed by me, and is based on a board
>> similar to http://www.dsignt.de/products/dmodule/d6713.htm including a
>> bios/bootloader by the same company.
>>
>> I am having a repeatability problem when debugging code that is using
>> interrupts. The issue that I see is that the code uses both timers,
>> though only one has an interrupt handler installed, I believe the other
>> timer is used for signaling an outside device. I have recently changed
>> so that the serial port input is handled via interrupts instead of
>> polling.
>>
>> I have gone through the code to make sure that I'm initializing all of
>> my variables.
>>
>> I am developing this in code composer studio.
>>
>> I reset the CPU and let the processor run free, to make sure that the
>> bios has had a chance to initialize anythign it needs to do. I then do
>> a compile and load of my program in the code composer studio. (I have
>> it set to automaticaly load the program when it successfuly builds the
>> project.) About half the time It doesn't respond to interrupts on the
>> UART. Simply halting and reloading the program makes it respond to UART
>> interrupts. When it is responding to UART interrupts it's not
>> responding to timer interrupts.
>>
>
> Is this with CCS v3.1? If so, what we found is the "auto load" function
> may have some timing issue. We found it to be more reliable to download
> the program manually, and *always* make sure the previous run has been
> halted and a Reset CPU has been performed.
>
> Also it helped that all TI patches were downloaded and installed for v3.1.
>
> Even with this, we still have not reached the same "each download performs
> the same every time" reliability as we have for CCS v2.2x.
>
> -Jeff
>
I am using CCS 3.1.23, and I believe I have installed all of the
updates, though I always get confused when I visit the TI site as to
which items have been installed, and which might need to be installed or
reinstalled.
It's good to know of one more example of the tools for dsp development
not being up to the standards I've come to expect from software
development in general.
Reply by ●August 23, 20062006-08-23
Jeff Brower wrote:
> Wim wrote:
>> It's good to know of one more example of the tools for dsp development
>> not being up to the standards I've come to expect from software
>> development in general.
>>
>
> Well please don't mis-understand me. I think CCS is an excellent package:
> full-featured, easy-to-use, and for the most part reliable and
> dependable. CCS pretty much dominates other DSP and FPGA development IDEs
> I've seen (which is at this point is a couple of dozen). The debug /
> hardware aspects of a cross-environment IDE are always the most difficult
> for a chip vendor to implement flawlessly, plus TI has a wide range of
> chips and emulators to support. For example, we didn't see the same
> inconsistencies with our C641x boards as we did with C6711/13.
>
> That said, it would be nice if upgrading from v2.2x to v3.1 didn't cause
> any new hiccups to appear. For our C671x development we're staying with
> v2.2x in the lab currently until v3.2 is more reliable. But for C55x and
> C64x, we've moved to v3.1/v3.2.
>
I think my issue is mainly that the embedded device development
environments in general are behind those that are available for general
software development.
After saying that, I've changed something in one of my linked projects,
and now when I build the project CCS Opens a new window tab named
"Consultant" with the following error message in it. I can't figure out
what is causing it, or what it might mean.
> 08/22/2006 01:30:21 PM
> Profile Server error while calling m_DataServer.TableCreate.
> 'Overwrite Error'
This is a tab in the same child window as the "Build" and "Messages"
tabs, but I've realized that I can't figure out how to close individual
tabs either. now that this tab has shown up, the stdout tab doesn't
seem to be showing up. (I can't remember what the name of the tab that
stdout and stderr text shows up in.)
If I exit the entire environment it will reset back to the defaults, but
then I lose my breakpoints, toolbar placement, and window set up.
Wim.
> Wim wrote:
>> It's good to know of one more example of the tools for dsp development
>> not being up to the standards I've come to expect from software
>> development in general.
>>
>
> Well please don't mis-understand me. I think CCS is an excellent package:
> full-featured, easy-to-use, and for the most part reliable and
> dependable. CCS pretty much dominates other DSP and FPGA development IDEs
> I've seen (which is at this point is a couple of dozen). The debug /
> hardware aspects of a cross-environment IDE are always the most difficult
> for a chip vendor to implement flawlessly, plus TI has a wide range of
> chips and emulators to support. For example, we didn't see the same
> inconsistencies with our C641x boards as we did with C6711/13.
>
> That said, it would be nice if upgrading from v2.2x to v3.1 didn't cause
> any new hiccups to appear. For our C671x development we're staying with
> v2.2x in the lab currently until v3.2 is more reliable. But for C55x and
> C64x, we've moved to v3.1/v3.2.
>
I think my issue is mainly that the embedded device development
environments in general are behind those that are available for general
software development.
After saying that, I've changed something in one of my linked projects,
and now when I build the project CCS Opens a new window tab named
"Consultant" with the following error message in it. I can't figure out
what is causing it, or what it might mean.
> 08/22/2006 01:30:21 PM
> Profile Server error while calling m_DataServer.TableCreate.
> 'Overwrite Error'
This is a tab in the same child window as the "Build" and "Messages"
tabs, but I've realized that I can't figure out how to close individual
tabs either. now that this tab has shown up, the stdout tab doesn't
seem to be showing up. (I can't remember what the name of the tab that
stdout and stderr text shows up in.)
If I exit the entire environment it will reset back to the defaults, but
then I lose my breakpoints, toolbar placement, and window set up.
Wim.
