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

Cluso99Cluso99 Posts: 16,925
edited 2020-11-20 - 21:00:28 in Propeller 2
I'm testing out my P2 RetroBlade2 boards and was wondering if anyone has done a pin test program?

What I'm thinking is checking for adjacent shorts for all I/O pins (well P0-P57 or P0-P61 although may need to allow for possible pullups/pulldowns on P59-P61).
Here is the idea...
Enable internal pullups on all pins (all means P0-57/61)

Now, for each pin, one at a time
disable the pullup
enable pulldown
read all pins (or 3 adjacent pins being lower, same, higher)
verify the current pin is low, and others are still high
enable pullup

Repeat the same but using pulldowns, and single pullup

Repeat both steps above, but instead of enabling pulldown/pullup drive low/high

While this does not check the pin to the connector, it does check for shorts between the P2 pins which is the most likely. A visual should provide reasonable confidence that the P2 pins are soldered to the pads, and a full pcb testing was paid for then there shouldn't be any tracking problems.

Comments

  • 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.
  • 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.
  • 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".

  • 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



  • 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.
  • 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 :)
  • 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.
  • 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 :(
  • jmgjmg Posts: 14,540
    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 ?

  • 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.
  • evanhevanh Posts: 10,088
    edited 2020-11-22 - 07:13:35
    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.

  • 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
    
    
    [
    
    800 x 480 - 90K
  • YanomaniYanomani Posts: 1,079
    edited 2020-11-22 - 13:32:15
    Now, this is nifty! :smile:

    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 JakackiPeter Jakacki Posts: 9,819
    edited 2020-11-22 - 14:26:30
    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
    



Sign In or Register to comment.