Forums

testing a blackfin DSP board

Started by djcham December 20, 2006
Hi guys,

I'm testing a blackfin DSP board and wanted to get the opinion of you
guys on what the best way to ensure that everything works on the board.
 I've desigined a blackfin dsp board and having it sent to fabricate. I
plan to assemble it myself.  How would you go about testing that the
board is fully functional?  Thanks, I appreciate it!

JC

djcham wrote:
> Hi guys, > > I'm testing a blackfin DSP board and wanted to get the opinion of you > guys on what the best way to ensure that everything works on the board. > I've desigined a blackfin dsp board and having it sent to fabricate. I > plan to assemble it myself. How would you go about testing that the > board is fully functional? Thanks, I appreciate it!
You give no idea of what populates the board but the processor itself. What do you want to know? What facilities for testing are built in? Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
> >You give no idea of what populates the board but the processor itself. >What do you want to know? What facilities for testing are built in? > >Jerry >-- >Engineering is the art of making what you want from things you can get. >¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ >
Agreed, it is difficult to build a test plan when you don't know the function of the product. If it is an audio board, audio loopbacks are always a good thing to do. If it uses external memory, there are a bunch of memory/read write tests you can do to ensure all data/address pins are ok. (tests cache as well). It's confusing actually...you're building it, so you should already know what to test. Jeff
Jeff and Jerry, thanks for your replies..  my apologies for such an
open ended question.  the board will be used as a multi-purpose board
for a robotics project for some sort of image processing.  I'm planning
to interface a camera board to the DSP through PPI.  I guess my
question is after the board is assembled, I plan to test the RAM  and
flash to ensure that there are no memory problems as Jeff had
mentioned.  I guess the question is, how do i test the hardware
reliability of the board?  should i just leave it on for days and make
sure that it doesn't crash?  Have any of you come across long term
problems after designing a board?  thanks again

i'm building a board using the BF 534 with 4 MB of flash and 64 MB of
ram. i'm making a breakout board that will bring out all the i/o and
all that good stuff.  My rea
sparafucile17 wrote:
> > > >You give no idea of what populates the board but the processor itself. > >What do you want to know? What facilities for testing are built in? > > > >Jerry > >-- > >Engineering is the art of making what you want from things you can get. > >=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF
> > > > Agreed, it is difficult to build a test plan when you don't know the > function of the product. If it is an audio board, audio loopbacks are > always a good thing to do. If it uses external memory, there are a bunch > of memory/read write tests you can do to ensure all data/address pins are > ok. (tests cache as well). > > It's confusing actually...you're building it, so you should already know > what to test. >=20 > Jeff
>Jeff and Jerry, thanks for your replies.. my apologies for such an >open ended question. the board will be used as a multi-purpose board >for a robotics project for some sort of image processing. I'm planning >to interface a camera board to the DSP through PPI. I guess my >question is after the board is assembled, I plan to test the RAM and >flash to ensure that there are no memory problems as Jeff had >mentioned. I guess the question is, how do i test the hardware >reliability of the board? should i just leave it on for days and make >sure that it doesn't crash? Have any of you come across long term >problems after designing a board? thanks again > >i'm building a board using the BF 534 with 4 MB of flash and 64 MB of >ram. i'm making a breakout board that will bring out all the i/o and >all that good stuff. My rea
I'd say a burn-in test of running constant for a week is definitely one good thing to do. My experience is that if it works once, it works forever in there are no environment changes. But where hardware can get flacky is during environmental stresses: Temperature extremes for example. At work, the hardware guys have temp chambers and they usually cycle the hardware through min/max temp over like a hour (-40C to +85C). I have seen these type of tests kill hardware expecially if there are solderability issues (cold joints, broken joints, etc.) If you're trying to see if you're hand soldered parts are up to snuff, I'd recommend at least getting a heat gun and cold spray out and keep alternating between the two while you're memory test is running in the background. That's at least one idea. Jeff
sparafucile17 wrote:
>> Jeff and Jerry, thanks for your replies.. my apologies for such an >> open ended question. the board will be used as a multi-purpose board >> for a robotics project for some sort of image processing. I'm planning >> to interface a camera board to the DSP through PPI. I guess my >> question is after the board is assembled, I plan to test the RAM and >> flash to ensure that there are no memory problems as Jeff had >> mentioned. I guess the question is, how do i test the hardware >> reliability of the board? should i just leave it on for days and make >> sure that it doesn't crash? Have any of you come across long term >> problems after designing a board? thanks again >> >> i'm building a board using the BF 534 with 4 MB of flash and 64 MB of >> ram. i'm making a breakout board that will bring out all the i/o and >> all that good stuff. My rea > > I'd say a burn-in test of running constant for a week is definitely one > good thing to do. My experience is that if it works once, it works > forever in there are no environment changes. > > But where hardware can get flacky is during environmental stresses: > Temperature extremes for example. At work, the hardware guys have temp > chambers and they usually cycle the hardware through min/max temp over > like a hour (-40C to +85C). I have seen these type of tests kill hardware > expecially if there are solderability issues (cold joints, broken joints, > etc.) > > If you're trying to see if you're hand soldered parts are up to snuff, I'd > recommend at least getting a heat gun and cold spray out and keep > alternating between the two while you're memory test is running in the > background. > > That's at least one idea.
Back when processors sat in sockets (at least on unproven boards), a tool I used was a plug-and-socket combination that plugged into the board and accepted the processor. The data bus was hardwired to always deliver NOP, INC (k), or any instruction suitable for the processor whose result would be to increment the instruction counter by one. Every address line should be a square wave, with a frequency appropriate to the nit number. Departures quickly pinpoint shorts and opens. The data bus should always display the "magic" instruction. It won't find all problems, but it gets the trivial ones out of the way early. Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯