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

Cluso99

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.

PropGuy2

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

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

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

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

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

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

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

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

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

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

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

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


[

Yanomani

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

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