Automated Testing of P2's

13

Comments

  • cgracey wrote: »
    VonSzarvas wrote: »
    cgracey wrote: »
    n ADC needs 10us to get out of bed.

    Wow. I'm only averaging 10s these days !


    That probably doesn't even include the time required to think about getting out of bed, before you actually do it.

    Does of count if I dream got out of bed and went to work.

    Thanks for the description of that T2000 machine. That's pretty interesting. I saw a used T2000 mainframe for sale on eBay for $200k. For the Prop1, we built application-specific testers for about $20 per unit, not including the socket adapter.
  • samuell wrote: »
    Hi Evan,

    Did you have to modify the 3V3 DC-DC circuit? I see a resistor hanging there. That might be the reason why my P2 doesn't pass. I've noticed that the 1MHz clock goes through briefly as P62 goes to high impedance, but it is erratic. Reminds me of an I2C or SPI signal.

    Kind regards, Samuel Lourenço

    Samuel, your chip already passed this test at Parallax when we built your eval board. It should still pass, unless some pin got destroyed. The test I posted ignores P62 and P63, since those are connected to the serial port and are not unloaded. You will see a 'WRWORD #0,#62' instruction that cancels errors for those pins. That instruction gets commented out for the test that ON Semi runs.
  • jmgjmg Posts: 13,609
    cgracey wrote: »
    ... For the Prop1, we built application-specific testers for about $20 per unit, not including the socket adapter.
    How much testing is done at OnSemi, and how much do you plan to do in-house for P2 ?

  • I think the goal here is to test the chips before they get packaged, to avoid spending money on duds.

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • jmg wrote: »
    cgracey wrote: »
    ... For the Prop1, we built application-specific testers for about $20 per unit, not including the socket adapter.
    How much testing is done at OnSemi, and how much do you plan to do in-house for P2 ?

    With our analog test program added onto ON Semi's digital tests, they will be able to perform a complete test at both wafer and package-level. No need for Parallax to touch the parts.
  • cool
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • evanhevanh Posts: 7,271
    edited 2019-07-03 - 04:16:17
    samuell wrote: »
    Hi Evan,

    Did you have to modify the 3V3 DC-DC circuit? I see a resistor hanging there.
    Heh, no those are remains of prior operations. There's more than one extraneous component hanging around in that photo. One is for USB 5V monitoring, one was for quieting the 3v3 VIO switcher, Mark_T's idea, but is currently open circuit and the pin supplies are all on LDOs right now anyway.

    Oh, you should be jumpered to the LDOs for analogue tests like this.

    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • MIchael_MichalskiMIchael_Michalski Posts: 127
    edited 2019-07-03 - 19:51:53
    cgracey wrote: »

    Thanks for the description of that T2000 machine. That's pretty interesting. I saw a used T2000 mainframe for sale on eBay for $200k. For the Prop1, we built application-specific testers for about $20 per unit, not including the socket adapter.


    I would not be surprised if that was lacking the system and site controllers and the option boards. I know the option boards range between 10 and 50 grand each. Im not sure how much the site controllers go for, but I know we pull them before disposing of a tester, so I bet Advantest sales people put their children through Ivy League colleges on the commissions.

    I would assume you had to pay them for the TIU to test the P2. The thought occurs to me, does Parallax own the hardware? The design? The test programs? And if not, is there a provision of the contract where you can buy it, should you decide to (or it become necessary) to change to another vendor to make the P2? (there no need to answer, just throwing that out there)
    Particularly patient proactive practice positively predicates practically precise poly-processor Parallax Propeller programming paradigms.

    .
  • cgraceycgracey Posts: 11,266
    edited 2019-07-03 - 20:22:19
    cgracey wrote: »

    Thanks for the description of that T2000 machine. That's pretty interesting. I saw a used T2000 mainframe for sale on eBay for $200k. For the Prop1, we built application-specific testers for about $20 per unit, not including the socket adapter.


    I would not be surprised if that was lacking the system and site controllers and the option boards. I know the option boards range between 10 and 50 grand each. Im not sure how much the site controllers go for, but I know we pull them before disposing of a tester, so I bet Advantest sales people put their children through Ivy League colleges on the commissions.

    I would assume you had to pay them for the TIU to test the P2. The thought occurs to me, does Parallax own the hardware? The design? The test programs? And if not, is there a provision of the contract where you can buy it, should you decide to (or it become necessary) to change to another vendor to make the P2? (there no need to answer, just throwing that out there)

    Well, we're using a lot of ON Semi IP when it comes to the RAMs, ROM, and logic cells. Everything in the core. We are partners, in a sense.

    I also don't know about the portability of the process to another fab. I'm sure it's quite similar, but just a few basic design rules difference and you've got to redo everything.
  • samuellsamuell Posts: 323
    edited 2019-07-04 - 20:10:35
    evanh wrote: »
    samuell wrote: »
    Hi Evan,

    Did you have to modify the 3V3 DC-DC circuit? I see a resistor hanging there.
    Heh, no those are remains of prior operations. There's more than one extraneous component hanging around in that photo. One is for USB 5V monitoring, one was for quieting the 3v3 VIO switcher, Mark_T's idea, but is currently open circuit and the pin supplies are all on LDOs right now anyway.

    Oh, you should be jumpered to the LDOs for analogue tests like this.
    Yup, I was not using the correct jumper settings there. However, today I've retested the P2, and still fails.
    cgracey wrote: »
    samuell wrote: »
    Hi Evan,

    Did you have to modify the 3V3 DC-DC circuit? I see a resistor hanging there. That might be the reason why my P2 doesn't pass. I've noticed that the 1MHz clock goes through briefly as P62 goes to high impedance, but it is erratic. Reminds me of an I2C or SPI signal.

    Kind regards, Samuel Lourenço

    Samuel, your chip already passed this test at Parallax when we built your eval board. It should still pass, unless some pin got destroyed. The test I posted ignores P62 and P63, since those are connected to the serial port and are not unloaded. You will see a 'WRWORD #0,#62' instruction that cancels errors for those pins. That instruction gets commented out for the test that ON Semi runs.
    I think my chip got damaged, although the suspect bank is still able to output signals. I suspect that I've accidentally touched and made contact between the P38 pin and the adjacent 5V pin, if I recall correctly. It was a very brief contact, and after that I saw that the bank was still operating. Perhaps the performance was somehow degraded.

    I've attached a photo of my precarious set. On the right is my function generator, outputting a 1MHz clock. It is connected to P62 via a 1K resistor.

    Kind regards, Samuel Lourenço
    1024 x 768 - 190K
  • samuellsamuell Posts: 323
    edited 2019-07-04 - 00:09:16
    To add to my previous comment, this is how I'm setting the function generator. Since I'm using its digital output, the 8Vpp setting is of no consequence, since it only affects the analog output. This high setting makes the output less jittery, though.

    Update: Tested pins 0 through 61 via TAQOZ. All pins were able to output 285.3KHz when set to blink at 1 MHz. I suspect the reason why the test fails might be due to an analog output/input issue. I suspect that because I'm unable to output audio to any pair of pins I choose when using the SIDcog demo program for the P2. Not only the P32-P39 bank is affected by this, but other banks as well (banks that didn't saw mishaps with 5V - as only the previously mentioned bank had such event).

    Chip, is there any way to isolate pins for troubleshooting? I mean, test a set of pins at a time?

    Kind regards, Samuel Lourenço
    1440 x 900 - 365K
  • cgraceycgracey Posts: 11,266
    edited 2019-07-04 - 02:09:31
    samuell wrote: »
    To add to my previous comment, this is how I'm setting the function generator. Since I'm using its digital output, the 8Vpp setting is of no consequence, since it only affects the analog output. This high setting makes the output less jittery, though.

    Update: Tested pins 0 through 61 via TAQOZ. All pins were able to output 285.3KHz when set to blink at 1 MHz. I suspect the reason why the test fails might be due to an analog output/input issue. I suspect that because I'm unable to output audio to any pair of pins I choose when using the SIDcog demo program for the P2. Not only the P32-P39 bank is affected by this, but other banks as well (banks that didn't saw mishaps with 5V - as only the previously mentioned bank had such event).

    Chip, is there any way to isolate pins for troubleshooting? I mean, test a set of pins at a time?

    Kind regards, Samuel Lourenço

    If you can look at the pins at the end of the test, you can see the first four pins that failed. The first failed-pin code will be on P[7:0] with the first failed-pin number on P[15:08]. Up to three more failed-pin reports will be on P[31:16], P[47:32], and P[63:48].

    You can also cause it to ignore certain pin failures by doing a 'WRBYTE #0,#pin' next to where the 'WRWORD #0,#62' is.
  • cgracey wrote: »
    samuell wrote: »
    To add to my previous comment, this is how I'm setting the function generator. Since I'm using its digital output, the 8Vpp setting is of no consequence, since it only affects the analog output. This high setting makes the output less jittery, though.

    Update: Tested pins 0 through 61 via TAQOZ. All pins were able to output 285.3KHz when set to blink at 1 MHz. I suspect the reason why the test fails might be due to an analog output/input issue. I suspect that because I'm unable to output audio to any pair of pins I choose when using the SIDcog demo program for the P2. Not only the P32-P39 bank is affected by this, but other banks as well (banks that didn't saw mishaps with 5V - as only the previously mentioned bank had such event).

    Chip, is there any way to isolate pins for troubleshooting? I mean, test a set of pins at a time?

    Kind regards, Samuel Lourenço

    If you can look at the pins at the end of the test, you can see the first four pins that failed. The first failed-pin code will be on P[7:0] with the first failed-pin number on P[15:08]. Up to three more failed-pin reports will be on P[31:16], P[47:32], and P[63:48].

    You can also cause it to ignore certain pin failures by doing a 'WRBYTE #0,#pin' next to where the 'WRWORD #0,#62' is.
    Hi Chip,

    I don't quite understand. So, I have to probe those pins and see their values at the end of the test? And then decode their values?

    Kind regards, Samuel Lourenço
  • samuell wrote: »
    cgracey wrote: »
    samuell wrote: »
    To add to my previous comment, this is how I'm setting the function generator. Since I'm using its digital output, the 8Vpp setting is of no consequence, since it only affects the analog output. This high setting makes the output less jittery, though.

    Update: Tested pins 0 through 61 via TAQOZ. All pins were able to output 285.3KHz when set to blink at 1 MHz. I suspect the reason why the test fails might be due to an analog output/input issue. I suspect that because I'm unable to output audio to any pair of pins I choose when using the SIDcog demo program for the P2. Not only the P32-P39 bank is affected by this, but other banks as well (banks that didn't saw mishaps with 5V - as only the previously mentioned bank had such event).

    Chip, is there any way to isolate pins for troubleshooting? I mean, test a set of pins at a time?

    Kind regards, Samuel Lourenço

    If you can look at the pins at the end of the test, you can see the first four pins that failed. The first failed-pin code will be on P[7:0] with the first failed-pin number on P[15:08]. Up to three more failed-pin reports will be on P[31:16], P[47:32], and P[63:48].

    You can also cause it to ignore certain pin failures by doing a 'WRBYTE #0,#pin' next to where the 'WRWORD #0,#62' is.
    Hi Chip,

    I don't quite understand. So, I have to probe those pins and see their values at the end of the test? And then decode their values?

    Kind regards, Samuel Lourenço
    samuell wrote: »
    cgracey wrote: »
    samuell wrote: »
    To add to my previous comment, this is how I'm setting the function generator. Since I'm using its digital output, the 8Vpp setting is of no consequence, since it only affects the analog output. This high setting makes the output less jittery, though.

    Update: Tested pins 0 through 61 via TAQOZ. All pins were able to output 285.3KHz when set to blink at 1 MHz. I suspect the reason why the test fails might be due to an analog output/input issue. I suspect that because I'm unable to output audio to any pair of pins I choose when using the SIDcog demo program for the P2. Not only the P32-P39 bank is affected by this, but other banks as well (banks that didn't saw mishaps with 5V - as only the previously mentioned bank had such event).

    Chip, is there any way to isolate pins for troubleshooting? I mean, test a set of pins at a time?

    Kind regards, Samuel Lourenço

    If you can look at the pins at the end of the test, you can see the first four pins that failed. The first failed-pin code will be on P[7:0] with the first failed-pin number on P[15:08]. Up to three more failed-pin reports will be on P[31:16], P[47:32], and P[63:48].

    You can also cause it to ignore certain pin failures by doing a 'WRBYTE #0,#pin' next to where the 'WRWORD #0,#62' is.
    Hi Chip,

    I don't quite understand. So, I have to probe those pins and see their values at the end of the test? And then decode their values?

    Kind regards, Samuel Lourenço

    That is right. You need to learn the values of those 64 pins. You'll have up to 4 errors' worth of data.
  • samuellsamuell Posts: 323
    edited 2019-07-04 - 20:12:48
    Hi Chip,

    Did two runs of tests. At the end of the test, there are no pins showing logic high (3.3V), except on the last bank.

    First run:
    P[7:0] = 0b00000000
    P[15:8] = 0b00000000
    P[23:16] = 0b00000000
    P[31:24] = 0b00000000
    P[39:32] = 0b00000000
    P[47:40] = 0b00000000
    P[55:48] = 0b00000000
    P[63:56] = 0b10011001

    Second run:
    P[7:0] = 0b00000000
    P[15:8] = 0b00000000
    P[23:16] = 0b00000000
    P[31:24] = 0b00000000
    P[39:32] = 0b00000000
    P[47:40] = 0b00000000
    P[55:48] = 0b00000000
    P[63:56] = 0b10011001

    I should mention that I've tested this using the prototyping board populated with LEDs and resistors to ground. One LED and series resistor for each pin, to ground. I've confirmed these observations with the oscilloscope.

    I suspect that the clock is too weak with a 1K resistor in series. Attached is a capture of what I see after the 1K resistor, unloaded, using a 10x probe.

    Kind regards, Samuel Lourenço
    800 x 600 - 23K
  • cgraceycgracey Posts: 11,266
    edited 2019-07-04 - 14:56:58
    samuell wrote: »
    Hi Chip,

    Did two runs of tests. At the end of the test, there are no pins showing logic high (3.3V), except on the last bank.

    First run:
    P[7:0] = 0b00000000
    P[15:8] = 0b00000000
    P[23:16] = 0b00000000
    P[31:24] = 0b00000000
    P[39:32] = 0b00000000
    P[47:40] = 0b00000000
    P[55:48] = 0b00000000
    P[63:56] = 0b10011001

    Second run:
    P[7:0] = 0b00000000
    P[15:8] = 0b00000000
    P[23:16] = 0b00000000
    P[31:24] = 0b00000000
    P[39:32] = 0b00000000
    P[47:40] = 0b00000000
    P[55:48] = 0b00000000
    P[63:56] = 0b10011001

    I should mention that I've tested this using the prototyping board populated with LEDs and resistors to ground. One LED and series resistor for each pin, to ground. I've confirmed these observations with the oscilloscope.

    I suspect that the clock is too weak with a 1K resistor in series. Attached is a capture of what I see after the 1K resistor, unloaded, using a 10x probe.

    Kind regards, Samuel Lourenço

    Ah, so that $99 on the top eight pins is the earliest error code possible and it indicates that the PLL test failed. That is the part of the test that needs P62 driven at 1MHz. The assumption is that you've got a 20MHz crystal attached between XI and XO, or XI is being driven at 20MHz.

    To pass the test, all pins must be free, without anything attached that could impede the DACs or the 10uA or 150k drive modes. The only pins which can have anything attached are P62 and P63, and they should error, in consequence of the P2 Eval board's connections, but their errors are cancellled with the 'WRWORD #0,#62'.

    I hope this helps.
  • samuellsamuell Posts: 323
    edited 2019-07-04 - 16:59:25
    cgracey wrote: »
    samuell wrote: »
    Hi Chip,

    Did two runs of tests. At the end of the test, there are no pins showing logic high (3.3V), except on the last bank.

    First run:
    P[7:0] = 0b00000000
    P[15:8] = 0b00000000
    P[23:16] = 0b00000000
    P[31:24] = 0b00000000
    P[39:32] = 0b00000000
    P[47:40] = 0b00000000
    P[55:48] = 0b00000000
    P[63:56] = 0b10011001

    Second run:
    P[7:0] = 0b00000000
    P[15:8] = 0b00000000
    P[23:16] = 0b00000000
    P[31:24] = 0b00000000
    P[39:32] = 0b00000000
    P[47:40] = 0b00000000
    P[55:48] = 0b00000000
    P[63:56] = 0b10011001

    I should mention that I've tested this using the prototyping board populated with LEDs and resistors to ground. One LED and series resistor for each pin, to ground. I've confirmed these observations with the oscilloscope.

    I suspect that the clock is too weak with a 1K resistor in series. Attached is a capture of what I see after the 1K resistor, unloaded, using a 10x probe.

    Kind regards, Samuel Lourenço

    Ah, so that $99 on the top eight pins is the earliest error code possible and it indicates that the PLL test failed. That is the part of the test that needs P62 driven at 1MHz. The assumption is that you've got a 20MHz crystal attached between XI and XO, or XI is being driven at 20MHz.

    To pass the test, all pins must be free, without anything attached that could impede the DACs or the 10uA or 150k drive modes. The only pins which can have anything attached are P62 and P63, and they should error, in consequence of the P2 Eval board's connections, but their errors are cancellled with the 'WRWORD #0,#62'.

    I hope this helps.
    That is correct. I have the 20MHz crystal connected, as is on the Eval Board. Unfortunately, the only way to disconnect it is to remove it completely, since I don't see any jumpers. Evan also had the same setup, crystal and all, and it passed.

    I have to look at the source code and see what is commented out. The statement you refer to is present in the line 190, and in full effect.
    wrword	#0,#62			'cancel errors for pins 62/63			COMMENT OUT FOR PRODUCTION
    

    Kind regards, Samuel Lourenço
  • samuell wrote: »
    cgracey wrote: »
    samuell wrote: »
    Hi Chip,

    Did two runs of tests. At the end of the test, there are no pins showing logic high (3.3V), except on the last bank.

    First run:
    P[7:0] = 0b00000000
    P[15:8] = 0b00000000
    P[23:16] = 0b00000000
    P[31:24] = 0b00000000
    P[39:32] = 0b00000000
    P[47:40] = 0b00000000
    P[55:48] = 0b00000000
    P[63:56] = 0b10011001

    Second run:
    P[7:0] = 0b00000000
    P[15:8] = 0b00000000
    P[23:16] = 0b00000000
    P[31:24] = 0b00000000
    P[39:32] = 0b00000000
    P[47:40] = 0b00000000
    P[55:48] = 0b00000000
    P[63:56] = 0b10011001

    I should mention that I've tested this using the prototyping board populated with LEDs and resistors to ground. One LED and series resistor for each pin, to ground. I've confirmed these observations with the oscilloscope.

    I suspect that the clock is too weak with a 1K resistor in series. Attached is a capture of what I see after the 1K resistor, unloaded, using a 10x probe.

    Kind regards, Samuel Lourenço

    Ah, so that $99 on the top eight pins is the earliest error code possible and it indicates that the PLL test failed. That is the part of the test that needs P62 driven at 1MHz. The assumption is that you've got a 20MHz crystal attached between XI and XO, or XI is being driven at 20MHz.

    To pass the test, all pins must be free, without anything attached that could impede the DACs or the 10uA or 150k drive modes. The only pins which can have anything attached are P62 and P63, and they should error, in consequence of the P2 Eval board's connections, but their errors are cancellled with the 'WRWORD #0,#62'.

    I hope this helps.
    That is correct. I have the 20MHz crystal connected, as is on the Eval Board. Unfortunately, the only way to disconnect it is to remove it completely, since I don't see any jumpers. Evan also had the same setup, crystal and all, and it passed.

    I have to look at the source code and see what is commented out. The statement you refer to is present in the line 190, and in full effect.
    wrword	#0,#62			'cancel errors for pins 62/63			COMMENT OUT FOR PRODUCTION
    

    Kind regards, Samuel Lourenço

    Your P2 Eval board should pass. Make sure nothing is connected to the 8-pin ports.
  • cgracey wrote: »
    samuell wrote: »
    cgracey wrote: »
    samuell wrote: »
    Hi Chip,

    Did two runs of tests. At the end of the test, there are no pins showing logic high (3.3V), except on the last bank.

    First run:
    P[7:0] = 0b00000000
    P[15:8] = 0b00000000
    P[23:16] = 0b00000000
    P[31:24] = 0b00000000
    P[39:32] = 0b00000000
    P[47:40] = 0b00000000
    P[55:48] = 0b00000000
    P[63:56] = 0b10011001

    Second run:
    P[7:0] = 0b00000000
    P[15:8] = 0b00000000
    P[23:16] = 0b00000000
    P[31:24] = 0b00000000
    P[39:32] = 0b00000000
    P[47:40] = 0b00000000
    P[55:48] = 0b00000000
    P[63:56] = 0b10011001

    I should mention that I've tested this using the prototyping board populated with LEDs and resistors to ground. One LED and series resistor for each pin, to ground. I've confirmed these observations with the oscilloscope.

    I suspect that the clock is too weak with a 1K resistor in series. Attached is a capture of what I see after the 1K resistor, unloaded, using a 10x probe.

    Kind regards, Samuel Lourenço

    Ah, so that $99 on the top eight pins is the earliest error code possible and it indicates that the PLL test failed. That is the part of the test that needs P62 driven at 1MHz. The assumption is that you've got a 20MHz crystal attached between XI and XO, or XI is being driven at 20MHz.

    To pass the test, all pins must be free, without anything attached that could impede the DACs or the 10uA or 150k drive modes. The only pins which can have anything attached are P62 and P63, and they should error, in consequence of the P2 Eval board's connections, but their errors are cancellled with the 'WRWORD #0,#62'.

    I hope this helps.
    That is correct. I have the 20MHz crystal connected, as is on the Eval Board. Unfortunately, the only way to disconnect it is to remove it completely, since I don't see any jumpers. Evan also had the same setup, crystal and all, and it passed.

    I have to look at the source code and see what is commented out. The statement you refer to is present in the line 190, and in full effect.
    wrword	#0,#62			'cancel errors for pins 62/63			COMMENT OUT FOR PRODUCTION
    

    Kind regards, Samuel Lourenço

    Your P2 Eval board should pass. Make sure nothing is connected to the 8-pin ports.
    Nothing is connected on any of the ports, and the DIP switches are all set to the "off" position. The supply jumpers are set to the local LDOs. I have all voltages present and correct, except that my Vbus is on the low side (4.7V). The USB ports on my PC are definitely weak, because of the PPTCs, and I can't use them to supply power to the P2. I'm using a hub, but the hub is not happy either. But since the other voltages, Vcore and Vio, are nominal, it shouldn't matter, right?

    On another note, during the test, the current consumption rises to 0.14A on the "P2 USB" port and to 0.10A on the "PC USB" port. Shouldn't all the current simply be bypassed through the "P2 USB" port when power is being supplied to it?

    Kind regards, Samuel Lourenço

  • samuellsamuell Posts: 323
    edited 2019-07-04 - 17:57:34
    Update:

    Used an hefty USB charger module (my own creation), with a capacity of 2A per port, to supply power to the board. The current now goes entirely through the "P2 USB" port. The fact that the Vbus voltage is dropped seems to allow a condition where the "PC USB" port power switch (U502) is not off, fully on in part. Vbus now reads 4.89V and is within spec.

    However, the test still fails, as expected. I don't think that Vbus is a factor, but managed to exclude that, anyway. Maybe the clock generator is not strong enough to drive the pin through a 1K resistor?

    Kind regards, Samuel Lourenço
  • samuell wrote: »
    Update:

    Used an hefty USB charger module (my own creation), with a capacity of 2A per port, to supply power to the board. The current now goes entirely through the "P2 USB" port. The fact that the Vbus voltage is dropped seems to allow a condition where the "PC USB" port power switch (U502) is not off, fully on in part. Vbus now reads 4.89V and is within spec.

    However, the test still fails, as expected. I don't think that Vbus is a factor, but managed to exclude that, anyway. Maybe the clock generator is not strong enough to drive the pin through a 1K resistor?

    Kind regards, Samuel Lourenço

    If you are still getting $99, that means that the PLL test is failing, which means that it's probably not getting the one megahertz signal into p62 okay.
  • cgracey wrote: »
    samuell wrote: »
    Update:

    Used an hefty USB charger module (my own creation), with a capacity of 2A per port, to supply power to the board. The current now goes entirely through the "P2 USB" port. The fact that the Vbus voltage is dropped seems to allow a condition where the "PC USB" port power switch (U502) is not off, fully on in part. Vbus now reads 4.89V and is within spec.

    However, the test still fails, as expected. I don't think that Vbus is a factor, but managed to exclude that, anyway. Maybe the clock generator is not strong enough to drive the pin through a 1K resistor?

    Kind regards, Samuel Lourenço

    If you are still getting $99, that means that the PLL test is failing, which means that it's probably not getting the one megahertz signal into p62 okay.
    Well, that is what I suspected. It is strange, though, because the signal generator I'm using should have a strong drive on its digital output. The output buffer (IC16) is a CDCLVC1102 from Texas, with both outputs connected for signal strength and better drive. I'm afraid I'm getting off-topic, because this shouldn't be about my DIY generator. But anyway, I've attached a schematic of it for debug. This is the only difference between the setup Evan is using and mine.

    Time to grab a P1 board? Maybe the activity board will work as a 1MHz clock generator?

    Kind regards, Samuel Lourenço
  • samuellsamuell Posts: 323
    edited 2019-07-04 - 20:09:48
    Finally! I've managed to have a repeatable passing test! The issue was caused by my signal generator. I've used an Analog Discovery to recreate a 3.3V CMOS clock, and now it passes as it should. It is very repeatable.

    Probably, the fail was triggered by the fast edges of the previous clock generator, that shows ringing when not loaded or terminated. It requires a 50R termination, but then again the amplitude is less than 3.3V if so. I'll have to test this.

    Kind regards, Samuel Lourenço
    1024 x 768 - 181K
  • To those who are curious and want to recreate this using the same device as a generator, please refer to the screenshot so see how the device is set up.

    Hope this helps!

    Kind regards, Samuel Lourenço
    1440 x 900 - 290K
  • samuellsamuell Posts: 323
    edited 2019-07-04 - 20:09:15
    OK, the previously used function generator was not to blame either. It was the wire that was making poor contact. The swap to the Analog Discovery forced me to swap the wire going to P62. The wire remained when I retested with the GF2 Function Generator. Anyway, spammed this forum too much today in order to solve this stupid issue. I'm very stubborn, sometimes.

    Thanks, Chip, for pointing me in the right direction! I was ready to give up and accept that I've damaged the board, somehow. After all, the board is perfectly fine!

    Kind regards, Samuel Lourenço
    1024 x 768 - 202K
  • Samuel,
    Congrats.

    You could trim, scale and recompress those photos though. They're huge but low quality. The forum is struggling.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • evanh wrote: »
    Samuel,
    Congrats.

    You could trim, scale and recompress those photos though. They're huge but low quality. The forum is struggling.
    Sorry, I was not aware of that, so I went the lazy way. The low quality doesn't fit the camera, though, being a Nikon D200. The photos were out of focus, and the lighting was not good.

    Anyway, fixed that. Trimmed and resized the photos. Re-compressed them using jpeg instead of png, because png takes about 1M of space for a 1024x768 photo. Thanks for making me aware!

    Kind regards, Samuel Lourenço
  • Samuel, I'm glad you got it working.

    These bumps along the way are normal.
  • samuell wrote: »
    It was the wire that was making poor contact. The swap to the Analog Discovery forced me to swap the wire going to P62.
    The white wire could be broken inside the heat-shrink. Good time to resolve what is wrong with the wire so doesn't cause future issues.

    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • samuellsamuell Posts: 323
    edited 2019-07-04 - 21:34:41
    cgracey wrote: »
    Samuel, I'm glad you got it working.

    These bumps along the way are normal.
    Had to many of these bumps in my life, caused by wires, connectors and stuff. It reminds me of when I worked at Synopsys, and had to perform constant troubleshooting, even though I already knew the setups and its most frequent issues. Not fond of these times (basically a very mild version of hell on earth - mild because the flames and pitchforks weren't there). Anyway, this troubleshooting only took this large amount of time, because I was in the middle of other work (coding, PCB layout, lunch meetings and whatnot) and had do disassemble the setup many times to free my desk. That left me little time to test this (typically at the end of the day, although today was an exception). :smile:
    evanh wrote: »
    samuell wrote: »
    It was the wire that was making poor contact. The swap to the Analog Discovery forced me to swap the wire going to P62.
    The white wire could be broken inside the heat-shrink. Good time to resolve what is wrong with the wire so doesn't cause future issues.
    That translates to me as: cut it in half and put it into the bin. :wink:

    Kind regards, Samuel Lourenço
Sign In or Register to comment.