> The usual serial port culprit is not lost
interrutps but over or under
> run conditions. These in turn can cause the data to become skewed as it
> comes in or out of a serial port. My preference (as I just mentioned in
> another post) is also to use 'clock it and forget it' devices on
the
> serial ports.
This confirms what I thought I was observing, which is that the 'C3x
serial port is "primitive" and not very robust under interrupts.
In my design, I have four ADC sources and two DAC sinks. Three of the
ADCs run at one clock rate and the fourth runs at a different rate, so I
am dynamically switching the clock to the serial port as well. Doing it
in an FPGA which is verified to be "glitchless" and all clocks derived
from the same source so there is no phase or frequency drift.
I also have two other interrupt sources that must be active and are
asynchronous to the serial port events. Dealing with these is where I
got into trouble, but sorted out a patch that appears to work.
> The other thing that comes to mind is if you are
trying to nest
> interrupts. In this case setting and clearing the GIE bit needs to
> follow some guidlines. This had been changed in the most recent C3x
> Users guide so you may want to get that UG from the TI site. You will
> know when you find it because this UG also contains references to the
> VC33 (every place a C31 reference was made, it became C31/VC33).
I have the newer version, but usually use the old one since I have it in
paper form. I'll print out and use the newer version's interrupt
section.
Thank you for the tip, Keith!
Regards,
Lyle Johnson
Reply by Keith Larson●June 13, 20052005-06-13
Hi Lyle
The usual serial port culprit is not lost interrutps but over or under
run conditions. These in turn can cause the data to become skewed as
it comes in or out of a serial port. My preference (as I just
mentioned in another post) is also to use 'clock it and forget it'
devices on the serial ports.
The other thing that comes to mind is if you are trying to nest
interrupts. In this case setting and clearing the GIE bit needs to
follow some guidlines. This had been changed in the most recent C3x
Users guide so you may want to get that UG from the TI site. You will
know when you find it because this UG also contains references to the
VC33 (every place a C31 reference was made, it became C31/VC33).
> I'm working in the development of a tm320c32
board. We make the
data > adquisition with a tlc2552 using the serial port
to transfer the
> samples. We have configured the registers of the DSP serial port
with > the same values used the example included in the
TI application
note > SLAA111. The hardware configuration we are using
for the ADC is
like > the une included in the figure 9. The DSP C test
program works
well > if we don't configure the serial port and use
the other periferals
> (the XF1, XF0, and timers), but when we configure
the serial port
the > DSP runs the program in a crazy way (we can't
see the signal
expected > in the XF0, XF1 and timer outputs) and the serial
port works
> sometimes. We have verified that the problem resides in the serial
> port (if we don't use it the program works
perfectly!). What is
wrong > in our program?
I am working on a TMS320VC33 project and discovered that the ADC
interrupt became unreliable if another interrupt occurred during the
instant that the ADC interrupt was asserted. The DAC interrupts were
all serviced fine, even if there was a time overlap of the type that
killed the ADC.
I worked around this by putting in a tiny piece of code that looks to
see if the ADC interrupt was expected; if so, it executes the interrupt
service routine.
_____________________________________
Note: If you do a simple "reply" with your email client, only the
author of this message will receive your answer. You need to do a
"reply all" if you want your answer to be distributed to the entire
group.
_____________________________________
About this discussion group:
The usual serial port culprit is an over or under run condition.
Basically if your program fails to meet real time requirements the
serial port will shut down. My preference is to have both the transmit
and receive running at the same rate and use only one (receive)
interrupt coming from a device that is NOT configured from its serial
port. Basically, if the external device is a simple state machine, it
will always clock the receive serial port so the only thing that can go
wrong is not servicing the receive interrupt in time. Basically you
can get a glitch in the data, but the interrupt is not lost.
This type of scenario is fairly common in the DSK where the
communications interface with the PC can gobble up huge swaths of
time. This becomes especially interesting when a background task like
a serial port could effectively eat away your entire stack space in a
fraction of a second. That is, suppose the debugger halts the
application, but not the serial port? As a result, the communications
kernel disables these processes before application code is allowed to
resume.
The JTAG and MPSD emulators dont really solve this issue either (for
any TI device), but rather tend to hide the problem. In the JTAG/MPSD
case when the CPU is halted the emulator halts the clocks going to (and
from) the CPU *and* its peripherals effectively halting any serial bit
transfers, pipeline activity etc... dead in its tracks. When emulation
resumes, the peripheral clocks are reconnected and everything resumes.
This is rather slick and a very cool way to go about debugging. BUT
YOU OWE IT TO YOURSELF TO KNOW THIS IS WHAT IS GOING ON! IMO with a
JTAG/MPSD emulator you dont really *know* if your ISR's are truly
robust and can withstand a fault or two. On the other hand, a DSK like
comm/debug kernel beats the crap out of the serial port 'robustness',
so if your applications survives this you are generally doing pretty
good.
By the way, this can also be related back to serial programmed
devices. Have you ever considered what happens with a serial
programmed codec if the programmation commands are a bit or two out of
synch? Answer: Usually bad things. IMO serial programmed devices can
be a dumb idea. I prefer the 'clock it and forget it' strategy,
or at
least something that recovers nicely.
I'm working in the development of a tm320c32 board. We make the data
adquisition with a tlc2552 using the serial port to transfer the
samples. We have configured the registers of the DSP serial port with
the same values used the example included in the TI application note
SLAA111. The hardware configuration we are using for the ADC is like
the une included in the figure 9. The DSP C test program works well
if we don't configure the serial port and use the other periferals
(the XF1, XF0, and timers), but when we configure the serial port the
DSP runs the program in a crazy way (we can't see the signal expected
in the XF0, XF1 and timer outputs) and the serial port works
sometimes. We have verified that the problem resides in the serial
port (if we don't use it the program works perfectly!). What is wrong
in our program?
I'll wait for your valuable advice.
Thanks a lot.
Mauricio Zapateiro De la Hoz
Barranquilla, Colombia
m...@ieee.org
_____________________________________
Note: If you do a simple "reply" with your email client, only the
author of this message will receive your answer. You need to do a
"reply all" if you want your answer to be distributed to the entire
group.
_____________________________________
About this discussion group:
> I'm working in the development of a tm320c32
board. We make the data
> adquisition with a tlc2552 using the serial port to transfer the
> samples. We have configured the registers of the DSP serial port with
> the same values used the example included in the TI application note
> SLAA111. The hardware configuration we are using for the ADC is like
> the une included in the figure 9. The DSP C test program works well
> if we don't configure the serial port and use the other periferals
> (the XF1, XF0, and timers), but when we configure the serial port the
> DSP runs the program in a crazy way (we can't see the signal expected
> in the XF0, XF1 and timer outputs) and the serial port works
> sometimes. We have verified that the problem resides in the serial
> port (if we don't use it the program works perfectly!). What is wrong
> in our program?
I am working on a TMS320VC33 project and discovered that the ADC
interrupt became unreliable if another interrupt occurred during the
instant that the ADC interrupt was asserted. The DAC interrupts were
all serviced fine, even if there was a time overlap of the type that
killed the ADC.
I worked around this by putting in a tiny piece of code that looks to
see if the ADC interrupt was expected; if so, it executes the interrupt
service routine.
Perhaps this may help your problem.
Lyle Johnson
Reply by m_zapateiro●June 2, 20052005-06-02
Greetings.
I'm working in the development of a tm320c32 board. We make the data
adquisition with a tlc2552 using the serial port to transfer the
samples. We have configured the registers of the DSP serial port with
the same values used the example included in the TI application note
SLAA111. The hardware configuration we are using for the ADC is like
the une included in the figure 9. The DSP C test program works well
if we don't configure the serial port and use the other periferals
(the XF1, XF0, and timers), but when we configure the serial port the
DSP runs the program in a crazy way (we can't see the signal expected
in the XF0, XF1 and timer outputs) and the serial port works
sometimes. We have verified that the problem resides in the serial
port (if we don't use it the program works perfectly!). What is wrong
in our program?
I'll wait for your valuable advice.
Thanks a lot.
Mauricio Zapateiro De la Hoz
Barranquilla, Colombia
m_zapateiro@m_za...