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.
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.
... 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.
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.
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)
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.
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.
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.
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?
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.
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?
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?
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.
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.
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 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
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.
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?
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?
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.
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?
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.
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.
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!
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!
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).
Comments
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.
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.
Mike
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.
Oh, you should be jumpered to the LDOs for analogue tests like this.
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.
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
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.
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.
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.
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.
Kind regards, Samuel Lourenço
Your P2 Eval board should pass. Make sure nothing is connected to the 8-pin ports.
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
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.
Time to grab a P1 board? Maybe the activity board will work as a 1MHz clock generator?
Kind regards, Samuel Lourenço
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
Hope this helps!
Kind regards, Samuel Lourenço
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
Congrats.
You could trim, scale and recompress those photos though. They're huge but low quality. The forum is struggling.
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
These bumps along the way are normal.
That translates to me as: cut it in half and put it into the bin.
Kind regards, Samuel Lourenço