Forums

Re: Re: CCS crash caused by too large program or Socket IO plug-in?

Started by Jeff Brower August 5, 2008
Janne-

> We are trying to remove the need for actual Node Bs in our testing. New
> env will also provide better tools for debugging and profiling. "port
> the code to appropriate DSK board with Enet daughtercard and then send
> test data via the Enet I/O" what does that mean? Do you know where I can
> get more info about this?

You can get a TCI6482 DSK board:

http://c6000.spectrumdigital.com/dsktci6482/files/6482_dsk_techref.pdf

and use that to run your actual code and socket I/O. Since you already have
operational code, this makes way more sense then trying to deal with the simulator --
and you should get more accurate results.

The TCI6482 is a single-core device (also called C6455); your Node B system is using
TCI6488 (3 cores). Hopefully you can extrapolate your results from one core.

> I am actually a thesis worker and my thesis concentrates on building up
> this new env. CCS is a tool that is used here part of our development.
> Nobody has a clear understanding of its function.

Ok that makes me laugh. "Nobody has a clear understanding of [CCS] function." Join
the club :-)

Seriously, CCS is a sophisticated, advanced tool...by far and away one of the best
embedded device IDEs ever created. But it's more robust with actual hardware than
with complex software simulation, due to all the years of usage and bug reporting by
1000s of developers using TI chips.

-Jeff

> >-----Original Message-----
> >From: ext Jeff Brower [mailto:j...@signalogic.com]
> >Sent: 05 August, 2008 00:59
> >To: Sandelin Janne (NSN - FI/Oulu)
> >Cc: c...
> >Subject: Re: [c6x] Re: CCS crash caused by too large program
> >or Socket IO plug-in?
> >
> >Janne-
> >
> >> Unfortunately it is impossible for me to post the code due
> >to its size
> >> and our company's policy (program is part of official Node B
> >SW). This
> >> same code with some flagged modifications is running in
> >actual Node B
> >> env without crashing.
> >
> >Well, that's a "slightly crucial" point you left out before.
> >Why do you need the simulator if actual code is already
> >running? If code is already running, and you want to make
> >some measurements or do some profiling, then why wouldn't you
> >port the code to appropriate DSK board with Enet daughtercard
> >and then send test data via the Enet I/O?
> >
> >> How is it possible that crashes happen in sim env but not in Node B
> >> env? If the crashes are caused by my program, is there any
> >way for me
> >> to track down the source of these problems after crash has happened?
> >
> >Who told you to take the simulator approach? It sounds to me
> >like you're an intern or new hire and a supervisor has thrown
> >this project at you without thinking it through. If you have
> >running code, you're way past the stage where the trouble and
> >difficulty of setting up the simulator and verifying that it's
> >configured correctly
> >-- and working correctly, and it's plug-ins are working
> >correctly -- is worth the time. It seems that you are
> >discovering this by now.
> >
> >-Jeff
> >