• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 381 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

C6747 can be programmed but won't run properly

DJH
Intellectual 985 points

This is behavior I can't explain.  The voltages power up correctly, they look stable, all clocks look good, and we can program the part via JTAG (spectrum debugger).  We can even confirm, from the spi flash part, that we are able to successfully flash the spi flash ic.  But when we try to run the code in the debugger things break down.  The program doesn't run predictably and if we pause and come back the program counter is off in the weeds; not at all expected behavior.

This is a second spin of our board and we seemed to have a similar problem, only occasionally though, on the first spin and it had to do with the delay on the reset line.  By adjusting an rc circuit we could get it to work.  We've replaced the reset control with a small pic, but it seems we must not have it right.

So my question is this: should we expect to be able to program the device, but not have it run (or boot) correctly, if the reset control isn't correct?  I don't want to spend a day chasing down ghost reset issues; because the thing programs fine I'm not sure what to think about why it won't run/boot.  We've pulled TRST low with a 10K resistor.

Any ideas?

Many thanks.

David Havell

  • 0
    TI__Guru* 84110 points

    David,

    I have had DSP boards with reset problems where I could get emulation access for some things and not others. If you do not have everything correct in the power, clocks, and reset, you cannot count on the device operating correctly. We cannot predict in what ways the device will fail when you do not apply these things correctly. This does not mean that fixing the reset will fix your problem, but it needs to be fixed even if it is not causing this problem.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Intellectual 985 points

    Thanks Randy,

    I've reproduced the waveform in fig 6.4 of the datasheet.  Is there a specification for the rise time of RESET?  It's taking just over 1us for RESET to go from 0V to 3V.  Everything matches the figure; except we don't have access to RESETOUT and I'm not sure how to confirm the boot pins are being sampled.

    Thanks for your help so far Randy.  I'll get you as much information today as I can.  It's bedeviling because the first spin we did works fine; this is not a problem we were expecting to have on the second spin...

    David

  • 0 in reply to DJH
    TI__Guru* 84110 points

    David,

    Did you have this 1us rise time for RESETz on your first spin? That is certainly a long time and a very slow rise for an important signal like RESETz.

    Like you, I did not find a Tr spec for RESETz, but it may be hidden in there in terms of test conditions or general information for all CMOS inputs.

    I definitely suggest making an improvement on this, at least on one board to see if it helps.

    How noisy is the signal on RESETz?

    You are certainly looking at what changed between the two spins. That is an important part of this equation, I would guess.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Intellectual 985 points

    Hi Jeff,

    Yes, TRST is pulled low with 10K and I've tried POR and warm reset, with debugger unplugged.  I have a working board here and the reset timing and voltage sequence I have checked so far match up.  I am performing a legal POR according to fig6.4.  I am also performing a legal warm reset.

    The power on sequence matches the spec listed on p.60. 

    We didn't bring out RESETOUT, but with the debugger running I can see that pushing the reset button definitely results in a DSP reset.

    I'm confused because it now doesn't appear to be a reset/voltage/timing problem.  So what else could it be?  1) SPI lines, 2) SDRAM?

    I will let you know what I find with the SPI bus.  But it is similar to our rev1 setup as well.  The SDRAM is exactly similar to rev1; but could this be an SDRAM issue?  (Recall that I'm trying to get the DSP to run the code loaded in the SPI flash part and we have debug LED's to indicate if the code is running or not.  We can program the DSP, we can even hit the run button without errors, but it isn't actually running and when we pause we get this: No source available for "varying hex addresses".)

    Actually, as I type this I realize that because it won't run in emulation probably means that my problem has nothing to do with SPI flash at all.  Must be a DSP or SDRAM issue, right?

    Thanks for all the help and hope so far!  Please keep it up...I have one of those nights coming up.

  • 0 in reply to DJH
    Intellectual 985 points

    Randy, sorry for starting that last one addressed to Jeff.  I inadvertently posted to another SPI flash/ reset page for the C6748 and interrupted someone else...sorry.

  • 0 in reply to DJH
    Intellectual 985 points

    CCS, if I'm doing it right, is telling me the boot mode register is all 0's.  But I can confirm that the actual state of those pins is set for SPI flash mode.

    In CCSv5, I go to the registers tab and look at the bootcfg register and bootmode is all 0's.  The debug window indicates that I am running and if I pull reset low, it indicates that a reset has occurred.  It will continue running after a few moments.

    Back to ye old drawing board...

    Thanks Randy,

    David

  • 0 in reply to DJH
    Intellectual 985 points

    Randy,

    I've got this distilled down to a more manageable set of questions.

    I've confirmed the start up sequence, clocks, voltages, and reset all are legal and match our rev1 board.  We expected the same code to just run because we have the same DSP (rev1 marking: TMS320C6747BZKB3 YF-IAADP9W 538 ZKB, rev2 marking: TMS320C6747BZKB3 YF-I9ACZHW 538 ZKB), same spi flash part, and same SDRAM.  However, the code doesn't just 'run'; there seem to be problems.  Here is what I observe in CCSv5:

    1.  CCS correctly reads the boot mode pins

    2.  CCS reports the program as running when I push the 'play' button

    3.  If I pause the program, it goes off to some unrecognized location where there is no code

    Here is my concern at this point:

    If I set the device to boot to emulation debug and then go into CCS, hit the debug button and then the play button, the code just doesn't run.  What could possibly cause the DSP to not run the existing code in emulation mode?  Wouldn't that indicate I have something wrong with the DSP itself?  Maybe there is a very base set of sample code I can get that will help me confirm the DSP can actually run code?

    We do have some pins of the DSP connected differently on this board, but it's mostly IO pins.  Could that cause issues with running the same code?  I'll be visiting with the software engineers on this, but I want to get your perspective on how I can tell if this is a DSP issue or a code issue.  Please let me know what you think.

    Thanks Randy,

    David

  • 0 in reply to DJH
    Intellectual 985 points

    Resolution:

    Well, we had the ratio setting to 0 in the PLLCTL register, which was setting the main processor frequency to 600MHz.  We simply had to change it to run at 300MHz and it runs great.

    It's still a mystery as to how the rev1 boards ever ran at 600MHz, but they are running.

    It makes sense why the dspflasher routine was able to program the SPI flash, because that routine uses it's own configuration and was probably correctly setting the PLL.

    Anyway, live and learn.  Thanks to all who contributed and thanks to Keegan Garcia for following up with me.

    David

  • 0 in reply to DJH
    Expert 2655 points

    Grtns,

    Your rev 1 with older silicon (not granularly screened) could have tolerated running as such speed, or it could have run at sub-harmonic (which I have seen before many times).  Rev 2 likely received newer silicon granularly screened for such speeds, and it chocked when clocked at double the rate.

    Good Luck,