Unable to flash (in 1 button mode) about amigargbtohdmi HOT 12 CLOSED

The versioning is working by pulling an ID from the CPLD and matching that up with details in the Pi's software. If they were from a Chinese supplier it is more than possible they were pulled from something and the software is reading this as the BBC version.

Equally possible is the Pi itself could have a damaged GPIO. I would check this too. Details on how to use GPIOtest can be found here (make sure the Pi is not connected): https://forums.raspberrypi.com/viewtopic.php?t=180505

Finally, what exactly happens when you try to overwrite the flash? Does it show a flashing text or does it return immediately?

from amigargbtohdmi.

Hi,
Thanks for your quick reply.
For GPIO, all is good and tried 2 RPi,.
I am able to erase / (re)program 1 of the CPLD and it works on the Amiga. 9 others are failures.
Here are 2 videos.
First one is with the working one (debug/erasing/flashing).
The other is What I get with a bad CPLD (debug/erasing/flashing)
https://youtu.be/uMGF5WQTbJ0
https://youtu.be/LkSqpSJheZQ

I have opened a dispute on ALI /PayPal.
The supplier is my trusted Altera MAXII provider for PiSrorms and has been flawless.
But for those X9572XL it is not the same story :-(
Thanks again for your work and this fast reply.
Br.
Cédric

from amigargbtohdmi.

Things to check:
R1 - make sure it is a 1K resistor and not a higher value
R2 - make sure this is soldered correctly

Check pins 44, 11, 10, 9, 24 for solder bridges.

Assuming that is all good, then I would say that it is safe to assume the other CPLDs probably aren't good (or are at least not what is badged).

from amigargbtohdmi.

Will do that today ;-)
I have checked solder bridges in production as I solder under microscope. Most board are looking that way.
https://photos.app.goo.gl/Ty7gdCurFB7EDUAR7

Boards are JLCPCB FR4 150 type (thicker than 140)
For R value, true that I have not checked them. From What I have read I could even remove it as RPi would take care of the pull.

Thanks a million. Will try ASAP.

from amigargbtohdmi.

Both R2 and R1 are pulls to communicate something to the Pi. R2 is pretty flexible in value but R1 has to be 1K because on the Pi this is an I2C pin, any higher and it doesn't pull. If you don't have R1 or it is too high a value then the Pi will think this is a legacy BBC board and misbehave.
The pulls that aren't required are for the buttons and are already removed on this design.

from amigargbtohdmi.

I'll swap resistor. Value is between 600 and 1K on my cheap multimeter. I'll compare from the working one. Resistors are from same batch.
I'll report back.
Thk

from amigargbtohdmi.

600-1K should be fine. I've seen a couple of people accidentally put a 4.7K there once or twice and it caused the firmware flashing menus to misbehave.

Off the top of my head, R2 tells the Pi there is a CPLD, without it the Pi will think it is a fixed-logic RGBtoHDMI board.

from amigargbtohdmi.

I tried with 910ohm resistor to be sure my 1k serie would be bad. On multi 1k reads 1k and 910 ohm reads 910 as well.
Swapping did not fix issue so I can confirm CPLD is more than likely bad.
New batch of CPLD is coming soon.
Thanks for your help and all the details that I can use to troubleshoot the build.
My sincere respect to you!!!!

from amigargbtohdmi.

I've build over a 100 of these and I have two Zeros and one Zero 2 that have damaged GPIO that will cause this issue.

I was pulling my hair out the first time it happened before I figured out it was the GPIO.

from amigargbtohdmi.

Ah, yes. I suspect a damaged GPIO could do this.

from amigargbtohdmi.

In my case I use rose RPi for testing Pistorms with EMU68. GPIO are fine. I also ran GPIO test.
And a pulled CPLD from a working devboards works fine too.
Got the bad parts reimbursed
But thanks tor tour input.

from amigargbtohdmi.

Closing this one for now.

from amigargbtohdmi.