P2 board testing - anyone done code to test out a board?

Comments

• PropGuy2 Posts: 358

  2020-11-21 02:56

  I suspect Parallax already has a P2 EDGE and proto board test set. When I was working in the industry I built several of them - Functional test, application test, long term burn-in test. The functional test just tests the voltages, inputs and outputs, maybe some other stuff just to make sure the unit works. The second test, like you mentioned, tests the electronic module for a specific application. It is usually very detailed and basically measures everything - voltages, amperage, functions, timing intervals, both hardware and software features. The third, burn-in test, a test for infant failures, usually for 24 hours or so, under extreme hot and cold, high and low system voltages boot-up and shut-down - things like that.
  For your P2 EDGE test I would probably let the computer test the computer, in this case to P2 against the P2, one being the Unit Under Test (UUT), and the second P2 the sequencer, controller and results logger. It takes some effort and thought on exactly what you want to test and what you are exactly looking for.
• Cluso99 Posts: 18,069

  2020-11-21 04:27

  PropGuy2 wrote: »

  I suspect Parallax already has a P2 EDGE and proto board test set. When I was working in the industry I built several of them - Functional test, application test, long term burn-in test. The functional test just tests the voltages, inputs and outputs, maybe some other stuff just to make sure the unit works. The second test, like you mentioned, tests the electronic module for a specific application. It is usually very detailed and basically measures everything - voltages, amperage, functions, timing intervals, both hardware and software features. The third, burn-in test, a test for infant failures, usually for 24 hours or so, under extreme hot and cold, high and low system voltages boot-up and shut-down - things like that.
  For your P2 EDGE test I would probably let the computer test the computer, in this case to P2 against the P2, one being the Unit Under Test (UUT), and the second P2 the sequencer, controller and results logger. It takes some effort and thought on exactly what you want to test and what you are exactly looking for.

  No. I was just looking to see if anyone had done P2 software to test out the P2 I/O pins. I already have some of it working now.
  
  Thanks for the info tho I'm well aware of production testing having built Apple branded product for Apple, etc. However, my RetroBlade2 is not in this class.
• Peter Jakacki Posts: 10,193

  2020-11-21 04:52

  Cluso99 wrote: »

  Thanks for the info tho I'm well aware of production testing having built Apple branded product for Apple, etc. However, my RetroBlade2 is not in this class.

  
  
  What if it emulated an Apple II? Then it would be in the Apple "class".
  
  
• Tubular Posts: 4,622

  2020-11-21 04:59

  Here's some auto stepping code from earlier testing a couple of years ago
  https://forums.parallax.com/discussion/169269/accurate-dac-reference-data-voltages-from-p2-silicon
  
  For this a big short circuit block was applied to all pins of port A on P2D2, then every pin stepped through in turn Low & High, and all 256 dac levels. The results were recorded on a calibrated hp dvm. This actually found one flaky connection, easily fixed with a soldering iron
  
  There were actually two low readings and two hi readings taken for reasons a bit like you describe, things have settled better by the second reading
  
  
  
  
• ManAtWork Posts: 2,076

  2020-11-21 19:39

  Look at this post. I have done exactly what you need. The program tests for
  * pins stuck low (short to ground)
  * pins stuck high (short to VIO)
  * shorts between adjacent pins (solder bridges)
  I have tested it and the results seek reasonable. Sometimes a double fault is reported (stuck low + short to next pin for the same pin number, for example) but I think that's no problem.
• Cluso99 Posts: 18,069

  2020-11-22 03:13

  ManAtWork wrote: »

  Look at this post. I have done exactly what you need. The program tests for
  * pins stuck low (short to ground)
  * pins stuck high (short to VIO)
  * shorts between adjacent pins (solder bridges)
  I have tested it and the results seek reasonable. Sometimes a double fault is reported (stuck low + short to next pin for the same pin number, for example) but I think that's no problem.

  Thanks. I thought i had seen some test code but wasn't certain if I was dreaming.
  
  So I have already done my own in spin. I just set all tested pins with 15K pullups, then set each pin, one by one to 15K pulldown and ensured it read low before returning to pullup. I've tested with 1K to 3V3, GND and adjacent pins and my code reports all errors.
  
  My code is posted here
  forums.parallax.com/discussion/172457/testing-pins-for-shorts-using-smartpins-and-pullups-pulldowns#latest
  
  I will include a link to your code on that thread too
• Tracy Allen Posts: 6,656

  2020-11-22 03:58

  Ray, recall this thread, where there was discussion of P1s that threw bizarre memory errors, where certain bits were stuck.
  http://forums.parallax.com/discussion/161872/ram-checksum-error
  You came up with a quick test program, which I used at the time to pin down errors on some of my boards, ones that had failed to program.
  I believe that Parallax runs exhaustive test on the chips that come back from the foundry, but those happened to slip through. It never hurts to double check while you're at it in your test suite, especially during this startup phase.
  
• Cluso99 Posts: 18,069

  2020-11-22 04:23

  Tracy Allen wrote: »

  Ray, recall this thread, where there was discussion of P1s that threw bizarre memory errors, where certain bits were stuck.
  http://forums.parallax.com/discussion/161872/ram-checksum-error
  You came up with a quick test program, which I used at the time to pin down errors on some of my boards, ones that had failed to program.
  I believe that Parallax runs exhaustive test on the chips that come back from the foundry, but those happened to slip through. It never hurts to double check while you're at it in your test suite, especially during this startup phase.

  Unfortunately, if I tried to verify the P2 internals I would never ship these boards
  
  My board testing today revealed (one bard) a few pins from one edge were misaligned (not coplanar is the term I think) so the pins were in the air. I had P0-3 permanently low and upon really close inspection (I couldn't see it with my jewelers glasses!) the first few pins were not sitting flat and had not been soldered. The big clue was there was no 3v3 on the vio pin for that group. Touchup is not easy when the bypass caps are so close.
  BTW I don't touch the pins as I place the P2 using a suction device on the main chip.
  
  So it seems I am going to need to verify that the pins reach the pcb connectors as my current test does not actually verify the pin is soldered to the pcb, and a visual check cannot see this adequately
• jmg Posts: 15,145

  2020-11-22 04:39

  Cluso99 wrote: »

  So it seems I am going to need to verify that the pins reach the pcb connectors as my current test does not actually verify the pin is soldered to the pcb, and a visual check cannot see this adequately

  
  IIRC Chip did an example triangle oscillator that uses low current-drive modes and self feedback ?
  Maybe the frequency of that can measure pin total trace capacitance, with enough precision to catch isolated pins ?
  
  
• Cluso99 Posts: 18,069

  2020-11-22 05:43

  jmg wrote: »

  Cluso99 wrote: »

  So it seems I am going to need to verify that the pins reach the pcb connectors as my current test does not actually verify the pin is soldered to the pcb, and a visual check cannot see this adequately

  
  IIRC Chip did an example triangle oscillator that uses low current-drive modes and self feedback ?
  Maybe the frequency of that can measure pin total trace capacitance, with enough precision to catch isolated pins ?
  

  Maybe a possibility for later. Time is critical now.
  
  So, after all pins are verified for no shorts, I’m setting all pins high via 1K5. This way i can manually pass a probe down each connection (unconnected 0.1” pad) with the other via a led and resistor to gnd. I can verify all pads are connected to the pins visually.
  
• evanh Posts: 15,187

  2020-11-22 07:06 edited 2020-11-22 07:13

  A connected pin will have a slower pull-up/down charge curve than a disconnected pin. It's something that'll need tuned as a test but it should be doable. Using one of the current sink/source pin drive modes would produce the triangular response JMG just mentioned. That makes the timing measurement more linear than using a resistance.
  
  EDIT: Ah, and to get it as a frequency rather than a ping time, have the input configured as Schmitt and fed back to the output. Although, I'm not sure how a frequency really helps.
  
  
• ozpropdev Posts: 2,791

  2020-11-22 07:11

  You can also use the smartpins to transmit a "pin id" and check with a terminal or scope.

  {
  Propeller 2 Pin ID/Test - ozpropdev 2020
  }
  con
  
          crystal = 20_000_000
          dv = 20
          mlt = 180
          _clkfreq = crystal / dv * mlt
          clk = 1 << 24 | (dv-1) << 18 | (mlt-1) << 8
  
          baud = 115_200
          cpb = (_clkfreq / baud) << 16 | 7
  
          config = P_HIGH_15K | P_LOW_15K | P_ASYNC_TX | P_TT_01
  
  dat     org
  
                hubset  ##clk | %1111_01_00
                waitx   ##20_000_000/100
                hubset  ##clk | %1111_01_11
  
  .loop         wrpin   ##config,pin
                wxpin   ##cpb,pin
                dirh    pin
                incmod  pin,#62 wz
          if_nz jmp       #.loop
  
  main          loc       ptra,#@msg
                call      #str
                qdiv      pin,#10
                getqx     pa
                add       pa,#"0"
                call      #char_out
                getqy     pa
                add       pa,#"0"
                call      #char_out
                incmod    pin,#62 wz
                jmp       #main
  
  str           rdbyte    pa,ptra++ wz
          if_z  ret
                call      #char_out
                jmp       #str
  
  char_out      rdpin     ina,pin wc
          if_c  jmp       #char_out
          _ret_ wypin     pa,pin
  
  pin           long      0
  
                orgh      $400
  msg           byte      "Pin#",0
  
  
  [
  

  

  

  pin_id.jpg

  800 x 480 - 90K

  pin_id.jpg 90.4K
• Yanomani Posts: 1,524

  2020-11-22 13:32 edited 2020-11-22 13:32

  Now, this is nifty!
  
  A minor concern: mainly due to the use of an enig-finished pcb, and also gold-flashed connector pins, I'm just wondering if even using a slight laterally-applied-force, as to ensure a good contact with a probe or socket, would not be just enough to provide sufficient contact force, allowing such kind of an "electronic signature à la ozpropdev", to pass thrugouth a louselly solder joint, or even completelly unsoldered one...
  
• Peter Jakacki Posts: 10,193

  2020-11-22 14:21 edited 2020-11-22 14:26

  I use this one liner to output a distinct frequency for all pins (expect rx/tx) and if the frequency is 49kHz then I know that is pin 48 (49-1) plus the scope shows up any I/O conflicts too.

  0 62 ADO I PIN I 1+ KHZ LOOP
  

  
  
  If I want some resistance then this variation:

  0 62 ADO   I PIN   15K SOURCE 15K SINK   I 1+ KHZ    LOOP