|
Keith,
Thanks
for your reply. The problem ended up being an extra instruction in the
vector/branch table. I was using zeros to fill the table out with, and the
instruction before the actual interrupt branch was being called. Zero maps
to "ABSF R0", which was what was causing the strange behavior I was
seeing.
Moral of
the story: be sure you set up your vector map correctly. It
doesn't hurt to TRAP all interrupts you're not defining
either.
Bill
Hi Bill
I dont recall ever having such a prblem, but I
ran it never the less. But without the problem you mention. But I also
used a DSK rather then the JTAG emulator.
What I suspect is going on
is that you may have installed the tools, but not the service pack that goes
with them. If you go to the Code Composer page for the C3x/VC33 you will
find a download link for the service pack.
http://focus.ti.com/docs/toolsw/folders/print/codecomposer.html
You
could also have some other things going on behind the scene. Your comments lead
me to think that you noticed this behaviour when trying to step over the
TRAPZ. In this case the debugger sets an SWI instruction after the TRAPZ
and then tries to 'run' to that point. With the interrupts
re-enabled within the trap it is quite possible that you ran another interrupt
between.
Take a look at the IE register... Any other
INT's enabled? Also you could get a hint of this action if you look
at the number of cycles the trap takes to step.
If this does not
work, then maybe there is a real issue with the emulation. This would not
be out of the question either as I know a little bit about how this works.
Basically a JTAG EMU differs (rather radically) from kernel mode emulation (like
a DSK) in that it can literally stop, start and manipulate the CPU clocks at a
whim. Furthermore, as the CPU is stopped the emulator is secretly moving
information in and out of the CPU pipeline and registers. In fact to do a
memory upload or download, the operation is to scan in a LDI||LDI or STI||STI
instruction, step it and then shift the data in or out via JTAG to the PC.
The problems occur when you have other things going on in the pipe. By
TMS320 standards the C3x is pretty mundane, but I am sure a few boundary
conditions (try to imagine all the possible combinations of opcodes and events)
still occur from time to time.
So, if you are still having
trouble,
-Set a BP within the TRAP and step through. Maybe you
spy something else?
-Try setting a BP after, or an infinite loop, and
use the 'Free Run' command. 'Free run' is a bit
different in that EMU background monitoring and other 'safety
controls' are suspended.
-Set BP's in all of the other
interrupts
-Check for floating pins. Why? Consider
for example the MCBL/MP pin. If this pin is floating the interrupt vector
that is fetched could be internal or external depending on the direction of the
wind. Otherwise, as long as your program stays outside of 0-0x1000 you
would never know. The older C30/C31/C32 line was notorious for this
because these devices also included internal pullup R's. And when
customers used external pulldown R's, they basically created a voltage
divider. A simple fix but a lot of customers pulled out a lot of hair.
- Consider also that 0x7F7FFFFFFF is the maximum positive float
value. Maybe a saturation effect?
By the way, sorry to drop
into the group and then quickly back out, but I wont be around until Saturday of
next week.
Best regards
Keith Larson
DSP and Analog
Consulting
Lincoln, Ma
rpgamer321 wrote:
I'm seeing a strange problem while restoring R0 on the VC33.
The code
I'm trying to run is similar to this:
.data
x .word 080000000h
...
main LDI @x, R0
... ; do some
work that doesn't involve R0
CMPI @x, R0
TRAPZ 16
B main
...
intfun
PUSH ST
PUSH FP
LDI SP, FP
...
; do work that does not use R0
POP FP
POP ST
RETIU
The trap is hit
when the interrupt occurs near the end of the main
block of code.
Looking at the registers, R0 is strangely set to:
7F 7FFFFFFF
Any ideas?
Bill
|