AD535 | BIOS | Booting | Bootloader | C621 | C6211 | C6415 | C671 | C6711 | C6711DSK | C6713 | CCS | Chassaing | COFF | DAT | DM64 | DM642 | DMA | DSK671 | DSK6711 | EDM | EDMA | EMIF | Emulator | EVM | EVM620 | FFT | FIR | GPIO | Halting | HPI | HWI | IDK | JTAG | LDB | LDH | LDW | Linker | LMS | LOG_printf | Matlab | McBSP | MEM_alloc | MIPS | PCI | PCM3003 | Pipeline | Profiling | QDM | Reset | ROM | RTDX | Sampling | SDRAM | Stack | TEB | THS1206 | TMS320C621 | TMS320C6416 | TMS320C6711 | TMS320C6713 | UART | Vector Table | XBUS | XDS560

Hi

I have my code built and loaded to my C672X board. However, when I hit RUN button, it doesn't
run at all. By that I mean the RUN button does work, but it halted right away. From the
disassembly window, I can see it runs two to three instructions each time I hit the RUN button.
But there is no change at all on any variable when I observe the memory. It seems like it just
jumps two to three instructions each time the RUN button hit and doing nothing.

The hardware is fine. The input powers' level are currect for DVDD, CVDD & PLLHV. The
oscillator is running. The EMIF clock is running. The reset is at high. The emulator clock is
running.

The software is fine. The emulator is properly connected to the target board. The CCS can
detect the target silicon version. All chip registers, on-chip memories and SDRAM are
accessible by CCS. The code is complied without bug. The code is a very simple test code, which
runs well on the CCS cpu simulator. I have no clue what's going on. Anyone have any idea what
might be going wrong? All suggestions are welcome. Any help would be appreciated.

Thanks

Peter 

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Peter-

> I have my code built and loaded to my C672X board. However, when I hit
> RUN button, it doesn't run at all. By that I mean the RUN button does work,
> but it halted right away. From the disassembly window, I can see it runs
> two to three instructions each time I hit the RUN button. But there is no
> change at all on any variable when I observe the memory. It seems like it
> just jumps two to three instructions each time the RUN button hit and
> doing nothing.
> 
> The hardware is fine. The input powers' level are currect for DVDD, CVDD
> & PLLHV. The oscillator is running. The EMIF clock is running. The reset
> is at high. The emulator clock is running.
> 
> The software is fine. The emulator is properly connected to the target
> board. The CCS can detect the target silicon version. All chip registers,
> on-chip memories and SDRAM are accessible by CCS. The code is complied
> without bug. The code is a very simple test code, which runs well on the
> CCS cpu simulator. I have no clue what's going on. Anyone have any idea
> what might be going wrong? All suggestions are welcome. Any help would
> be appreciated.

So you want to "Run" before you can crawl :-)  Why aren't you using that 'other
button' (single-step)?  Let only one instruction run at a time, go step-by-step and
observe the processor state carefully afer each.  You will soon find whatever is
wrong.

-Jeff

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Peter-
> Thanks for your reply.The Run button is already doing two to three instructions at
> a time, and not really execute anything.I have try signal-step, but the result is
> still the same. It can't be the code problem. The test code is just too simple to
> have mistake. Is posible there any register setup problem can cause this situation?

There could be many different problems.  But why are we guessing?  It's a simple
debug process.

Just make the first instruction a NOP, and then do just ONE single-step.  What
happens?

If you can't figure out this much, then you're in over your head and you need to back
way up and do some tutorials, DSK examples, etc.

-Jeff

PS. Please post to the group, not to me.
> 2008/5/16 Jeff Brower <j...@signalogic.com>:
>
>      Peter-
>
>      > I have my code built and loaded to my C672X board. However, when I hit
>      > RUN button, it doesn't run at all. By that I mean the RUN button does
>      work,
>      > but it halted right away. From the disassembly window, I can see it
>      runs
>      > two to three instructions each time I hit the RUN button. But there is
>      no
>      > change at all on any variable when I observe the memory. It seems like
>      it
>      > just jumps two to three instructions each time the RUN button hit and
>      > doing nothing.
>      >
>      > The hardware is fine. The input powers' level are currect for DVDD,
>      CVDD
>      > & PLLHV. The oscillator is running. The EMIF clock is running. The
>      reset
>      > is at high. The emulator clock is running.
>      >
>      > The software is fine. The emulator is properly connected to the target
>      > board. The CCS can detect the target silicon version. All chip
>      registers,
>      > on-chip memories and SDRAM are accessible by CCS. The code is complied
>      > without bug. The code is a very simple test code, which runs well on
>      the
>      > CCS cpu simulator. I have no clue what's going on. Anyone have any idea
>
>      > what might be going wrong? All suggestions are welcome. Any help would
>      > be appreciated.
>
>      So you want to "Run" before you can crawl :-)  Why aren't you using that
>      'other
>      button' (single-step)?  Let only one instruction run at a time, go
>      step-by-step and
>      observe the processor state carefully afer each.  You will soon find
>      whatever is
>      wrong.
>
>      -Jeff
>

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Jeff

ONE single-step does nothing, just like RUN.

Peter

Hi
>
>I have my code built and loaded to my C672X board. However, when I hit RUN button, it
doesn't run at all. By that I mean the RUN button does work, but it halted right away. From the
disassembly window, I can see it runs two to three instructions each time I hit the RUN button.
But there is no change at all on any variable when I observe the memory. It seems like it just
jumps two to three instructions each time the RUN button hit and doing nothing.
>
>The hardware is fine. The input powers' level are currect for DVDD, CVDD & PLLHV. The
oscillator is running. The EMIF clock is running. The reset is at high. The emulator clock is
running.
>
>The software is fine. The emulator is properly connected to the target board. The CCS can
detect the target silicon version. All chip registers, on-chip memories and SDRAM are
accessible by CCS. The code is complied without bug. The code is a very simple test code, which
runs well on the CCS cpu simulator. I have no clue what's going on. Anyone have any idea what
might be going wrong? All suggestions are welcome. Any help would be appreciated.
>
>Thanks
>
>Peter 
>
>------------------------------------
>
>OMAP35x EVM jump-starts low-power apps
>------------------------------------
>The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start
building applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

am running a simple loop program on C6713 processor.Am storing the adc
values in array but when i plot the values it is giving wrong values.How the
values  read from the adc can be converted into proper float numbers

On Fri, May 16, 2008 at 7:07 PM, Jeff Brower <j...@signalogic.com> wrote:

>   Peter-
> > I have my code built and loaded to my C672X board. However, when I hit
> > RUN button, it doesn't run at all. By that I mean the RUN button does
> work,
> > but it halted right away. From the disassembly window, I can see it runs
> > two to three instructions each time I hit the RUN button. But there is no
> > change at all on any variable when I observe the memory. It seems like it
> > just jumps two to three instructions each time the RUN button hit and
> > doing nothing.
> >
> > The hardware is fine. The input powers' level are currect for DVDD, CVDD
> > & PLLHV. The oscillator is running. The EMIF clock is running. The reset
> > is at high. The emulator clock is running.
> >
> > The software is fine. The emulator is properly connected to the target
> > board. The CCS can detect the target silicon version. All chip registers,
> > on-chip memories and SDRAM are accessible by CCS. The code is complied
> > without bug. The code is a very simple test code, which runs well on the
> > CCS cpu simulator. I have no clue what's going on. Anyone have any idea
> > what might be going wrong? All suggestions are welcome. Any help would
> > be appreciated.
>
> So you want to "Run" before you can crawl :-) Why aren't you using that
> 'other
> button' (single-step)? Let only one instruction run at a time, go
> step-by-step and
> observe the processor state carefully afer each. You will soon find
> whatever is
> wrong.
>
> -Jeff
>  
>

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Peter-

> ONE single-step does nothing, just like RUN.

Was your first instruction a NOP?  And the little yellow arrow in CCS is pointing to
the next (second) instruction?

-Jeff
> Hi
> >
> >I have my code built and loaded to my C672X board. However, when I hit RUN button, it
doesn't run at all. By that I mean the RUN button does work, but it halted right away. From the
disassembly window, I can see it runs two to three instructions each time I hit the RUN button.
But there is no change at all on any variable when I observe the memory. It seems like it just
jumps two to three instructions each time the RUN button hit and doing nothing.
> >
> >The hardware is fine. The input powers' level are currect for DVDD, CVDD & PLLHV.
The oscillator is running. The EMIF clock is running. The reset is at high. The emulator clock
is running.
> >
> >The software is fine. The emulator is properly connected to the target board. The CCS
can detect the target silicon version. All chip registers, on-chip memories and SDRAM are
accessible by CCS. The code is complied without bug. The code is a very simple test code, which
runs well on the CCS cpu simulator. I have no clue what's going on. Anyone have any idea what
might be going wrong? All suggestions are welcome. Any help would be appreciated.
> >
> >Thanks
> >
> >Peter

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Peter,

On 5/16/08, i...@gmail.com <i...@gmail.com> wrote:
>
>   Jeff
>
> ONE single-step does nothing, just like RUN.
>
> Peter
>

Let's start with the basics.
1. Does this happen with every program, or just one program??
2. Where does the PC point after a load??
3. Does the instruction packet that the PC points to consist of valid
instructions??
4. Are you loading into internal or external memory??

mikedunn

   Hi
> >
> >I have my code built and loaded to my C672X board. However, when I hit RUN
> button, it doesn't run at all. By that I mean the RUN button does work, but
> it halted right away. From the disassembly window, I can see it runs two to
> three instructions each time I hit the RUN button. But there is no change at
> all on any variable when I observe the memory. It seems like it just jumps
> two to three instructions each time the RUN button hit and doing nothing.
> >
> >The hardware is fine. The input powers' level are currect for DVDD, CVDD &
> PLLHV. The oscillator is running. The EMIF clock is running. The reset is at
> high. The emulator clock is running.
> >
> >The software is fine. The emulator is properly connected to the target
> board. The CCS can detect the target silicon version. All chip registers,
> on-chip memories and SDRAM are accessible by CCS. The code is complied
> without bug. The code is a very simple test code, which runs well on the CCS
> cpu simulator. I have no clue what's going on. Anyone have any idea what
> might be going wrong? All suggestions are welcome. Any help would be
> appreciated.
> >
> >Thanks
> >
> >Peter
> >
> >------------------------------------
> >
> >OMAP35x EVM jump-starts low-power apps
> >------------------------------------
> >The modular and extensible OMAP35x Evaluation Module (EVM) enables
> developers to start building applications based on the OMAP35x architecture:
>http://www.DSPRelated.com/omap35x
<http://www.dsprelated.com/omap35x>
> >
> >

-- 
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Hi Mikedunn

Really thanks for your reply.
1. It happens to every program.
2. The PC is point to 0x10002060 which is where the c_int00 is.
3. yes
4. I have tried to load the code into both internal or external memory, but the result is the
same.

By the way, I don't know if this matter, but I didn't use any gel file while running the
program. Would this cause the problem I have?

Thank you

Best regards
Peter

>Let's start with the basics.
>1. Does this happen with every program, or just one program??
>2. Where does the PC point after a load??
>3. Does the instruction packet that the PC points to consist of valid
>instructions??
>4. Are you loading into internal or external memory??

>mikedunn

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

iddqd,

The following is a slightly simplified technique for debugging the execution path
This is assuming the board is set to power up the CPU in microprocessor mode?

If you compile with full debug info..
Then load the code (be sure the .cmd file matches the addressing of the code)
Then click Debug/reset CPU
Then click View/Registers (check that the PC and SP registers are correct for a CPU reset)
Then click View/Call Stack
Then Click View/mixed Source/Asm
Then Click View/memory (setting the view address to the jump address in Flash)
Does the jump address contain the address of your program entry point?
If not your link needs tweaking
Then Click View/Memory (setting the view address to your main() function
Does your main function exist at the (.map file) indicated address?
If not, your link needs tweaking
otherwise..
Click Debug/Go Main
Check that the code actually stepped to the main() function.
(use the .map file and the PC register)
If the code executed to the main() function; use the F11 key to step through the code, one
instruction at a time
R. Williams

---------- Original Message -----------
From: i...@gmail.com
To: c...@yahoogroups.com
Sent: Fri, 16 May 2008 08:37:49 -0400
Subject: [c6x] C672X unable to Run

> Hi
> 
> I have my code built and loaded to my C672X board. However, when I hit RUN button, it 
> doesn't run at all. By that I mean the RUN button does work, but it halted right away. 
> From the disassembly window, I can see it runs two to three instructions each time I hit 
> the RUN button. But there is no change at all on any variable when I observe the memory. 
> It seems like it just jumps two to three instructions each time the RUN button hit and 
> doing nothing.
> 
> The hardware is fine. The input powers' level are currect for DVDD, CVDD & PLLHV. The

> oscillator is running. The EMIF clock is running. The reset is at high. The emulator clock

> is running.
> 
> The software is fine. The emulator is properly connected to the target board. The CCS can

> detect the target silicon version. All chip registers, on-chip memories and SDRAM are 
> accessible by CCS. The code is complied without bug. The code is a very simple test code,
>  which runs well on the CCS cpu simulator. I have no clue what's going on. Anyone have any

> idea what might be going wrong? All suggestions are welcome. Any help would be
appreciated.
> 
> Thanks
> 
> Peter
------- End of Original Message -------
------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Hi Richard

Thanks for the debuggubg technique you posted.

The PC points to the correct address when reseting the CPU and loading the program.
The stack looks right. It shows the instruction where the PC currently points to. 
The main() is inside the indicated address (from .map), it should be right.

But when I click the "Go Main", CCS gives the following error message:
{
Trouble Setting Breakpoint with the Action "Terminate GEL_Go()" at 0x10002120: Error
0x00000008/-2042 Error during: Break Point,  Cannot set/verify breakpoint at 0x10002120  
Sequence ID: 7 Error Code: -2042 Error Class: 0x00000008
Breakpoint Manager: Retrying with a Legacy Hardware breakpoint
}

I have done some research on this, but can't find any answer. 
Does anyone have an idea what might be going wrong?
P.S. I didn't use GEL file nor any berakpoint.

Best regards
Peter
>2008/5/17 Richard Williams <r...@lewiscounty.com>:
>iddqd,

>The following is a slightly simplified technique for debugging the >execution path
>This is assuming the board is set to power up the CPU in microprocessor >mode?
>
>If you compile with full debug info..
>Then load the code (be sure the .cmd file matches the addressing of the >code)
>Then click Debug/reset CPU
>Then click View/Registers (check that the PC and SP registers are correct >for a CPU
reset)
>Then click View/Call Stack
>Then Click View/mixed Source/Asm
>Then Click View/memory (setting the view address to the jump address in >Flash)
>Does the jump address contain the address of your program entry point?
>If not your link needs tweaking
>Then Click View/Memory (setting the view address to your main() function
>Does your main function exist at the (.map file) indicated address?
>If not, your link needs tweaking
>otherwise..
>Click Debug/Go Main
>Check that the code actually stepped to the main() function.
>(use the .map file and the PC register)
>If the code executed to the main() function; use the F11 key to step >through the code,
one
>instruction at a time
>R. Williams

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Peter-

> Thanks for the debuggubg technique you posted.
> 
> The PC points to the correct address when reseting the CPU and loading the program.
> The stack looks right. It shows the instruction where the PC currently points to.
> The main() is inside the indicated address (from .map), it should be right.
> 
> But when I click the "Go Main", CCS gives the following error message:
> {
> Trouble Setting Breakpoint with the Action "Terminate GEL_Go()" at 0x10002120:
Error 0x00000008/-2042 Error during: Break Point,  Cannot set/verify breakpoint at 0x10002120  
Sequence ID: 7 Error Code: -2042 Error Class: 0x00000008
> Breakpoint Manager: Retrying with a Legacy Hardware breakpoint
> }
> 
> I have done some research on this, but can't find any answer.
> Does anyone have an idea what might be going wrong?
> P.S. I didn't use GEL file nor any berakpoint.

When you click "Go Main" that uses a breakpoint.  From the sound of that error
message, I doubt that any code ran because CCS had trouble with the breakpoint.

What is the asm instruction the program counter points to after loading (at the
entry-point)?  I asked you this before.  I suggest that you list the first few asm
instructions, maybe they're not valid.  Also, did you try single-stepping the first
few instructions?  You should see the little yellow arrow move down one instruction
each time.  I made this suggestion before but it seems you still didn't try it.

Peter, if you click "Run" or "Go Main" then you're assuming that your board
works. 
But obviously it doesn't.  Probably you have some basic chip or hardware issue, not
too hard to fix, you just have to find it..  You may not like such low-level, tedious
debug work, and you may be hoping your board starts up and runs perfectly, but I can
tell you from experience that just never happens.

-Jeff

> >2008/5/17 Richard Williams <r...@lewiscounty.com>:
> 
> >iddqd,
> 
> >The following is a slightly simplified technique for debugging the >execution path
> >This is assuming the board is set to power up the CPU in microprocessor >mode?
> >
> >If you compile with full debug info..
> >Then load the code (be sure the .cmd file matches the addressing of the >code)
> >Then click Debug/reset CPU
> >Then click View/Registers (check that the PC and SP registers are correct >for a
CPU reset)
> >Then click View/Call Stack
> >Then Click View/mixed Source/Asm
> >Then Click View/memory (setting the view address to the jump address in >Flash)
> >Does the jump address contain the address of your program entry point?
> >If not your link needs tweaking
> >Then Click View/Memory (setting the view address to your main() function
> >Does your main function exist at the (.map file) indicated address?
> >If not, your link needs tweaking
> >otherwise..
> >Click Debug/Go Main
> >Check that the code actually stepped to the main() function.
> >(use the .map file and the PC register)
> >If the code executed to the main() function; use the F11 key to step >through the
code, one
> >instruction at a time
> >
> >
> >R. Williams

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

iddqd,

clicking 'go main' tries to set a break point at the address of main()

Have you looked at the contents of the first part of the main() function?
does it match the asm listing for the file that contains main()?

The CCS debug operation will use a default gel file (I do not remember just which one)

The program load operation uses a gel file to set the address space parameters
(read/write/execute)
These parameters must match the actual address space in the DSP.

The RAM (internal/external) usually needs a certain number of wait states implemented.
The default gel file should set those wait states appropriately, IF the correct DSP processor
is
selected during the CCS Setup function AND in the project/build options/basic/targetversion

IF any of these above selections are incorrect, then the correct selections need to be made and
then
recompile/link all the source code.

Are you including the RTS library in the project?
The RTS library contains the code function that is executed before main()

R. Williams

---------- Original Message -----------
From: i...@gmail.com
To: c...@yahoogroups.com
Sent: Sat, 17 May 2008 06:44:34 -0400
Subject: [c6x] Re: C672X unable to Run

> Hi Richard
> 
> Thanks for the debuggubg technique you posted.
> 
> The PC points to the correct address when reseting the CPU and loading the program.
> The stack looks right. It shows the instruction where the PC currently points to. 
> The main() is inside the indicated address (from .map), it should be right.
> 
> But when I click the "Go Main", CCS gives the following error message:
> {
> Trouble Setting Breakpoint with the Action "Terminate GEL_Go()" at 0x10002120:
Error 
> 0x00000008/-2042 Error during: Break Point,  Cannot set/verify breakpoint at 0x10002120  
>  Sequence ID: 7 Error Code: -2042 Error Class: 0x00000008 Breakpoint Manager: Retrying 
> with a Legacy Hardware breakpoint }
> 
> I have done some research on this, but can't find any answer. 
> Does anyone have an idea what might be going wrong?
> P.S. I didn't use GEL file nor any berakpoint.
> 
> Best regards
> Peter
> 
> >2008/5/17 Richard Williams <r...@lewiscounty.com>:
> 
> >iddqd,
> 
> >The following is a slightly simplified technique for debugging the >execution path
> >This is assuming the board is set to power up the CPU in microprocessor >mode?
> >
> >If you compile with full debug info..
> >Then load the code (be sure the .cmd file matches the addressing of the >code)
> >Then click Debug/reset CPU
> >Then click View/Registers (check that the PC and SP registers are correct >for a
CPU reset)
> >Then click View/Call Stack
> >Then Click View/mixed Source/Asm
> >Then Click View/memory (setting the view address to the jump address in >Flash)
> >Does the jump address contain the address of your program entry point?
> >If not your link needs tweaking
> >Then Click View/Memory (setting the view address to your main() function
> >Does your main function exist at the (.map file) indicated address?
> >If not, your link needs tweaking
> >otherwise..
> >Click Debug/Go Main
> >Check that the code actually stepped to the main() function.
> >(use the .map file and the PC register)
> >If the code executed to the main() function; use the F11 key to step >through the
code, one
> >instruction at a time
> >
> >
> >R. Williams
------- End of Original Message -------
------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Jeff

I don't think any code ran at all either. It would run for a second and then go off to no-where
land.

The asm instruction program counter points to is as follow:
10007E20 FFBBECDE            .word         0xffbbecde
10007E24 6BF3E25D     [ B2]  STH.D2T1      A23,*+B14[29666]
10007E28 FF656BDE ||         .word         0xff656bde
10007E2C B6FAB6BF     [!A2]  STB.D2T2      B13,*+B15[31414]
10007E30 C108D420 ||         .word         0xc108d420

Those are the first five instructions. Sorry I miss that part on your post before.

I did try the single-stepping the first few instructions. It doesn't execute anything. As I
answered to you in previous post. 
I can see a little green arrow move down.

Yes, Jeff, I do assume my board works, haha. Probably not a good idea. However, I did do a lot
hardware debug on this board. I see two new strange symptoms. 
1. The bit-5 of the PLLCSR register is reserved and can only reads as "0", according
to C672X DSP PLL datasheet. However, when I setup a GEL file to initiate the PLL, that bit
always reads as "1". There is no code accidentally pulling high that bit. 

2. The core supply (1.2V) current consumption of C6722 is 555mA at 250MHz, according to the
datasheet. But it only draw ~200mA when I increases the CPU speed to 250MHz. There is no short
circuit and there is plenty of current supplied. 
Do you have an idea what might be going wrong?
Thanks

Best regards

Peter
>Peter-
>
>When you click "Go Main" that uses a breakpoint.  From the sound of that
>error
>message, I doubt that any code ran because CCS had trouble with the >breakpoint.
>
>What is the asm instruction the program counter points to after loading >(at the
entry-point)?  I asked you this before.  I suggest that you list >the first few asm
>instructions, maybe they're not valid.  Also, did you try single-stepping >the first
>few instructions?  You should see the little yellow arrow move down one >instruction
>each time.  I made this suggestion before but it seems you still didn't >try it.
>
>Peter, if you click "Run" or "Go Main" then you're assuming that your
>board works. 
>But obviously it doesn't.  Probably you have some basic chip or hardware >issue, not
>too hard to fix, you just have to find it..  You may not like such low->level, tedious
>debug work, and you may be hoping your board starts up and runs >perfectly, but I can
>tell you from experience that just never happens.
>
>-Jeff

>
>> Thanks for the debuggubg technique you posted.
>> 
>> The PC points to the correct address when reseting the CPU and loading >the
program.
>> The stack looks right. It shows the instruction where the PC currently >points to.
>> The main() is inside the indicated address (from .map), it should be >right.
>> 
>> But when I click the "Go Main", CCS gives the following error message:
>> {
>> Trouble Setting Breakpoint with the Action "Terminate GEL_Go()" at
>0x10002120:
>Error 0x00000008/-2042 Error during: Break Point,  Cannot set/verify >breakpoint at
0x10002120  
>Sequence ID: 7 Error Code: -2042 Error Class: 0x00000008
>> Breakpoint Manager: Retrying with a Legacy Hardware breakpoint
>> }
>> 
>> I have done some research on this, but can't find any answer.
>> Does anyone have an idea what might be going wrong?
>> P.S. I didn't use GEL file nor any berakpoint.
>

> >2008/5/17 Richard Williams <r...@lewiscounty.com>:
> 
> >iddqd,
> 
> >The following is a slightly simplified technique for debugging the >execution
path
> >This is assuming the board is set to power up the CPU in microprocessor >mode?
> >
> >If you compile with full debug info..
> >Then load the code (be sure the .cmd file matches the addressing of the >code)
> >Then click Debug/reset CPU
> >Then click View/Registers (check that the PC and SP registers are correct >for a
CPU reset)
> >Then click View/Call Stack
> >Then Click View/mixed Source/Asm
> >Then Click View/memory (setting the view address to the jump address in >Flash)
> >Does the jump address contain the address of your program entry point?
> >If not your link needs tweaking
> >Then Click View/Memory (setting the view address to your main() function
> >Does your main function exist at the (.map file) indicated address?
> >If not, your link needs tweaking
> >otherwise..
> >Click Debug/Go Main
> >Check that the code actually stepped to the main() function.
> >(use the .map file and the PC register)
> >If the code executed to the main() function; use the F11 key to step >through the
code, one
> >instruction at a time
> >
> >
>> >R. Williams
------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Peter,

On 5/19/08, i...@gmail.com <i...@gmail.com> wrote:
>
>   Jeff
>
> I don't think any code ran at all either. It would run for a second and
> then go off to no-where land.
>
> The asm instruction program counter points to is as follow:
> 10007E20 FFBBECDE .word 0xffbbecde
> 10007E24 6BF3E25D [ B2] STH.D2T1 A23,*+B14[29666]
> 10007E28 FF656BDE || .word 0xff656bde
> 10007E2C B6FAB6BF [!A2] STB.D2T2 B13,*+B15[31414]
> 10007E30 C108D420 || .word 0xc108d420
>

I am not sure what is going on, but the instructions are "garbage".  The
reason that you only run a few instructions when you hit 'run' is that some
of the 'garbage instructions' have the breakpoint bit set.

The problem is likely in the code generation, library selection, or emulator
memory write process. Just to verify basic instruction execution, you can do
the following:

1. Fill 100 hex words of internal memory with 0s.
2. Set the PC to the begining of that filled memory.
3. Single step a few instructions - at least 8.
NOTE: The first step could be erratic/incorrect depending on what the DSP
was doing last.  If it is, just set the PC again and start over.
4. Set a breakpoint near the end of of the filled 0s.
5. Hit run. It should run to the BP.

   Those are the first five instructions. Sorry I miss that part on your
> post before.
>
> I did try the single-stepping the first few instructions. It doesn't
> execute anything. As I answered to you in previous post.
> I can see a little green arrow move down.
>
> Yes, Jeff, I do assume my board works, haha. Probably not a good idea.
> However, I did do a lot hardware debug on this board. I see two new strange
> symptoms.
> 1. The bit-5 of the PLLCSR register is reserved and can only reads as "0",
> according to C672X DSP PLL datasheet. However, when I setup a GEL file to
> initiate the PLL, that bit always reads as "1". There is no code
> accidentally pulling high that bit.
>
> 2. The core supply (1.2V) current consumption of C6722 is 555mA at 250MHz,
> according to the datasheet. But it only draw ~200mA when I increases the CPU
> speed to 250MHz. There is no short circuit and there is plenty of current
> supplied.
> Do you have an idea what might be going wrong?
>

The current on the 1.2v is dependent of CPU activity. Executing fully
parallelized packets that include FP instructions will raise the current
level.  You probably do not have a problem here.

mikedunn

   Thanks
>
> Best regards
>
> Peter
>
> >Peter-
> >
> >When you click "Go Main" that uses a breakpoint. From the sound of that
> >error
> >message, I doubt that any code ran because CCS had trouble with the
> >breakpoint.
> >
> >What is the asm instruction the program counter points to after loading
> >(at the entry-point)? I asked you this before. I suggest that you list >the
> first few asm
> >instructions, maybe they're not valid. Also, did you try single-stepping
> >the first
> >few instructions? You should see the little yellow arrow move down one
> >instruction
> >each time. I made this suggestion before but it seems you still didn't
> >try it.
> >
> >Peter, if you click "Run" or "Go Main" then you're assuming that
your
> >board works.
> >But obviously it doesn't. Probably you have some basic chip or hardware
> >issue, not
> >too hard to fix, you just have to find it.. You may not like such
> low->level, tedious
> >debug work, and you may be hoping your board starts up and runs
> >perfectly, but I can
> >tell you from experience that just never happens.
> >
> >-Jeff
>
> >
> >> Thanks for the debuggubg technique you posted.
> >>
> >> The PC points to the correct address when reseting the CPU and loading
> >the program.
> >> The stack looks right. It shows the instruction where the PC currently
> >points to.
> >> The main() is inside the indicated address (from .map), it should be
> >right.
> >>
> >> But when I click the "Go Main", CCS gives the following error message:
> >> {
> >> Trouble Setting Breakpoint with the Action "Terminate GEL_Go()" at
> >0x10002120:
> >Error 0x00000008/-2042 Error during: Break Point, Cannot set/verify
> >breakpoint at 0x10002120
> >Sequence ID: 7 Error Code: -2042 Error Class: 0x00000008
> >> Breakpoint Manager: Retrying with a Legacy Hardware breakpoint
> >> }
> >>
> >> I have done some research on this, but can't find any answer.
> >> Does anyone have an idea what might be going wrong?
> >> P.S. I didn't use GEL file nor any berakpoint.
> > > >2008/5/17 Richard Williams
<r...@lewiscounty.com<r...%40lewiscounty.com>>:
>
> >
> > >iddqd,
> >
> > >The following is a slightly simplified technique for debugging the
> >execution
> path
> > >This is assuming the board is set to power up the CPU in microprocessor
> >mode?
> > >
> > >If you compile with full debug info..
> > >Then load the code (be sure the .cmd file matches the addressing of the
> >code)
> > >Then click Debug/reset CPU
> > >Then click View/Registers (check that the PC and SP registers are
> correct >for a
> CPU reset)
> > >Then click View/Call Stack
> > >Then Click View/mixed Source/Asm
> > >Then Click View/memory (setting the view address to the jump address in
> >Flash)
> > >Does the jump address contain the address of your program entry point?
> > >If not your link needs tweaking
> > >Then Click View/Memory (setting the view address to your main() function
> > >Does your main function exist at the (.map file) indicated address?
> > >If not, your link needs tweaking
> > >otherwise..
> > >Click Debug/Go Main
> > >Check that the code actually stepped to the main() function.
> > >(use the .map file and the PC register)
> > >If the code executed to the main() function; use the F11 key to step
> >through the
> code, one
> > >instruction at a time
> > >
> > >
> >> >R. Williams
>

-- 
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Peter-

> I don't think any code ran at all either. It would run for a second and then go off to
no-where land.
>
> The asm instruction program counter points to is as follow:
> 10007E20 FFBBECDE            .word         0xffbbecde
> 10007E24 6BF3E25D     [ B2]  STH.D2T1      A23,*+B14[29666]
> 10007E28 FF656BDE ||         .word         0xff656bde
> 10007E2C B6FAB6BF     [!A2]  STB.D2T2      B13,*+B15[31414]
> 10007E30 C108D420 ||         .word         0xc108d420
>
> Those are the first five instructions. Sorry I miss that part on your post before.

As Mike indicated, the above instructions are not valid entry-point code.  His suggestions to
you are good ones,
suggest to follow and report your results.

> I did try the single-stepping the first few instructions. It doesn't execute anything. As
I answered to you in
> previous post.
> I can see a little green arrow move down.

Ok.

> Yes, Jeff, I do assume my board works, haha. Probably not a good idea. However, I did do a
lot hardware debug on this
> board.

I can tell that you did, from your first post.  Whatever is the problem is likely to be minor. 
Just have to find it.

> I see two new strange symptoms.
> 1. The bit-5 of the PLLCSR register is reserved and can only reads as "0",
according to C672X DSP PLL datasheet.
> However, when I setup a GEL file to initiate the PLL, that bit always reads as
"1". There is no code accidentally
> pulling high that bit.

I wouldn't worry about this yet... the CPU clock rate doesn't matter at this point.  You just
need to get a few
instructions to run.

> 2. The core supply (1.2V) current consumption of C6722 is 555mA at 250MHz, according to
the datasheet. But it only
> draw ~200mA when I increases the CPU speed to 250MHz. There is no short circuit and there
is plenty of current
> supplied.
> Do you have an idea what might be going wrong?

As Mike said, this does not sound like a problem.  It sounds to me like you paid a lot of
attention to power supply
and Vcc level, so the design should be good.

-Jeff

>>Peter-
>>
>>When you click "Go Main" that uses a breakpoint.  From the sound of that
>error
>>message, I doubt that any code ran because CCS had trouble with the >breakpoint.
>>
>>What is the asm instruction the program counter points to after loading >(at the
entry-point)?  I asked you this
>> before.  I suggest that you list >the first few asm
>>instructions, maybe they're not valid.  Also, did you try single-stepping >the
first
>>few instructions?  You should see the little yellow arrow move down one
>instruction
>>each time.  I made this suggestion before but it seems you still didn't >try it.
>>
>>Peter, if you click "Run" or "Go Main" then you're assuming that
your
>>board works.
>>But obviously it doesn't.  Probably you have some basic chip or hardware >issue,
not
>>too hard to fix, you just have to find it..  You may not like such low->level,
tedious
>>debug work, and you may be hoping your board starts up and runs >perfectly, but I
can
>>tell you from experience that just never happens.
>>
>>-Jeff
>>
>>> Thanks for the debuggubg technique you posted.
>>>
>>> The PC points to the correct address when reseting the CPU and loading >the
program.
>>> The stack looks right. It shows the instruction where the PC currently >points
to.
>>> The main() is inside the indicated address (from .map), it should be >right.
>>>
>>> But when I click the "Go Main", CCS gives the following error message:
>>> {
>>> Trouble Setting Breakpoint with the Action "Terminate GEL_Go()" at
>0x10002120:
>>Error 0x00000008/-2042 Error during: Break Point,  Cannot set/verify >breakpoint at
0x10002120
>>Sequence ID: 7 Error Code: -2042 Error Class: 0x00000008
>>> Breakpoint Manager: Retrying with a Legacy Hardware breakpoint
>>> }
>>>
>>> I have done some research on this, but can't find any answer.
>>> Does anyone have an idea what might be going wrong?
>>> P.S. I didn't use GEL file nor any berakpoint.
>>> >2008/5/17 Richard Williams <r...@lewiscounty.com>:
>>
>> >iddqd,
>>
>> >The following is a slightly simplified technique for debugging the >execution
> path
>> >This is assuming the board is set to power up the CPU in microprocessor >mode?
>> >
>> >If you compile with full debug info..
>> >Then load the code (be sure the .cmd file matches the addressing of the >code)
>> >Then click Debug/reset CPU
>> >Then click View/Registers (check that the PC and SP registers are correct >for
a
> CPU reset)
>> >Then click View/Call Stack
>> >Then Click View/mixed Source/Asm
>> >Then Click View/memory (setting the view address to the jump address in
>Flash)
>> >Does the jump address contain the address of your program entry point?
>> >If not your link needs tweaking
>> >Then Click View/Memory (setting the view address to your main() function
>> >Does your main function exist at the (.map file) indicated address?
>> >If not, your link needs tweaking
>> >otherwise..
>> >Click Debug/Go Main
>> >Check that the code actually stepped to the main() function.
>> >(use the .map file and the PC register)
>> >If the code executed to the main() function; use the F11 key to step >through
the
> code, one
>> >instruction at a time
>> >
>> >
>>> >R. Williams
------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

HI

Thank you guys. I don't know how to express my appreciation.

I tried the Michael's method to fill 100 hex words of internal memory with 0s and follow his
steps. It works!! The instructions run to the end of the 0s, where the break point is. So I did
the following debug process.

- I disconnect the target and close CCS, then reopen CCS and connect to the target, the 0s are
still there when reading from the memory window. Therefore, the 0s did write into the internal
memory, not just showed on the CCS.

- Can read the sillicon verion & registers, and can write to the registers use the GEL file
to initiate the PLL. So the communication between the host and target are OK.

-After reseting the hardware (0s are gone), the "Garbage" codes are the same every
time I connect to the target. At the same time sillicon ROM version & registers values are
read correctly at the right address. So I assume the Garbage codes are some intrinsic values
inside the inernal RAM, not just CCS randomly reads some codes from the target.

-The generated .out file can be applied to the CCS cpu simulator and runs correctly without
rebuild or recomplie the code. So that indicates the code generate tools are OK. 

I find that although the code can be complied and load without any error message. The codes
didn't actually load into memory at all. The sections (.text, .system, c_int00, main(), etc)
were shown correctly in the disassembly window & inside the .map file. It looked like every
thing is good to go. But the asm code in the disassembly window were just the intrinsic values
(garbage code) inside the inernal RAM. The real code didn't load at all.

There is a symptom when I did the fill "0s" test. I use the Edit -> memory ->
fill function in the CCS to fill the memory with 0s. I can only fill maximum 0x019 memory words
(e.g. 0x10000000~0x10000018) at a time. Once I try to fill more than that (e.g. 0x020 words),
nothing happened.

I just tried to load the code into external RAM. The CCS did load something into it. But they
are still some invalid codes.

80006E20          c_int00:
80006E20 2020B0D5     [ B0]  STH.D2T1      A0,*--B8[5]
80006E24 20203350 ||  [ B0]  ADDK.S1       16486,A0
80006E28 2020B7FF     [ B0]  STW.D2T2      B0,*+B15[8375]
80006E2C 2020356A ||  [ B0]  MVKH.S2       0x406a0000,B0
80006E30 20203BE9     [ B0]  MVKH.S1       0x40770000,A0
80006E34 20202BCC ||  [ B0]  LDH.D2T1      *+B15[8235],A0
80006E38 20203ECE     [ B0]  LDH.D2T2      *+B15[8254],B0
80006E3C 202055A7            .word         0x202055a7
80006E40 2020AA54 ||  [ B0]  STH.D1T1      A0,*+A8[A5]

Strangly, the hex of the code are all 0x2020XXXX inside the c_int00. and 0x1020XXXX outside the
c_int00???

Is there any setup that I need to do before I load the file? Such as refresh the cache? or
setup something in the GEL file?

Best regards
Peter

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Peter,

On Mon, May 19, 2008 at 10:46 PM,  <i...@gmail.com> wrote:
> HI
>
> Thank you guys. I don't know how to express my appreciation.
>
> I tried the Michael's method to fill 100 hex words of internal memory with
> 0s and follow his steps. It works!! The instructions run to the end of the
> 0s, where the break point is. So I did the following debug process.
>
> - I disconnect the target and close CCS, then reopen CCS and connect to the
> target, the 0s are still there when reading from the memory window.
> Therefore, the 0s did write into the internal memory, not just showed on the
> CCS.
>
> - Can read the sillicon verion & registers, and can write to the registers
> use the GEL file to initiate the PLL. So the communication between the host
> and target are OK.
>
> -After reseting the hardware (0s are gone), the "Garbage" codes are the same
> every time I connect to the target. At the same time sillicon ROM version &
> registers values are read correctly at the right address. So I assume the
> Garbage codes are some intrinsic values inside the inernal RAM, not just CCS
> randomly reads some codes from the target.
>
> -The generated .out file can be applied to the CCS cpu simulator and runs
> correctly without rebuild or recomplie the code. So that indicates the code
> generate tools are OK.
>
> I find that although the code can be complied and load without any error
> message. The codes didn't actually load into memory at all. The sections
> (.text, .system, c_int00, main(), etc) were shown correctly in the
> disassembly window & inside the .map file. It looked like every thing is
> good to go.

FYI - The labels/symbols are all generated on the host and require no
target information. [You could probably get the same results by
performing a 'symbol only load']

> But the asm code in the disassembly window were just the
> intrinsic values (garbage code) inside the inernal RAM. The real code didn't
> load at all.

Good - it sounds like you are making progress and have eliminated
several things.  Right now it is sounding like an emulator/software
problem.

What type of emulator are you using??
>
> There is a symptom when I did the fill "0s" test. I use the Edit -> memory
> -> fill function in the CCS to fill the memory with 0s. I can only fill
> maximum 0x019 memory words (e.g. 0x10000000~0x10000018) at a time. Once I
> try to fill more than that (e.g. 0x020 words), nothing happened.

This could be significant. I have seen this [or a similar] problem on
a couple of 'non-Spectrum Digital' emulators [the emulation driver
uses 2 different load algorithms internally - 1 for small blocks and
another for larger blocks]   If you are using a non-SD emulator,
please post the contents of 'cc/bin/brddat/ccbrd0.dat' - you could
have an emulator setup problem [or a bad adapter DLL].

>
> I just tried to load the code into external RAM. The CCS did load something
> into it. But they are still some invalid codes.

I would focus on internal memory first because it is a more controlled
environment.

>
> 80006E20 c_int00:
> 80006E20 2020B0D5 [ B0] STH.D2T1 A0,*--B8[5]
> 80006E24 20203350 || [ B0] ADDK.S1 16486,A0
> 80006E28 2020B7FF [ B0] STW.D2T2 B0,*+B15[8375]
> 80006E2C 2020356A || [ B0] MVKH.S2 0x406a0000,B0
> 80006E30 20203BE9 [ B0] MVKH.S1 0x40770000,A0
> 80006E34 20202BCC || [ B0] LDH.D2T1 *+B15[8235],A0
> 80006E38 20203ECE [ B0] LDH.D2T2 *+B15[8254],B0
> 80006E3C 202055A7 .word 0x202055a7
> 80006E40 2020AA54 || [ B0] STH.D1T1 A0,*+A8[A5]
>
> Strangly, the hex of the code are all 0x2020XXXX inside the c_int00. and
> 0x1020XXXX outside the c_int00???
>
> Is there any setup that I need to do before I load the file? Such as refresh
> the cache? or setup something in the GEL file?

There shouldn't be anything that you need to do.  You could disable
the cache from the register view [ i don't remember which bits in the
CSR make up the PCC field.  You can goto the product folder or data
sheet at ti.com. A cpu reset should clear the bits and disable the
cache, but I don't think that your problem is cache related.

mikedunn
>
> Best regards
> Peter

-- 
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Hi Michael

Thanks for your response. I am using a 'non-Spectrum Digital' emulator. It is "Wintech
TDS510USB2.0 emulator". The contents of "ccbrd0.dat" are shown as follow.

# config version=3.5
$ uscif
  slowclk=NO
  tdoedge=RISE
$ /
$ sepk
  pod_drvr=WTUSB5102.dll
$ /
@ tms320c6720_0 family=tms320c672x
@ bypass_0 family=bypass irbits=8
# /

How should I do to make it work?

Best regards
Peter

>Peter,
>
>On Mon, May 19, 2008 at 10:46 PM,  <i...@gmail.com> wrote:
>> HI
>>
>> Thank you guys. I don't know how to express my appreciation.
>>
>> I tried the Michael's method to fill 100 hex words of internal memory >with
>> 0s and follow his steps. It works!! The instructions run to the end of >the
>> 0s, where the break point is. So I did the following debug process.
>>
>> - I disconnect the target and close CCS, then reopen CCS and connect to >the
>> target, the 0s are still there when reading from the memory window.
>> Therefore, the 0s did write into the internal memory, not just showed >on the
>> CCS.
>>
>> - Can read the sillicon verion & registers, and can write to the >registers
>> use the GEL file to initiate the PLL. So the communication between the >host
>> and target are OK.
>>
>> -After reseting the hardware (0s are gone), the "Garbage" codes are the
>same
>> every time I connect to the target. At the same time sillicon ROM >version &
>> registers values are read correctly at the right address. So I assume >the
>> Garbage codes are some intrinsic values inside the inernal RAM, not >just CCS
>> randomly reads some codes from the target.
>>
>> -The generated .out file can be applied to the CCS cpu simulator and >runs
>> correctly without rebuild or recomplie the code. So that indicates the >code
>> generate tools are OK.
>>
>> I find that although the code can be complied and load without any error
>> message. The codes didn't actually load into memory at all. The sections
>> (.text, .system, c_int00, main(), etc) were shown correctly in the
>> disassembly window & inside the .map file. It looked like every thing is
>> good to go.
>
>FYI - The labels/symbols are all generated on the host and require no
>target information. [You could probably get the same results by
>performing a 'symbol only load']
>
>> But the asm code in the disassembly window were just the
>> intrinsic values (garbage code) inside the inernal RAM. The real code >didn't
>> load at all.
>
>Good - it sounds like you are making progress and have eliminated
>several things.  Right now it is sounding like an emulator/software
>problem.
>
>What type of emulator are you using??
>>
>> There is a symptom when I did the fill "0s" test. I use the Edit ->
>memory
>> -> fill function in the CCS to fill the memory with 0s. I can only fill
>> maximum 0x019 memory words (e.g. 0x10000000~0x10000018) at a time. Once >I
>> try to fill more than that (e.g. 0x020 words), nothing happened.
>
>This could be significant. I have seen this [or a similar] problem on
>a couple of 'non-Spectrum Digital' emulators [the emulation driver
>uses 2 different load algorithms internally - 1 for small blocks and
>another for larger blocks]   If you are using a non-SD emulator,
>please post the contents of 'cc/bin/brddat/ccbrd0.dat' - you could
>have an emulator setup problem [or a bad adapter DLL].
>
>>
>> I just tried to load the code into external RAM. The CCS did load >something
>> into it. But they are still some invalid codes.
>
>I would focus on internal memory first because it is a more controlled
>environment.
>
>>
>> 80006E20 c_int00:
>> 80006E20 2020B0D5 [ B0] STH.D2T1 A0,*--B8[5]
>> 80006E24 20203350 || [ B0] ADDK.S1 16486,A0
>> 80006E28 2020B7FF [ B0] STW.D2T2 B0,*+B15[8375]
>> 80006E2C 2020356A || [ B0] MVKH.S2 0x406a0000,B0
>> 80006E30 20203BE9 [ B0] MVKH.S1 0x40770000,A0
>> 80006E34 20202BCC || [ B0] LDH.D2T1 *+B15[8235],A0
>> 80006E38 20203ECE [ B0] LDH.D2T2 *+B15[8254],B0
>> 80006E3C 202055A7 .word 0x202055a7
>> 80006E40 2020AA54 || [ B0] STH.D1T1 A0,*+A8[A5]
>>
>> Strangly, the hex of the code are all 0x2020XXXX inside the c_int00. and
>> 0x1020XXXX outside the c_int00???
>>
>> Is there any setup that I need to do before I load the file? Such as >refresh
>> the cache? or setup something in the GEL file?
>
>There shouldn't be anything that you need to do.  You could disable
>the cache from the register view [ i don't remember which bits in the
>CSR make up the PCC field.  You can goto the product folder or data
>sheet at ti.com. A cpu reset should clear the bits and disable the
>cache, but I don't think that your problem is cache related.
>
>mikedunn
>>
>> Best regards
>> Peter
>
>-- 
>www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
>

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Peter,

On Tue, May 20, 2008 at 1:43 AM,  <i...@gmail.com> wrote:
> Hi Michael
>
> Thanks for your response. I am using a 'non-Spectrum Digital' emulator. It
> is "Wintech TDS510USB2.0 emulator". The contents of "ccbrd0.dat" are
shown
> as follow.
Try the following experiment:
1. Run CCS setup, save, exit, and do NOT start CCS.
2. Edit  'ccbrd0.dat' with a text editor - add the line just like I
did below. Save the file.
3. Start CCS and test.

Also, what is the version of the driver [as reported by windows
properties] that you are using?? [if you click once on the 'chip' icon
in CCS setup, you can see the driver name and path]

mikedunn
>
> # config version=3.5
> $ uscif
> slowclk=NO
> tdoedge=RISE
> $ /
> $ sepk
> pod_drvr=WTUSB5102.dll
POD_SCANLOOP=no
> $ /
> @ tms320c6720_0 family=tms320c672x
> @ bypass_0 family=bypass irbits=8
> # /
>
> How should I do to make it work?
>
> Best regards
> Peter
>
>>Peter,
>
>>
>>On Mon, May 19, 2008 at 10:46 PM, <i...@gmail.com> wrote:
>>> HI
>>>
>>> Thank you guys. I don't know how to express my appreciation.
>>>
>>> I tried the Michael's method to fill 100 hex words of internal memory
>>> >with
>>> 0s and follow his steps. It works!! The instructions run to the end of
>>> >the
>>> 0s, where the break point is. So I did the following debug process.
>>>
>>> - I disconnect the target and close CCS, then reopen CCS and connect to
>>> >the
>>> target, the 0s are still there when reading from the memory window.
>>> Therefore, the 0s did write into the internal memory, not just showed >on
>>> the
>>> CCS.
>>>
>>> - Can read the sillicon verion & registers, and can write to the
>>> >registers
>>> use the GEL file to initiate the PLL. So the communication between the
>>> >host
>>> and target are OK.
>>>
>>> -After reseting the hardware (0s are gone), the "Garbage" codes are the
>>> >same
>>> every time I connect to the target. At the same time sillicon ROM
>>> >version &
>>> registers values are read correctly at the right address. So I assume
>>> >the
>>> Garbage codes are some intrinsic values inside the inernal RAM, not >just
>>> CCS
>>> randomly reads some codes from the target.
>>>
>>> -The generated .out file can be applied to the CCS cpu simulator and
>>> >runs
>>> correctly without rebuild or recomplie the code. So that indicates the
>>> >code
>>> generate tools are OK.
>>>
>>> I find that although the code can be complied and load without any error
>>> message. The codes didn't actually load into memory at all. The sections
>>> (.text, .system, c_int00, main(), etc) were shown correctly in the
>>> disassembly window & inside the .map file. It looked like every thing is
>>> good to go.
>>
>>FYI - The labels/symbols are all generated on the host and require no
>>target information. [You could probably get the same results by
>>performing a 'symbol only load']
>>
>>> But the asm code in the disassembly window were just the
>>> intrinsic values (garbage code) inside the inernal RAM. The real code
>>> >didn't
>>> load at all.
>>
>>Good - it sounds like you are making progress and have eliminated
>>several things. Right now it is sounding like an emulator/software
>>problem.
>>
>>What type of emulator are you using??
>>>
>>> There is a symptom when I did the fill "0s" test. I use the Edit ->
>>> >memory
>>> -> fill function in the CCS to fill the memory with 0s. I can only fill
>>> maximum 0x019 memory words (e.g. 0x10000000~0x10000018) at a time. Once
>>> >I
>>> try to fill more than that (e.g. 0x020 words), nothing happened.
>>
>>This could be significant. I have seen this [or a similar] problem on
>>a couple of 'non-Spectrum Digital' emulators [the emulation driver
>>uses 2 different load algorithms internally - 1 for small blocks and
>>another for larger blocks] If you are using a non-SD emulator,
>>please post the contents of 'cc/bin/brddat/ccbrd0.dat' - you could
>>have an emulator setup problem [or a bad adapter DLL].
>>
>>>
>>> I just tried to load the code into external RAM. The CCS did load
>>> >something
>>> into it. But they are still some invalid codes.
>>
>>I would focus on internal memory first because it is a more controlled
>>environment.
>>
>>>
>>> 80006E20 c_int00:
>>> 80006E20 2020B0D5 [ B0] STH.D2T1 A0,*--B8[5]
>>> 80006E24 20203350 || [ B0] ADDK.S1 16486,A0
>>> 80006E28 2020B7FF [ B0] STW.D2T2 B0,*+B15[8375]
>>> 80006E2C 2020356A || [ B0] MVKH.S2 0x406a0000,B0
>>> 80006E30 20203BE9 [ B0] MVKH.S1 0x40770000,A0
>>> 80006E34 20202BCC || [ B0] LDH.D2T1 *+B15[8235],A0
>>> 80006E38 20203ECE [ B0] LDH.D2T2 *+B15[8254],B0
>>> 80006E3C 202055A7 .word 0x202055a7
>>> 80006E40 2020AA54 || [ B0] STH.D1T1 A0,*+A8[A5]
>>>
>>> Strangly, the hex of the code are all 0x2020XXXX inside the c_int00. and
>>> 0x1020XXXX outside the c_int00???
>>>
>>> Is there any setup that I need to do before I load the file? Such as
>>> >refresh
>>> the cache? or setup something in the GEL file?
>>
>>There shouldn't be anything that you need to do. You could disable
>>the cache from the register view [ i don't remember which bits in the
>>CSR make up the PCC field. You can goto the product folder or data
>>sheet at ti.com. A cpu reset should clear the bits and disable the
>>cache, but I don't think that your problem is cache related.
>>
>>mikedunn
>>>
>>> Best regards
>>> Peter
>>
>>--
>>www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
>
-- 
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )