• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 449 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.

Need help debugging DM6467 custom boards

V.Faul
Intellectual 885 points

A number of our custom DM6467 boards have been manufactured and we are using the emulator to debug them.  Each board has three DM6467 circuits.  About 30% of the DM6467s do not work.  Two of the most common problems are described below.  We have done the obvious checks, such as verifying components have been installed in the correct orientation, etc.  On some boards, all three 6467s function, so we are confident the PWB is correct.  We are using the evmdm6467_arm.gel version 1.02 with some minor mods for NOR flash and our DDR timing is the same as the EVM.  Can anyone offer some advice on the two problems below?
 
Problem #1:
We are getting the error shown below in the function Disable_IRQ_Flush_Cache of the GEL file, when setting supervisory mode and disable IRQ/FIQ ("CPSR = 0x400000d3;").  I can't even find a CPSR register in the 6467 datasheet!
ARM926_0: GEL Output: Disable IRQ/FIQ
ARM926_0: GEL: Error while executing OnTargetConnect(): execution state prevented access.

Problem #2:
We are getting the error shown below in the function setup_pll_0 of the GEL file.  I stuck some print statements in the GEL and it hangs in step 2 at "*pll_ctl &= ~0x0001;", which sets the PLL to bypass mode.
ARM926_1: GEL Output: Setup PLL0
ARM926_1: Trouble Reading Memory Block at 0x1c40900 on Page 0 of Length 0x4: Error 0x80002002/-173 Fatal Error during: Memory, Control,  Error generated by SD scan controller module

  • 0
    TI__Expert 8260 points

    Faul,

    What speed DM6467 parts are you using? 594MHz or 729MHz?

    Regards, Srirami.

     

  • 0 in reply to V.Faul
    TI__Expert 8260 points

    Faul,

    What is the boot mode are u using? To debug the boards initially, I recommend you use the emulation boot (0000b) and use the evmdm6467_arm.gel file. Also you should see all 0s in BOOTCFG register (0x01C40000)  to make sure of emulation boot.

    Regards, Srirami.

  • 0 in reply to srirami
    Intellectual 885 points

    On the particular 6467 I'm working with, I tried connecting using evmdm6467_arm.gel in emulation boot, uart boot, and NOR boot and I get Problem #1 for all three boot modes).  Note that our hardware has switches for boot cfg bits 2 and 3, bits 0 and 1 are tied low.

  • 0 in reply to V.Faul
    Intellectual 885 points

    We have made some progress.  We slowed the JTAG TCK from 13MHz all the down to 1MHz (even 2MHz was a problem!).  Now we can connect to all three 6467s on the board.  I'm not sure why some boards work with a 13MHz TCK and this board needs a much slower TCK.  Our next problem is that changing a value at one DDR address changes values at many addresses.  I need to double check the DDR timing registers in the GEL.

    For those who read this and may be wondering how we modified the TCK freq of our SD XDS510-USB emulator, here is how we did it.  We edited c:\windows\system32\sdopts.cfg.  In the [EmulatorId=510] section, we changed the value of EmuJclkFreqMHz from 13 to 1.

  • 0 in reply to V.Faul
    TI__Expert 8260 points

    Here is what I recommend.
    In SDconfig utility make sure you can do a RESET, EMU-check. Then click on the "Emulator" tab and select "Diagnostics". Set the pattern to 0x5555 or 0xAAAA, set the loop count to 0 (infinity), Set the error loop count to 0 (infinity). click start to make it run/stop to halt. Now look at all the signals with a scope.

    Do this with a good board at 13 MHz (actually 12). Get a good idea what the JTAG waveforms look like all over the board, then do it with a faulty board.

    Preliminary check: look at ALL the voltages on the bad boards.

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

    Few more items to consider:

    I suggest you to bring up 1 device at a time and put the other 2 in bypass until you can verify that all 3 are good.
    DSP, ByPass, ByPass
    ByPass, DSP, ByPass
    ByPass, ByPass, DSP
    then DSP, DSP, DSP

    If you can't do a basic diagnostic scan with SDI XDS510 USB or XDS510USB PLUS emulator and the SDConfig utility, how do you know what is good/bad in the scan chain. If they can't talk to each DSP cleanly CCS has NO chance to come up.

    Is there a way to short circuit the scan chain to only have 1 device in the chain ?

    If one board with 3 DSP is working correctly and the others do not, I think the assembly of the boards could be suspect.
    Were the boards(mainly the 3 DSPs) x-rayed after manufacturing to verify the connection/soldering under the parts. If not, go have it done, immediately. This is a quality issue.

    If the .gel file works on the board with the 3 DSPs that do work I would say it should work on the other boards.

    Again test one DSP at a time.

    Also if you are trying to boot out of an empty flash device they need to change their boot mode to NO boot or HPI boot. An empty flash looks like real data that never ends and the emulation logic cannot get control of the processor.
    --------------------

    Regards, Srirami.