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...
Data adquisition for the C32 with the tlc2552
Started by ●June 2, 2005
Reply by ●June 3, 20052005-06-03
Hello Mauricio!
> 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
> 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 ●June 13, 20052005-06-13
Hello Mauricio
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.
Hope this helps
Best regards
Keith Larson
DSP and Analog Consultant
Lincoln Ma
k...@comcast.net
http://home.comcast.net/~klarsondsp/
m_zapateiro wrote:
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.
Hope this helps
Best regards
Keith Larson
DSP and Analog Consultant
Lincoln Ma
k...@comcast.net
http://home.comcast.net/~klarsondsp/
m_zapateiro wrote:
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...@ieee.org
NEW! You can now post a message or access and search the archives of this group on DSPRelated.com:
http://www.dsprelated.com/groups/c3x/1.php
_____________________________________
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:
Archives: http://www.dsprelated.com/groups/c3x/1.php
To Post: Send an email to c...@yahoogroups.com
Other DSP Related Groups: http://www.dsprelated.com/groups.php
Reply by ●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).
Hope this helps
Best regards
Keith Larson
DSP and Analog Consultant
Lincoln Ma
k...@comcast.net
http://home.comcast.net/~klarsondsp/
Lyle Johnson wrote:
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).
Hope this helps
Best regards
Keith Larson
DSP and Analog Consultant
Lincoln Ma
k...@comcast.net
http://home.comcast.net/~klarsondsp/
Lyle Johnson wrote:
Hello Mauricio!
> 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
NEW! You can now post a message or access and search the archives of this group on DSPRelated.com:
http://www.dsprelated.com/groups/c3x/1.php
_____________________________________
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:
Archives: http://www.dsprelated.com/groups/c3x/1.php
To Post: Send an email to c...@yahoogroups.com
Other DSP Related Groups: http://www.dsprelated.com/groups.php
Reply by ●June 13, 20052005-06-13
Hello Keith!
> 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
> 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
