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 |
|
Register Restore Error
Started by ●September 20, 2004
Reply by ●September 23, 20042004-09-23
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 |
|
Reply by ●September 23, 20042004-09-23
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
|
|
Reply by ●October 3, 20042004-10-03
Hi Bill Glad to hear that you figured this out. Which brings up an interesting architectural feature of the C3x that relates to TRAP instructions. If you look at the binary value of a TRAP it is something like 0x5000001x (I did not look up the actual code). The part of this to notice is that if the '1' where '0', TRAP's would begin at offset '0' in the interupt table... and they do. For example if ASM30 would accept the code 'TRAP -16' you could trap to the reset vector, TRAP -15 would be INT0 and so on. But ASM30 generates an error so you will need to use a macro instead. Another point of interest is that there is no second serial port on the C31/VC33 (the C30 has two), but guess what... those IF and IE bits do exist and those interrupts are still valid. I used them with the C31/VC33 DSK comm/debug kernel :-) Best regards Keith Larson DSP and Analog Consulting Lincoln, Ma ---------------------------------- Bill Finger wrote:
|