Weird, I seem to be able to control these pins okay, but for some reason they show pulled down and pulled high on several pins that are floating on my design (or at least should be). I can control these pins fine with the pin commands below and they output the expected values. I am starting to wonder if they are meaningful?
TAQOZ# lsio ---
P:00000000001111111111222222222233333333334444444444555555555566
P:01234567890123456789012345678901234567890123456789012345678901
=:d~~dddddd~~~~~~~~~dh~~~~d~~~~~~d~~d~d~~~~~~~~~~~~~~~~~~~~~hhhh ok
TAQOZ# 2 pin 3 hz --- ok
TAQOZ# 3 pin 1 hz --- ok
TAQOZ# 4 pin 1 hz --- ok
TAQOZ# 5 pin 2 hz --- ok
TAQOZ# 6 pin 2 hz --- ok
TAQOZ# 7 pin 3 hz --- ok
TAQOZ# 8 high --- ok
TAQOZ# 8 low --- ok
Also I am unable to download @Cluso99 's stuck pin test program using loadp2 with -SINGLE argument that uses the RCFAST option. It works for the P2-EDGE but not my board for some reason and I get no output from my board. Maybe you still need a crystal fitted for this download to work...? I did modify it to use RCFAST in the RBTest2.spin2 code:
CON
'_clkfreq = 200_000_000 ' clock frequency
_rcfast
_BAUD = 115_200 ' serial speed
P2 EDGE output gives this:
$ loadp2 -b 115200 -SINGLE -t RBTest10.binary
( Entering terminal mode. Press Ctrl-] to exit. )
Test pins 0....V....1....V....2....V....3....V....4....V....5....V....6...
Init Hi 1111111111111111111111111111111111111111111111111111111111
Test Lo 0000000000000000000000000000000000000000000000000000000000
Init Lo 0000000000000000000000000000000000000000000000000000000000
Test Hi 1111111111111111111111111111111111111111111111111111111111
Done 0....V....1....V....2....V....3....V....4....V....5....V....6...
Passed shorts test
My board doesn't output anything after loading it, maybe my reset timing has an issue, although "loadp2 -xTAQOZ -t" does seem to work each time with my board and that should exercise the reset pin too:
Ok thanks @evanh I might give that a try if I can get Pnut onto a win10 machine I have now - I do have PropTool there at least.
I'm fairly confident I don't have shorted pins, but this pull up and pull down indicator in TAQOZ is confusing me. Its like the different pins are floating to different voltages, which I do see when I measure some input pins with a voltmeter. I should probably also check for 3.3V supply noise, it's currently powered off a dinky little adjustable LDO supply I constructed years back and sourced from a USB port which was more convenient to setup quickly.
clkset( 0, 25_000_000 ) also works instead of clkfreq := 25_000_000. EDIT: Although, thinking about it, there is no advantage because it won't get to the CLKSET() if it has tried to set any prior PLL mode.
@rogloh said:
@evanh, can you zip your special 25MHz test build and paste into this thread so I can use your binary image? It will save me some setup time. Cheers.
Aha, it worked on my board and reported that I do have a few pin errors on port B which I didn't check yet. I'll need to check these pins.
( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. )
clkfreq = 25000000, clkmode = $0
Test pins 0....V....1....V....2....V....3....V....4....V....5....V....6...
Init Hi 1111111111111111111111111111111111111111111111111111111111
Test Lo 0000000000000000000000000000000001000000000000000000000000 <<< 1 error(s)
Init Lo 0000000000000000000000000000000001000000000001000000000000 <<< 2 error(s)
Test Hi 1111111111111111111111111111111111111111111111111111111111
Done 0....V....1....V....2....V....3....V....4....V....5....V....6...
Total pin errors = 3 error(s)
UPDATE: cleaned the board a bit, there might have been some residue in between a few P2 pads. Now getting a better test result.
( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. )
clkfreq = 25000000, clkmode = $0
Test pins 0....V....1....V....2....V....3....V....4....V....5....V....6...
Init Hi 1111111111111111111111111111111111111111111111111111111111
Test Lo 0000000000000000000000000000000000000000000000000000000000
Init Lo 0000000000000000000000000000000000000000000000000000000000
Test Hi 1111111111111111111111111111111111111111111111111111111111
Done 0....V....1....V....2....V....3....V....4....V....5....V....6...
Also TAQOZ lsio output has less showing in it now but board still might need another clean around these pins too.
TAQOZ# lsio ---
P:00000000001111111111222222222233333333334444444444555555555566
P:01234567890123456789012345678901234567890123456789012345678901
=:~h~~dd~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~d~~h~~~~~~~hhhh ok
@rogloh said:
Aha, it worked on my board and reported that I do have a few pin errors on port B which I didn't check yet. I'll need to check these pins.
UPDATE: cleaned the board a bit, there might have been some residue in between a few P2 pads. Now getting a better test result.
Also TAQOZ lsio output has less showing in it now but board still might need another clean around these pins too.
```
The good and the bad guys, playing tricky pranks onto those pins...
Hope you can get rid of the remainning aqueous solder past, ASAP!
IMHO, everything I've been seeing is just progress, so it's ever going in the right direction.
@rogloh This may not be a popular opinion, but I use rework flux exclusively... for everything... including initial board assembly. None of the water based fluxes IMHO are worth much as they tend to make "stuck bits" like you are seeing. If no failure happens immediately, then down the road once the board has been exposed to the real world strange things go wrong. RMA (rosin mildly activated) from Kester is what I use for everything, but you have to get it all off after soldering. Anything that wont survive a scrubbing with isopropanol followed by an ultrasonic bath gets added manually later. Its more work, but the end result (to me) is worth it.
As a point of reference, my stuff tends to wind-up in refineries, plants and oil fields in deep south Texas. Summers are brutal hot and wet. There are no "nice" environments for these gadgets, so use of a more aggresive flux and obsessive cleaning followed by conformal coatings are my standard motif for everything.
@rogloh said:
Also TAQOZ lsio output has less showing in it now but board still might need another clean around these pins too.
TAQOZ# lsio ---
P:00000000001111111111222222222233333333334444444444555555555566
P:01234567890123456789012345678901234567890123456789012345678901
=:~h~~dd~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~d~~h~~~~~~~hhhh ok
I think those are pull up and pull down sense, which may be prone to false positives ? Many forum reports have a mix of d,h,~ ie PCB capacitance of crosstalk may confuse things.
You could check the reported pins with a current meter, to see if they really do have 'real' pull ups or pull downs ? Or load with 10k or 100k and see any drop across the load ?
@JRoark
This is good information for me to know, along with what ManAtWork mentioned too. This test board was partially hand soldered and I grabbed the only flux I had on hand which is this water based stuff. I used to have some other Chemtools branded sticky flux gel stuff which was messy to deal with but that went hard in the syringe and I couldn't use it. I think I'll try to get some other types of flux/rosin when I put in my next parts order.
My next board will be solder paste based and hopefully I'll only need some flux for the top layer which will have 16 hand soldered bypass caps but that should be much easier to clean up. It's much harder to clean around and between the 0.5mm P2 pad pitch. I just tend to soak it in isopropanol and sort of wick it up with a tissue but it can still leave some residue as I found.
@jmg
Yeah that's what I'm thinking so I'll load it up and see what I get. Apart from the upper 4 pins I doubt this is genuine, maybe the input sensitivity is so high that it picks up faint flux residue/capacitance effects.
@rogloh I keep half of it in a glass bottle like women use to paint their nails, and the other half in a 1 oz squeezie with a Luer lock needle on top (Amazon: “gun oiler”). They work a treat and are fast to use and spillproof on the bench.
@rogloh said:
I ran this 1.8V regulator at about 1.7-1.8A output for a while - it's difficult to load up fully with just small value resistors I have so I partially resorted to using the lead resistance of my ammeter itself as a load. It got a little warm but not really hot so I think the thermals should be sufficient to take the next step. Efficiency seemed to be about 90% or so but the current wasn't fully stable in my probing setup so I probably need to take better readings later. I did hear some faint microphonic(?) vibration when the board was pressed down onto the table surface under load.
Time to cook a full board I think...
Update: Just realized that placing the P2 onto the paste without smudging is going to be tricky without special place tools. Tweezers may not be sufficient. All other parts will be okay.
One of these would be nice...
Bit late to the party, and just saw this. Another option would be to use a Zephyrtronics Vacuum pen zeph.com/zt3web.htm to place parts. Found one at a great price used. As to the visual part, try a pair of dental/surgical telescope lenses. Nice to be able to see up close and personal from 14-18" away from the work. There is really cheap to seriously expensive.
@evanh said:
Here's a recompile of Cluso's code with 62 pins and a more sensitive setting for each.
I tried this new version @evanh but am getting new errors. I think it must be the flash CS and DO being driven and affecting one another. Probably not good to test these pins the same way as the others which is why Cluso left them out.
( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. )
clkfreq = 25000000, clkmode = $0
Test pins 0....V....1....V....2....V....3....V....4....V....5....V....6...
Init Hi 11111111111111111111111111111111111111111111111111111111111111
Test Lo 00000000000000000000000000000000000000000000000000000000001001 <<< 2 error(s)
Init Lo 00000000000000000000000000000000000000000000000000000000001001 <<< 2 error(s)
Test Hi 11111111111111111111111111111111111111111111111111111111111111
Done 0....V....1....V....2....V....3....V....4....V....5....V....6...
Am having trouble with my 20MHz crystal that I recently soldered on. It doesn't appear to boot up and work with that. Might be a bad connection or a bad xtal (or both). I've re-soldered it a few times now but it might not be making a connection underneath to the pads. SMD crystals can be a PITA to hand solder, though I've managed it in the past and assumed it could work again. I added flux and some initial solder to the pad and reheated the corners while the part was placed down. It's hard to know if it made a proper connection but I do know that XI and XO are not shorted to the metal can's GND.
Says it can only be solder cycled twice, so maybe all my reheating attempts has overcooked it...hmm?
Here's the little beastie that is causing the grief. I do know that GND is connected at least.
Probably almost time to bite the bullet and just go make the full solder paste based board and use up my remaining parts, but it would be nice to know this crystal worked with the P2.
@rogloh said:
@jmg you are a crystal fan, this is the one I selected, do you think it should work okay with the P2 or may have issues? https://au.mouser.com/datasheet/2/122/ecx_53b-1479911.pdf
In particular I used ECS-200-10-30B-CKM-TR.
Any crystal should oscillate, the finer points apply when you want an exact frequency.
Then, the design pF matter
when initial testing xtals I often use a single strand from ribbon cable, to worm them onto the pads
If the Xtal OSC enables, you should see it change to 50% vcc on the XI and XO pins.
If that does not happen it is not activated in the linear region.
A high speed diode like BAW62 / 1N4148 can be used with a meter to indicate the peak to peak on XI and XO.
Yeah I'll drag out the scope and test if there's even a 20MHz signal getting through. To download any code I do have to use that -SINGLE option otherwise loadp2 has its own problems.
@jmg, I'm seeing 1.4V DC level on XIN to P2 from XTAL when I load something that enables the PLL and ~0.4V when running on the internal clock (eg. in TAQOZ). XOUT from P2 seems to vary a bit from 2V when I first touch it quickly jumping to ~3V. Not seeing an real oscillations on either pin but my scope probe will load it down of course (using x10 operation).
Update: Probing XOUT again now I do see a 20MHz sine shaped wave at 2.0V DC offset, so that's good.
Update2: Now things appear to be working when running off the XTAL, not sure why it's fixed, maybe a loose connection that has settled down after my pad probing with the scope.
It seems you're having the same bad contact/solder problem at the crystal pins, you experienced before, while doing the first attempts with the 1.8 V regulator.
Probably very true Yanomani. I'm seeing some weird startup delay too once the external PLL is activated. It's like if and when intermittently it does download and run the code enabling the PLL, it then takes a few extra seconds or so to switch over to the crystal and then output the application's serial port response data I send out at bootup (even when I put no startup delays in the code). In comparison P2-EDGE board does not do this and outputs data immediately after the binary download has finished. There is some flakiness in the PLL's startup time on my board, potentially soldering related but it could also be something else like load capacitance perhaps if the PLL takes longer to lock.
I hope it is not supply/noise related on the VCCIO supply for the PLL. I'm seeing ~20mV RMS of noise (~80mVp-p) on the board's 3.3V supply, and similar on 1.8V regulator output if I can trust my scope's built-in measurements. Same amount of noise seems to be present on the VCCIO for pins 28..31 (PLL supply).
I do have a 20MHz oscillator module to try out too, so if I can't resolve this problem anytime soon, I can just remove the xtal and solder an oscillator down instead, assuming I can solder that one any better than the xtal which is TBD.
If excessive stray capacitance is to be blamed as a possible cause of any problems, you can simply rule out the internal caps, by attempting a CC-field stuffed with %01, as part of the hubset command composition.
That's a temporally solution, meant to be used as a diagnose tool, and if it works, the track area around XI/XO pins, and also under the crystal, would demand carefull inspection.
Comments
Thanks Cluso, I'll take a look after dinner.
Thanks jmg.
Nessun dorma!
Belatedly, but still joyfully congratulations!
Weird, I seem to be able to control these pins okay, but for some reason they show pulled down and pulled high on several pins that are floating on my design (or at least should be). I can control these pins fine with the pin commands below and they output the expected values. I am starting to wonder if they are meaningful?
Also I am unable to download @Cluso99 's stuck pin test program using loadp2 with -SINGLE argument that uses the RCFAST option. It works for the P2-EDGE but not my board for some reason and I get no output from my board. Maybe you still need a crystal fitted for this download to work...? I did modify it to use RCFAST in the RBTest2.spin2 code:
P2 EDGE output gives this:
My board doesn't output anything after loading it, maybe my reset timing has an issue, although "loadp2 -xTAQOZ -t" does seem to work each time with my board and that should exercise the reset pin too:
Ah, hmm, looks like compiling under Flex suite will always enables the PLL. Default is 160 MHz and I don't think defining _RCFAST does anything.
Pnut will leave you in RCFAST just by commenting out the
_CLKFREQ =but then the assumed frequency of 20 MHz is too low for valid comms.EDIT: Ah-ha! With Pnut, add
clkfreq := 25_000_000to the start of Cluso's program, before starting the comms.EDIT2: And it also needs updated for replacing the
waitx(DLAY)cases withwaitus(DLAY)and change DLAY from 100 to 1.PS: I'm successfully compiling with Pnut (F9) then loading with loadp2.
Ok thanks @evanh I might give that a try if I can get Pnut onto a win10 machine I have now - I do have PropTool there at least.
I'm fairly confident I don't have shorted pins, but this pull up and pull down indicator in TAQOZ is confusing me. Its like the different pins are floating to different voltages, which I do see when I measure some input pins with a voltmeter. I should probably also check for 3.3V supply noise, it's currently powered off a dinky little adjustable LDO supply I constructed years back and sourced from a USB port which was more convenient to setup quickly.
@evanh, can you zip your special 25MHz test build and paste into this thread so I can use your binary image? It will save me some setup time. Cheers.
clkset( 0, 25_000_000 )also works instead of clkfreq := 25_000_000. EDIT: Although, thinking about it, there is no advantage because it won't get to the CLKSET() if it has tried to set any prior PLL mode.Actually I may as well just solder in that crystal. I have a few of those anyway.
Done
Thanks for that evanh.
Aha, it worked on my board and reported that I do have a few pin errors on port B which I didn't check yet. I'll need to check these pins.
UPDATE: cleaned the board a bit, there might have been some residue in between a few P2 pads. Now getting a better test result.
Also TAQOZ lsio output has less showing in it now but board still might need another clean around these pins too.
The good and the bad guys, playing tricky pranks onto those pins...
Hope you can get rid of the remainning aqueous solder past, ASAP!
IMHO, everything I've been seeing is just progress, so it's ever going in the right direction.
@rogloh This may not be a popular opinion, but I use rework flux exclusively... for everything... including initial board assembly. None of the water based fluxes IMHO are worth much as they tend to make "stuck bits" like you are seeing. If no failure happens immediately, then down the road once the board has been exposed to the real world strange things go wrong. RMA (rosin mildly activated) from Kester is what I use for everything, but you have to get it all off after soldering. Anything that wont survive a scrubbing with isopropanol followed by an ultrasonic bath gets added manually later. Its more work, but the end result (to me) is worth it.
As a point of reference, my stuff tends to wind-up in refineries, plants and oil fields in deep south Texas. Summers are brutal hot and wet. There are no "nice" environments for these gadgets, so use of a more aggresive flux and obsessive cleaning followed by conformal coatings are my standard motif for everything.
I think those are pull up and pull down sense, which may be prone to false positives ? Many forum reports have a mix of d,h,~ ie PCB capacitance of crosstalk may confuse things.
You could check the reported pins with a current meter, to see if they really do have 'real' pull ups or pull downs ? Or load with 10k or 100k and see any drop across the load ?
@Yanomani
Cheers!
@JRoark
This is good information for me to know, along with what ManAtWork mentioned too. This test board was partially hand soldered and I grabbed the only flux I had on hand which is this water based stuff. I used to have some other Chemtools branded sticky flux gel stuff which was messy to deal with but that went hard in the syringe and I couldn't use it. I think I'll try to get some other types of flux/rosin when I put in my next parts order.
My next board will be solder paste based and hopefully I'll only need some flux for the top layer which will have 16 hand soldered bypass caps but that should be much easier to clean up. It's much harder to clean around and between the 0.5mm P2 pad pitch. I just tend to soak it in isopropanol and sort of wick it up with a tissue but it can still leave some residue as I found.
@jmg
Yeah that's what I'm thinking so I'll load it up and see what I get. Apart from the upper 4 pins I doubt this is genuine, maybe the input sensitivity is so high that it picks up faint flux residue/capacitance effects.
@rogloh I keep half of it in a glass bottle like women use to paint their nails, and the other half in a 1 oz squeezie with a Luer lock needle on top (Amazon: “gun oiler”). They work a treat and are fast to use and spillproof on the bench.
Yeah those little squeeze bottles are useful. I do have my iospropanol in one and can apply it to needed areas of the PCB through the needle.
I do remember LSIO being very sensitive to this kind of thing, when we were testing early silicon way back in late 2018
It may be worth slowing the P2 clock down, before executing LSIO
Here's a recompile of Cluso's code with 62 pins and a more sensitive setting for each.
Bit late to the party, and just saw this. Another option would be to use a Zephyrtronics Vacuum pen zeph.com/zt3web.htm to place parts. Found one at a great price used. As to the visual part, try a pair of dental/surgical telescope lenses. Nice to be able to see up close and personal from 14-18" away from the work. There is really cheap to seriously expensive.
I tried this new version @evanh but am getting new errors. I think it must be the flash CS and DO being driven and affecting one another. Probably not good to test these pins the same way as the others which is why Cluso left them out.
yeah, I was thinking you didn't have anything else connected.
Am having trouble with my 20MHz crystal that I recently soldered on. It doesn't appear to boot up and work with that. Might be a bad connection or a bad xtal (or both). I've re-soldered it a few times now but it might not be making a connection underneath to the pads. SMD crystals can be a PITA to hand solder, though I've managed it in the past and assumed it could work again. I added flux and some initial solder to the pad and reheated the corners while the part was placed down. It's hard to know if it made a proper connection but I do know that XI and XO are not shorted to the metal can's GND.
@jmg you are a crystal fan, this is the one I selected, do you think it should work okay with the P2 or may have issues?
https://au.mouser.com/datasheet/2/122/ecx_53b-1479911.pdf
In particular I used ECS-200-10-30B-CKM-TR.
Says it can only be solder cycled twice, so maybe all my reheating attempts has overcooked it...hmm?
Here's the little beastie that is causing the grief. I do know that GND is connected at least.
Probably almost time to bite the bullet and just go make the full solder paste based board and use up my remaining parts, but it would be nice to know this crystal worked with the P2.
Any crystal should oscillate, the finer points apply when you want an exact frequency.
Then, the design pF matter
when initial testing xtals I often use a single strand from ribbon cable, to worm them onto the pads
If the Xtal OSC enables, you should see it change to 50% vcc on the XI and XO pins.
If that does not happen it is not activated in the linear region.
A high speed diode like BAW62 / 1N4148 can be used with a meter to indicate the peak to peak on XI and XO.
Yeah I'll drag out the scope and test if there's even a 20MHz signal getting through. To download any code I do have to use that -SINGLE option otherwise loadp2 has its own problems.
@jmg, I'm seeing 1.4V DC level on XIN to P2 from XTAL when I load something that enables the PLL and ~0.4V when running on the internal clock (eg. in TAQOZ). XOUT from P2 seems to vary a bit from 2V when I first touch it quickly jumping to ~3V. Not seeing an real oscillations on either pin but my scope probe will load it down of course (using x10 operation).
Update: Probing XOUT again now I do see a 20MHz sine shaped wave at 2.0V DC offset, so that's good.
Update2: Now things appear to be working when running off the XTAL, not sure why it's fixed, maybe a loose connection that has settled down after my pad probing with the scope.
It seems you're having the same bad contact/solder problem at the crystal pins, you experienced before, while doing the first attempts with the 1.8 V regulator.
Probably very true Yanomani. I'm seeing some weird startup delay too once the external PLL is activated. It's like if and when intermittently it does download and run the code enabling the PLL, it then takes a few extra seconds or so to switch over to the crystal and then output the application's serial port response data I send out at bootup (even when I put no startup delays in the code). In comparison P2-EDGE board does not do this and outputs data immediately after the binary download has finished. There is some flakiness in the PLL's startup time on my board, potentially soldering related but it could also be something else like load capacitance perhaps if the PLL takes longer to lock.
I hope it is not supply/noise related on the VCCIO supply for the PLL. I'm seeing ~20mV RMS of noise (~80mVp-p) on the board's 3.3V supply, and similar on 1.8V regulator output if I can trust my scope's built-in measurements. Same amount of noise seems to be present on the VCCIO for pins 28..31 (PLL supply).
I do have a 20MHz oscillator module to try out too, so if I can't resolve this problem anytime soon, I can just remove the xtal and solder an oscillator down instead, assuming I can solder that one any better than the xtal which is TBD.
If excessive stray capacitance is to be blamed as a possible cause of any problems, you can simply rule out the internal caps, by attempting a CC-field stuffed with %01, as part of the hubset command composition.
That's a temporally solution, meant to be used as a diagnose tool, and if it works, the track area around XI/XO pins, and also under the crystal, would demand carefull inspection.