UART Problem after system reset

Phillip,

Which DSP and which version of EVM and CCS are you using?

It would be good to check the errata for your device to see if there is anything related to the UART that might be affecting your operation. I did not check it, so there might not be anything, but it is always a good idea to look there first.

I would approach debug for something like this on my system (and I did recently on the C6424) by dumping all of the UART registers and UART-related PSC registers prior to loading your program after a POR, after successfully running your application, after the CCS System Reset, and after initialization in your reloaded application. Compare those to see what is different in the four scenarios.

Look at the UART signals on an oscilloscope to see if anything is coming out, possibly at a different frequency.

Regards,
RandyP

Thanks for your qick reply :)

Dumping the UART registers delivered, that my initialization does everything right... all registers are set to the same values like they are set by the HUA-Demo on power up!

But I think I was able to isolate the problem a bit: when I power up the board and load my code to the board everything is working fine, as I described before... but when I'm calling the GEL-Script Init_PLL, I'm not receiving the messages in the terminal anymore! So I think the problem arises with the PLL-Initialization...

Maybe anyone can help me with this issue: which SYSCLK is connected to the internal UART? Think it must be SYSCLK7, but I'am not sure about it...

BTW:

I'm using the TMDSEVM6678LE Eval-Board and CCS  5.2.0.00069

I find that if the UART "doesn't work", it's often a sign that you're still in PLL bypass, with the whole chip running at 100 MHz.

It's an easy one to trip over, because lots of things appear to work fine, but you're still effectively in first gear.  It's only when you try to interact with things that are independent of the core clock that you start to notice (typically the PHY in my case).  The UART baud rate is expressed as a divider of core clock so when you're in bypass it is out by a factor of 10 and the PC sees gibberish.

The "System Reset" button always invisibly drops you back to this state on the 6678.  Booting from flash, the IBL sorts the PLL for you, and when you first start the debugger the GEL Global_Default_Setup does it.

Therefore, after a System Reset, you ALWAYS need to re-run "Global_Default_Setup" from the GEL menus on core 0.  (Also, this only works if you're in "no boot" on the DIP switches).

Forgive me if you know this, but it took me ages to understand why System Reset didn't seem to fix things.  Once I understood this, debugging became massively easier.

There's another thread here, including a TI suggestion for a GEL function that does the reset and the setup in one action.

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/167914/617386.aspx#617386

Oh, the GEL Init_PLL menu item by itself doesn't work for me (YMMV) so I always use the full setup.  I think you probably want that anyway, as System Reset will have reset more than just the PLL.

Philipp,

On the TI Wiki Pages is a simple app that runs on any C64x+ and later core (C674x and C66x) to tell you the clock speed of the DSP by comparing with the wall clock. You can find it here, and run it to confirm that your DSP clock is at the right value or not.

Regards,
RandyP