This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS debugging DSP6747 project

Other Parts Discussed in Thread: OMAP-L137

I'm seeing two things I can't explain. I'm trying to implement some algorithms that work on the OMAP-L137 on the DSP side in a DSP only project.

1. If I call TSK_sleep(10), the idle task gets control, but I never see the ticks that would allow other sleeping tasks to get control. If I explicitly add calls to TSK_tick alternating with TSK_yield, I do see ticks. Is it possible that I've somehow disabled the tick function?

2. When I force my way past 1, I see some bad calculations for Uint32s. When I made the change, it was recommended that I switch to the bios std.h rather than the xdc/std.h. I made that change, but UInt32 (and similarly capitalized types) became unknown types, so I added

#typedef Uint32 UInt32

etc

to a header file. Now when I set variables of this type, I get unexpected resoluts. For example, when I store

(UInt32)((double)1000000 * 0.07) to one of the variables, it stores 65536. Note that it is not restricted to 16 bits. I can use the debugger to store 70000 in the variable, but the next time it copies the value to another UInt32, it transmutes to 65536 again.

Can anyone help fix either of these problems?

  • No replies on that. Let's start with something basic: what causes the ticks that would eventually down-count the TSK_sleep counter? (I'm using object viewer and I see no evidence of the count decrementing unless I call TSK_tick.)

    That is, what function name would I find in my map? Can I put a breakpoint there? Could I have accidently disabled it?