• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 780 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.

TMS320BC51PQ80 - Need to test for functionality

kelsey hudson
Prodigy 40 points

Hi folks.

    I received an Agilent 33250A arb generator to try and repair and I think I've narrowed down the issue to the onboard DSP, which is a TMS320BC51PQ80. The part is 20 years old, obsolete now, and probably was even when the function generator was new. Regardless, I'd like to test it for operation somehow, but the only emulation software I could even find reference to for this core is for OS/2 Warp - even if I could find the software for download it's unlikely I could even run it, and certainly don't have the proper parallel port debugger (or hell, even a parallel port to attach it). So emulation is probably out of the question unless someone knows of a trick to get it working under any recent version of CCS (I'm probably asking too much). I own an XDS100v2 debugger (if that helps).

Anyways, what I really need is a simple way to test this thing for functionality. I had hoped JTAG would be it, but clearly that seems like it's more trouble than it's worth from the above experience. Is there a trick I can pull to e.g. pull pin X high for 10 ms and expect pin Y to go low? All I need to do is verify that the logic core is working so I can move on to other things for testing. Any help would be appreciated - any suggestions at all I'm willing to try. I have access to logic analyzers and any sort of tooling I'd need to debug it.

It's worth mentioning that I have exactly 0 experience with the TMS320 architecture, so even if it's something simple that even a beginner should know, I probably don't. 

One thing I will say is that the CLKOUT line is showing what I'd expect it to - a phase-delayed, cleaned CLKIN from the TCXO. I'm not sure how much (if any) of the logic core this uses for generation, though.

Regards, and thanks in advance.

-Kelsey

  • 0
    TI__Guru**** 161600 points
    Hi Kelsey,

    This has been forwarded to the design team. Their feedback will be posted here.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Prodigy 40 points

    Much appreciated. If there is any additional information the design team requires please let them know they can reach out to me via any means necessary.

    Regards,

    -Kelsey

  • 0 in reply to Yordan Kovachev
    Prodigy 40 points

    Yordan,

       Any chance we can poke the design team again? I know I might be asking a bit much what with a 20 year old product, but really, any small bit of insight would be appreciated. I would love to get this thing fixed.

    Thanks

    -Kelsey

  • 0
    TI__Mastermind 30470 points

    Hi Kelsey,

    I see that the 80MHz version of the Agilent 33250A sells used on eBay for $2500, so it may be worth trying to fix the piece of equipment. Have you used the sniff test to smell out any bad components, or visually inspected the board and components for burns, leaky mess, etc.

    The datasheet and technical documentation is available on ti.com
    www.ti.com/.../technicaldocuments

    The part number TMS320BC51PQ80 tells us...
        - it is not the low power option (3.3V), so must be 5V
        - it has the Boot Loader option
        - has ’C5x DSP
        - 132-pin plastic bumpered QFP (PQ PACKAGE)

    Use the pinout on page 3 (PQ package) to find and check the pins until you can figure out what is going on...
    Unlike BGA packages, the bumpered QFP package gives you access to all of the signals .

    Since you have a CLKOUT, it sounds like you are getting power, but it is wise to check all the rails are close to 5V:  VDD, VDDA, VDDD, VDDC, VDDI
    I would have started by checking for power to GND shorts before powering the system.
    Next would be to check the clocks, but that's been done already.

    The board might have routed the JTAG pins to a header which should have the required pull-ups / pull-downs. You may be able to tap into it. Or else (if you want to go this route), refer to the JTAG circuits available in the Emulation and Trace Headers Technical Reference Manual at www.ti.com/.../spru655i.pdf
    See schematic at 9 Electrical Requirements and Table 17. Termination Values and Use Cases
    I'm not sure what to use in CCS, but maybe one of the older devices will work with the 'C51. You'd have to try and see.

    In the TMS320BC51PQ80 datasheet, you can see how each signal is meant to behave and compare against your device.

    The part number tells us that your C51 has the Boot Loader option, but we dont know if the system designers used it or not.

    Datasheet: An optional boot loader is available in the device’s on-chip ROM. This boot loader can be used to transfer a program automatically from data memory or the serial port to anywhere in program memory. In data memory, the program can be located on any 1K-word boundary and can be in either byte-wide or 16-bit word format. Once the code is transferred, the boot loader releases control to the program for execution.
    The ROM is enabled or disabled by the state of the MP/MC control input upon resetting the device

    So you can probe the MP/MC pin and determine how the DSP gets its program code based on the documentation in the datasheet.

    If bootloader is used, it will use the parallel or serial interface to copy from external memory to internal memory. You could probe these pins and even connect the parallel bus to your logic analyzer... It would be really helpful to compare against a known good unit, if you happen to have one handy.

    Refer to external interface section of the datasheet.

    Datasheet: The R/W output signal is provided to indicate whether the current cycle is a read or a write. The STRB output signal provides a timing reference for all external cycles. For convenience, the device also provides the RD and the WE output signals, which indicate a read and a write cycle, respectively, along with timing information for those cycles.
    You also have the READY line and bus request (BR) signal
    Waveforms are shown below the timing tables in the second half of the datasheet

    You might even play with CLKMD1-3 to change PLL multiply factors
        TMS320BC51PQ80 supports 80MHz max sysclk

    Have you tried the BBS at 713/274-2323?
    Just kidding.

    Hopefully this prods you towards the right direction of debugging.

    Hope this helps,
    Mark

  • 0 in reply to Mark M
    Prodigy 40 points

    Mark Mckeown said:
    I see that the 80MHz version of the Agilent 33250A sells used on eBay for $2500, so it may be worth trying to fix the piece of equipment. Have you used the sniff test to smell out any bad components, or visually inspected the board and components for burns, leaky mess, etc.

    It's definitely worth repairing (despite what the repair houses around town tell me :))  To answer your question, yes, I've done a thorough component check to see if any of the discrete components were shot before moving on to the logic components. Nothing had any of the classic signs of distress.

    The part number TMS320BC51PQ80 tells us...

    (snip)
    Since you have a CLKOUT, it sounds like you are getting power, but it is wise to check all the rails are close to 5V:  VDD, VDDA, VDDD, VDDC, VDDI
    I would have started by checking for power to GND shorts before powering the system.

    Those were the first things I checked before the clocks. The power supply was a bit misaligned but nothing I couldn't easily correct by twiddling some trimpots. Nothing was out-of-spec by more than 1V (the -16V line which isn't even connected to the DSP - most of the others were off by ~+/-0.3V) so I'm confident it's not a power supply issue at this point. The voltages present at the DSP are actually provided by a 5V linear regulator that's rock solid at +5.01V.

    The board might have routed the JTAG pins to a header which should have the required pull-ups / pull-downs. You may be able to tap into it. 
    I'm not sure what to use in CCS, but maybe one of the older devices will work with the 'C51. You'd have to try and see.

    There's definitely a header broken out on the board and I purchased an XDS100v2 specifically for this project (it's actually quite an awesome debugger - i've used it quite a bit since I purchased it). I'll try a few things in CCS to see if something will talk to the C51, but I'm afraid I won't have much luck. As it is I need to download an older version of CCS in order to get even C5000 support, so that's on my list. I think this will be the biggest hurdle in terms of the JTAG route - the part is just so ancient that nothing specifically supports it (though from what I'm reading the C5x cores are all pretty similar, so *hopefully* something will be compatible enough to connect to it and say, "yup, it's alive" and I can feed it a simple assembly program to step through.

    The part number tells us that your C51 has the Boot Loader option, but we dont know if the system designers used it or not.

    So you can probe the MP/MC pin and determine how the DSP gets its program code based on the documentation in the datasheet.

    Now we're talking. I'll do this and see what I come up with - According to the Agilent datasheet the main CPU is supposed to load the DSP with code, but doesn't extrapolate on *how* that's done. The DSP's SRAM is connected to a shared but selectively isolated bus, so I suspect the main CPU or main FPGA will be loading that SRAM with code, then telling the bootloader to go nuts and pull it in. In my debugging, I never did observe a WE signal on the SRAM, so I (maybe incorrectly) assumed that the DSP isn't telling the rest of the system it's ready to accept code and the SRAM thusly isn't being loaded. The SRAM itself may be bad, now that I think about it - I'll have to figure out a way to verify that as well.

    If bootloader is used, it will use the parallel or serial interface to copy from external memory to internal memory. You could probe these pins and even connect the parallel bus to your logic analyzer... It would be really helpful to compare against a known good unit, if you happen to have one handy.

    A friend of mine was kind enough to loan me his operational unit, but it has a newer revision of the mainboard and isn't a 100% match. I do believe the DSP section is the same, however. It'll probably give me enough of an idea of what I should be looking for on the DSP's bus, at any rate.

    You might even play with CLKMD1-3 to change PLL multiply factors
        TMS320BC51PQ80 supports 80MHz max sysclk

    I'll do that and see if the CLKOUT line changes at all. 

    Have you tried the BBS at 713/274-2323?
    Just kidding.

    I think I still have a 2400 baud modem somewhere in a box! Brings back memories of my parents picking up the phone in the middle of a call wondering what the "static" on the line was, then garbage dumping to my terminal, prompting screams of, "I'M ON THE PHONE!!"

    Hopefully this prods you towards the right direction of debugging.

    You've definitely given me a couple things to look at and when I have the unit in front of me again I'll try them out and let you know how it goes. Thank you *very* much for helping me out. 

    Regards,

    -Kelsey