Photon Test Breakout Board

Hardware
1

My students often blame the photon when their software does not work, which is silly since there are so many other things that might be wrong, however after teaching 3 semesters using the Photon it is possible that the occasional photon pin might be messed up. Has anyone made a photon test PCB and if so would you share the Eagle schematics? I assume particle.io has something for testing Photons.

I am thinking about making a testing board. The digital and analog input and output pins would be easy to test with photoresistors and LED's but how could I test uART, SPI and I2C pins without actually connecting expensive other boards. Are there test chips for each form of serial communication?

here is a link to a cheap I2C chip

Just remembered I have 10 of these that I can use.

1 Like
2

At this topic you can find the eagle schematics for the photon etc

The Photon being here

3

@peekay123 with all those libraries you have converted to the particle, can you think of anything that uses a really cheap chip like:

https://www.digikey.ca/product-detail/en/microchip-technology/PIC12F1822T-I-SN/PIC12F1822T-I-SNCT-ND/5013533

that connects to the photon using all three types of serial connections (uART, SPI, I2C). I am fine getting a chip for each type but one chip that does all three would be a really good challenge.

4

@rocksetta,

How about designing a simple test jig that connects two photons together?
You have your “teacher” photon which is a known working unit.
If you test communications back and forth between that and a “student” photon, then you can be confident that the “student” photon is working.
Separately, you would most likely still want to test the remaining digital and analogue pins along with power pins to ensure no damaged pins.

I think that would give you fairly high confidence in the photon, would it not?

1 Like
5

Absolutely a great idea. Don't need to buy any chips etc I like it, but not really sure how to do the teacher - student (master-slave) protocols with uART, SPI and I2C but I like the concept

...

...

For the arduino uART looks fairly easy:

http://robotic-controls.com/learn/arduino/arduino-arduino-serial-communication

Note to self: Remember the common ground connection :slight_smile:

I2C looks OK as well:

SPI may also work:

If anyone has already done any of these with the Photon please add a link.

6

@rocksetta, making a jig with a known-good Photon and a target Photon makes sense. For UART testing, a simple loopback (TX connected to RX) is all that’s needed on the tested Photon. Otherwise, a simple echo test between the testing and the tested Photon is good as well.

The Photon now supports both SPI and I2C slave modes so the master would be the testing Photon and the slave the tested Photon. Modes can be reversed as long as hookup is done correctly. GPIO is straight forward as is ADC. The testing Photon could put out a voltage on its DAC that is used as inputs to the tested Photon ADCs. PWM output could tested with pulseIn() on the testing photon.

The testing board may need analog/digital multiplexers (CD4067) to configure different pin arrangements. It would be interesting to hear from the Particle folks on their test jig experience. @rickkas7 or @KyleG, can you help with that?

2 Likes
7

So I have started to design my Photon Testing PCB board. Actually presently working on the code to flash to the Photon in question. I really want to be able to test a photon that has cloud connectivity but perhaps a dead pin.

Question: What is the most likely pin to die? Anyone at Particle know what is the most common dead pin (probably caused by user error). Not sure who works in customer support but they should have an idea of this issue.

Would you expect Digital pins, Analog (non 5V tolerant pins…), PWM or Serial. What would people expect to burn out most without totally destroying the Photon? Possibly this is one of those things that no one person has enough information to answer.

I guess I will just have to test all pins for every ability

8

I am testing all the GPIO pins, by setting the next higher pin to an output and then reading for both HIGH and LOW on the present pin.

Bit strange connecting every single GPIO pin together, but it seems to work. Even spotted the error in my logic with D7. The original code connected it to D8!

GPIO-GOOD-BAD3.png315Ă—610 29.4 KB

Using the new Particle code sharing capabilities here is my corrected for D7 code (which will last about 5 minutes before I change it.)

… actually took about 10 minutes to fully change it. Here is the new revision.

https://go.particle.io/shared_apps/5931e36e07e2002c36000e40

2 Likes
9

So this seems fine for DAC testing. Was a bit more code than I was expecting.

void myTestDAC(){

// String myDAC1Good = "Bad";  //decalred as a global variable
// String myDAC2Good = "Bad";  // declared as a global variable    

int myDacRead1000, myDacRead2000, myDacRead3000;
String myDac1Output,myDac2Output ;


pinMode(DAC1, OUTPUT);    // DAC1 = A6 for output
analogWrite(DAC1, 1000);    
myDacRead1000 = analogRead(A1);
analogWrite(DAC1, 2000);    
myDacRead2000 = analogRead(A1);
analogWrite(DAC1, 3000);    
myDacRead3000 = analogRead(A1);

myDac1Output = String(myDacRead1000) + ", "+String(myDacRead2000) + ", "+ String(myDacRead3000) ;
if (myDacRead1000 > 900 && myDacRead1000 < 1100 && myDacRead2000 > 1900 && myDacRead2000 < 2100 && myDacRead3000 > 2900 && myDacRead3000 < 3100){
    myDAC1Good = "Good";
}

Particle.publish("AnalogWrite DAC1 AnalogRead A1", myDac1Output , 60, PRIVATE);
delay(1000);
Particle.publish("AnalogWrite DAC1 AnalogRead A1", myDAC1Good , 60, PRIVATE);
delay(1000);     

pinMode(DAC2, OUTPUT);    // DAC2 = A3 for output
analogWrite(DAC2, 1000);    
myDacRead1000 = analogRead(A2);
analogWrite(DAC2, 2000);    
myDacRead2000 = analogRead(A2);
analogWrite(DAC2, 3000);    
myDacRead3000 = analogRead(A2);

myDac2Output = String(myDacRead1000) + ", "+String(myDacRead2000) + ", "+ String(myDacRead3000) ;
if (myDacRead1000 > 900 && myDacRead1000 < 1100 && myDacRead2000 > 1900 && myDacRead2000 < 2100 && myDacRead3000 > 2900 && myDacRead3000 < 3100){
    myDAC2Good = "Good";
}

Particle.publish("AnalogWrite DAC2 AnalogRead A2", myDac2Output , 60, PRIVATE);
delay(1000);
Particle.publish("AnalogWrite DAC2 AnalogRead A2", myDAC2Good , 60, PRIVATE);
delay(1000);
// test both DAC lines
// schematic needs lines from DAC1 (A6) to A1;
// schematic needs lines from DAC2 (A3) to A2;
// somehow these lines need to be activated. How is this done?
// Output to console ??

}

10

I really like the new revision share particle system for when I have a problem and need help, but this program is changing very quickly I think the only way to working with it is from a github site.

Sharing a revision is probably a great way to store a working backup that people can look at.

Here is the Github link

11

So I have PWM and AnalogRead Photon testing working on A5-A1 and A4-A0. Still makes me nervous connecting all these pins together by setting them to INPUT when not using them, but it seems to work.

The basic concept here is to use PWM to turn on an LED to 3 levels, then use- AnalogRead to read the levels from a photoresistor and a bit of fuzzy logic to check if the values are good. I needed to use my own photoresistor (inside a cylinder to block stray light) since the ones that came with the Photon were not sensitive enough.

Note:The calculation is:

myReadBig - myReadSmall > (myReadMedium - myReadSmall)*0.90

12

@rocksetta, you could simply connect an analog (PWM) output to a digital input and use pulseIn() to measure the pulse width for different analog output values. Or use interrupts to measure the ON/OFF times. This is more accurate and simpler than your proposed approach IMO. :wink:

13

My way made a lot of sense until I saw how finicky the results were. Your way makes much more sense now. Thanks :slight_smile:

Interesting: pulseIn() returns a number that is almost always 7.84 times the PWM value. Making it very easy to work with. Note: Both PWM 0 and PWM 255 return zero from PulseIn()

1 Like
14

How to fully reset a DAC pin?

I have a weird situation with the DAC’s:

I have expanded my DAC test to test all the analog pins. My code for both DAC1 and DAC2 works great to test all of the other analog pins (So I use DAC1 to test A3 and DAC2 to test A6). But strangely I can’t run both tests one after the other, as if once DAC1 is activated it messes up DAC2 somehow.

I know that at analogWrite(DAC1, 0); still generates about 50 mV. So I am using pinMode(pin, INPUT) to reset my pins but I am not really sure if it works on the DAC’s. I also need to have all GPIO pins interconnected (Yes I find that troubling :worried:).

The DOCS for DAC and analogRead get a bit confusing about AN_INPUT and INPUT

https://docs.particle.io/reference/firmware/photon/#analogwriteresolution-pwm-and-dac-

Does anyone have any suggestions how to fully reset a DAC pin.

Here is my full code at the moment. DAC1 works for all analog pins then DAC2 fails.

https://go.particle.io/shared_apps/5936e6a9ba82212c63000961

It almost looks like the DAC pin has an extra few volts for the first reading???

DAC-bad.png437Ă—510 24.2 KB

15

Don't know why I have to write a question on this board before I think of a solution. :grinning:

It looks like this works to fully de-activate a DAC

pinMode(DAC1, OUTPUT);
analogWrite(DAC1, 1000); // activate DAC

digitalWrite(DAC1, LOW); // set DAC pin low NEEDED!
pinMode(DAC, INPUT); // de-activate the DAC pin

Looks like the code is good to go:

Connect all GPIO pins together, flash and run

Use at your own risk!

I have changed my plans slightly. I will use a differernt PCB / breadboard setup to test the serial connections. Presently have uART working just need to get I2C and SPI going.

16

@bko in this post:

[solved] Particle Photon not receiving i2c transmission

You have a very simple I2C Photon to Photon setup. I know the connections are:

// Photon I2C setup
// GND master to GND slave
// D0 (SDA = data) on master to D0 on slave
// D1 (SCL = clock) on Master to D1 on slave

but I am not sure about pullups when both Master and Slave are Photons both pullup to 5V or can both be pulled up to 3V3?. Any suggestions?

17

@rocksetta, you can pull-up to either voltages. Use 3V3 if no other I2C devices are on the bus.

2 Likes
18

I agree with @peekay123 here–3.3V if all devices agree, 5V otherwise.

1 Like
19

So working on breadboards now: Happens to coincide with my students making a few mistakes in class and frying a few Photons. The Photon-alone.ino and breadboard is currently working. I am still testing all the serial breadboards which eventually will be rolled into one (have I2C and uART working, still confused with SPI, the code not the breadboard).

Here is the github again:

Photon-alone testing Breadboard

…

uART Serial (GND, RX to TX and TX to RX)

…

I2C Serial (3V3, GND, D0, D1 both with 4.7 K ohm pullup resistors to 3V3 )

…

SPI Serial (GND, 3V3, A2 to A5)

spi-only5.png604Ă—1004 147 KB

…

@ScruffR your good at seeing my errors, other than my poor Fritzing abilities, do these serial breadboards look correct?

I am still working on the SPI, here is the docs, slave example, not sure where the master example is
https://docs.particle.io/reference/firmware/photon/#onselect-

Confused about the while(1) statement.

20

For your setups with a second Photon I can’t see how you power the second device? You have GND connected, but you might also want Vin or 3v3 connected.
For I2C you want 4k7 pull-ups not 470Ohm.

while(1) is usually used to trap your code in an eternal loop in case of an error condition.
But in this case it’s meant as a very tight loop to avoid any overhead introducted between loop() - but this will only work with non-AUTOMATIC SYSTEM_MODE()