Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange Behaviour from pico in Jrunner #17

Open
idevicedesigner opened this issue Jul 29, 2022 · 29 comments
Open

Strange Behaviour from pico in Jrunner #17

idevicedesigner opened this issue Jul 29, 2022 · 29 comments

Comments

@idevicedesigner
Copy link

So i've been looking around for days, and i've recently just posted to reddit about this issue, that despite checking my wiring numerous times, having others assess my soldering, and flashing and reflashing the picoflasher software (version 2.0 and 3.0, with compatible jrunner versions that i have archived across both my desktop pc and my laptop), i am getting the error "0x00000000" console not found, with the green light on the pico toggling on and off everytime i try to query the console board type, as well as when i press "read NAND". After referring to a post on reddit from Octal450, i saw that when trying to setup everything in a specific order (connecting the pico, opening jrunner, then applying standby power, i yield the error "0xFFFFFFFF" instead, and i still get the phrase console not found. i haven't tried with a different picoflasher, as at the time i hadn't a lot of money to devote to my RGH project, perhaps there is anything you can look into regarding this? if you need me to provide anything, i gladly will

@ghost
Copy link

ghost commented Jul 30, 2022

Im sorta having a similar issue? I know my soldering is good as I have two matching valid nand dumps in JRunner, and I havent touched the nand since I added it. Im also using a Pico, Since writing the ECC most of the time I get 0xffffffff when identifying the console, the rest of the time I get Console not found. Ive checked, double checked, triple checked, quadruple checked my soldering and this isn't my first time with a soldering iron, or with a Corona 4GB, but it is my first with a Pico. Ive tried the same steps as yourself, connecting in specific orders, random orders, etc. It gave me two dumps right away, then since then nothing works to recognise the console, I disconnected the Pico USB to solder the RGH3 wires, and now it doesn't register the console at all :/

@NotPhoton
Copy link

Where did you buy your pico from? I think there might just be fake/faulty boards coming from Amazon as that's where my board came from, and a couple other people have mentioned bad boards coming from Amazon.

@idevicedesigner
Copy link
Author

idevicedesigner commented Aug 1, 2022 via email

@NotPhoton
Copy link

Yeah I bought it from amazon, I'll see if I can send you the link 

That would be awesome. Mine was purchased from Seeed Starter's Amazon marketplace, though reading up on them after the fact it sounds like they don't produce very high quality parts. A couple of the pins on the rp2040 chip on mine don't look super solid, it might be worth checking continuity of the pins on yours if you have access to a multimeter

@ghost
Copy link

ghost commented Aug 1, 2022

Where did you buy your pico from? I think there might just be fake/faulty boards coming from Amazon as that's where my board came from, and a couple other people have mentioned bad boards coming from Amazon.

I bought mine from the pi hut in the UK, was buying a Pi 4 at the time and grabbed it cheap enough, it’s the recommended sales part for Raspberry in the Uk, I stay away from eBay and amazon for the same reasons

edit: got a replacement coming today, but managed to get this one to detect a friends console once last night, then it stopped reading. I checked all continuity and it was fine, didn’t desolder anything, nothing. Reflashing the uf2 got the console detected until I disconnected the USB again, then it couldn’t find the console until flashing again.

@X360Tools X360Tools deleted a comment from fabio296 Aug 2, 2022
@NotPhoton
Copy link

managed to get this one to detect a friends console once last night, then it stopped reading. I checked all continuity and it was fine, didn’t desolder anything, nothing. Reflashing the uf2 got the console detected until I disconnected the USB again, then it couldn’t find the console until flashing again.

It's a little odd that yours will actually detect a console for a short while. On mine it just stops at 0xf and crashes the program. Exact same behavior on 3 different laptops, 2 different versions of windows, both jrunner with extras and jrunner pro, and soldering triple checked.

Does the picoflasher logo appear in jrunner after reconnecting?

@idevicedesigner
Copy link
Author

idevicedesigner commented Aug 2, 2022 via email

@ghost
Copy link

ghost commented Aug 2, 2022

managed to get this one to detect a friends console once last night, then it stopped reading. I checked all continuity and it was fine, didn’t desolder anything, nothing. Reflashing the uf2 got the console detected until I disconnected the USB again, then it couldn’t find the console until flashing again.

It's a little odd that yours will actually detect a console for a short while. On mine it just stops at 0xf and crashes the program. Exact same behavior on 3 different laptops, 2 different versions of windows, both jrunner with extras and jrunner pro, and soldering triple checked.

Does the picoflasher logo appear in jrunner after reconnecting?

Only when I reflash the UF2 at this point, that’s when I can detect a console for a single read, after that I’m in the same position again. About 80% of the time I get a flash of the picoFlasher logo before it disappears, when I load it in flash mode Jrunner finds it as a flash drive about 60% of the time while windows every time.

@NotPhoton
Copy link

I've sorta come to the conclusion that there are just a lot of fake/faulty Picos out in the wild. With a brand new pico, I was able to fully finish the mod. Upon inspecting the 2 picos (new and fake), I noticed that the legit board is a couple shades darker than the fake, and the text on the new rp2040 chip is a lot easier to read than on the fake.

@ghost
Copy link

ghost commented Aug 5, 2022

I've sorta come to the conclusion that there are just a lot of fake/faulty Picos out in the wild. With a brand new pico, I was able to fully finish the mod. Upon inspecting the 2 picos (new and fake), I noticed that the legit board is a couple shades darker than the fake, and the text on the new rp2040 chip is a lot easier to read than on the fake.

Can you upload a side by side so I can compare my boards? I wouldn’t like to think they were fake but…

@NotPhoton
Copy link

NotPhoton commented Aug 5, 2022

https://imgur.com/a/u5y9GY5
Left is fake, right is real. Its a little hard to tell the color difference with the lighting in my room, but the major thing to focus on is the etching on the chip. The fake board has a glossier chip and harder to read etching, while the real one is matte and easier to read.

@ghost
Copy link

ghost commented Aug 5, 2022

https://imgur.com/a/u5y9GY5
Left is fake, right is real. Its a little hard to tell the color difference with the lighting in my room, but the major thing to focus on is the etching on the chip. The fake board has a glossier chip and harder to read etching, while the real one is matte and easier to read.

….fuck. @balika011 Might be worth adding in that fake Picos are fucking shit. Also avoid the Pi Hut in the UK, lol. Thanks for that, confirms mine is also fake af.

@ferrycosv
Copy link

Guys, I'm in the same boat. Got one from ebay and is exactly as the one on the left with a darker etching on the chip, pure shit. Anyone can recommend a legit seller in the UK? I thought the pi hut was recommended by the official website and now I find out they're selling fake products what a shame!

@idevicedesigner
Copy link
Author

So, coming back to this, ive taken a look at my pico, and it looks very similar to the photo on the left, you can only faintly see the pico etching under direct light sources, close up, such as my phone's torch. the seller on amazon is known as 'Coolwel' so potentially they are either trafficking fake pico's or they aren't aware that they are counterfeit. ill attach a photo of my board for people to also compare theirs to. https://imgur.com/a/WhiIO92

@NotPhoton
Copy link

Guys, I'm in the same boat. Got one from ebay and is exactly as the one on the left with a darker etching on the chip, pure shit. Anyone can recommend a legit seller in the UK? I thought the pi hut was recommended by the official website and now I find out they're selling fake products what a shame!

I personally am in the US, but looking at the list of approved sellers in the UK I would try pimoroni. I've bought some of their parts before and they've always been quality

@ferrycosv
Copy link

Thank you for your reply, I was able to flash the firmware with the fake pico. I figure out a sequence to make it work, first connect everything up flasher and rgh to the motherboard, then apply standby power to the console and connect your pico to the PC, if you already flashed the uf2 picoflasher file look for the flash_nuke.uf2 file on the official site to wipe your flash clean, remember to put your pico in flashing mode, do this with everything connected and make sure the jrunner is open as well, then flash the picoflasher uf2 file to your pico and it will be detected by jrunner you will be able to read or write the nand you need to repeat these steps every time you disconnect the pico from PC or it's not recognized by jrunner anymore or jrunner is not able to detect your console, I hope this could help people having the same issue I've just flashed my console and is working great!

@ghost
Copy link

ghost commented Aug 12, 2022

Guys, I'm in the same boat. Got one from ebay and is exactly as the one on the left with a darker etching on the chip, pure shit. Anyone can recommend a legit seller in the UK? I thought the pi hut was recommended by the official website and now I find out they're selling fake products what a shame!

Im also disappointed in The Pi Hut, but Ive been in touch with support and have sent my Pi back to be checked over, They've also independently verified that a delivery was sent with a batch of fake Pico's, and have sent me two replacements to my fakes. Can't fault the support, and as soon as I flashed the UF2 and wired it up, I got a first time read. So there's a definite issue with Fake Pico's, Im gonna fork and submit a PR with that info at the top,

@NotPhoton
Copy link

Im also disappointed in The Pi Hut, but Ive been in touch with support and have sent my Pi back to be checked over, They've also independently verified that a delivery was sent with a batch of fake Pico's, and have sent me two replacements to my fakes. Can't fault the support, and as soon as I flashed the UF2 and wired it up, I got a first time read. So there's a definite issue with Fake Pico's, Im gonna fork and submit a PR with that info at the top

Man, can't fault that support at all. Good on them for confirming our suspicions and completely fixing your problem.

@a-hurst
Copy link

a-hurst commented Aug 28, 2022

Running into the same issue with my Pico. It was working fine a few weeks ago (took guesswork sequences of disconnects/reconnects to recognize the console, but still worked), but I ran into some strange problems with it using it for something else, and now PicoFlasher always gives me either 0x00000000 or 0xFFFFFFFF with a different Trinity.

Is there any way of figuring out where in the PicoFlasher code the fake Picos are tripping up? I tested all the relevant pins by setting them to 3.3V with micropython and they all work fine, and the firmware flashes and gets detected by J-Runner reliably. I also tried flashing PicoFlasher v1 and reading the NAND with the original dump_nand.cpp example from a Linux VM and that failed in the same way (console ID returned as 0), so it's not an OS-related specific problem either.

From the source code it looks like console identification is just reading a value from an SPI register after init, so there don't seem to be too many points of failure to check:

PicoFlasher/xbox.c

Lines 72 to 79 in 84a751b

uint32_t xbox_get_flash_config()
{
static uint32_t flash_config = 0;
if (!flash_config)
flash_config = spiex_read_reg(0);
return flash_config;
}

Maybe something in the SPI code isn't working properly on these fake chips? How would you test it?

Also, has anyone found any other sources of info talking about the counterfeit Picos? I've searched all over to see if any other projects are having issues related to these faded chips, but so far I haven't found anything.

EDIT: Found another (much older) 360 NAND flasher project on github that uses a different controller. In its code, it reads the flash config register twice in a row via SPI (and has a comment suggesting it's deliberate). The PicoFlasher code only reads the register once. Maybe there's some hardware quirk that means a second read is needed?

@ghost
Copy link

ghost commented Sep 1, 2022

Running into the same issue with my Pico. It was working fine a few weeks ago (took guesswork sequences of disconnects/reconnects to recognize the console, but still worked), but I ran into some strange problems with it using it for something else, and now PicoFlasher always gives me either 0x00000000 or 0xFFFFFFFF with a different Trinity.

Is there any way of figuring out where in the PicoFlasher code the fake Picos are tripping up? I tested all the relevant pins by setting them to 3.3V with micropython and they all work fine, and the firmware flashes and gets detected by J-Runner reliably. I also tried flashing PicoFlasher v1 and reading the NAND with the original dump_nand.cpp example from a Linux VM and that failed in the same way (console ID returned as 0), so it's not an OS-related specific problem either.

From the source code it looks like console identification is just reading a value from an SPI register after init, so there don't seem to be too many points of failure to check:

PicoFlasher/xbox.c

Lines 72 to 79 in 84a751b

uint32_t xbox_get_flash_config()
{
static uint32_t flash_config = 0;
if (!flash_config)
flash_config = spiex_read_reg(0);
return flash_config;
}

Maybe something in the SPI code isn't working properly on these fake chips? How would you test it?

Also, has anyone found any other sources of info talking about the counterfeit Picos? I've searched all over to see if any other projects are having issues related to these faded chips, but so far I haven't found anything.

EDIT: Found another (much older) 360 NAND flasher project on github that uses a different controller. In its code, it reads the flash config register twice in a row via SPI (and has a comment suggesting it's deliberate). The PicoFlasher code only reads the register once. Maybe there's some hardware quirk that means a second read is needed?

Im not sure if thats necessary, but could be tested by forking the project, adding and compiling with changes, Im not sure if its fake Picos or not, but Ive now done 7 consoles with one of the replacements from PiHub and no issues at all on all 7. Ive only had issues since v3.0 though, so maybe 4gb eMMC issues, as thats where my biggest issue lies. I can read the 4gb via an SD Tool, but the same wiring just with the Pico errors on the fake, works fine on the genuine.

@Adran-Marit
Copy link

Running into the same issue with my Pico. It was working fine a few weeks ago (took guesswork sequences of disconnects/reconnects to recognize the console, but still worked), but I ran into some strange problems with it using it for something else, and now PicoFlasher always gives me either 0x00000000 or 0xFFFFFFFF with a different Trinity.
Is there any way of figuring out where in the PicoFlasher code the fake Picos are tripping up? I tested all the relevant pins by setting them to 3.3V with micropython and they all work fine, and the firmware flashes and gets detected by J-Runner reliably. I also tried flashing PicoFlasher v1 and reading the NAND with the original dump_nand.cpp example from a Linux VM and that failed in the same way (console ID returned as 0), so it's not an OS-related specific problem either.
From the source code it looks like console identification is just reading a value from an SPI register after init, so there don't seem to be too many points of failure to check:

PicoFlasher/xbox.c

Lines 72 to 79 in 84a751b

uint32_t xbox_get_flash_config()
{
static uint32_t flash_config = 0;
if (!flash_config)
flash_config = spiex_read_reg(0);
return flash_config;
}

Maybe something in the SPI code isn't working properly on these fake chips? How would you test it?
Also, has anyone found any other sources of info talking about the counterfeit Picos? I've searched all over to see if any other projects are having issues related to these faded chips, but so far I haven't found anything.
EDIT: Found another (much older) 360 NAND flasher project on github that uses a different controller. In its code, it reads the flash config register twice in a row via SPI (and has a comment suggesting it's deliberate). The PicoFlasher code only reads the register once. Maybe there's some hardware quirk that means a second read is needed?

Im not sure if thats necessary, but could be tested by forking the project, adding and compiling with changes, Im not sure if its fake Picos or not, but Ive now done 7 consoles with one of the replacements from PiHub and no issues at all on all 7. Ive only had issues since v3.0 though, so maybe 4gb eMMC issues, as thats where my biggest issue lies. I can read the 4gb via an SD Tool, but the same wiring just with the Pico errors on the fake, works fine on the genuine.

For me I found FW 2.0 worked without the disconnect issue on my pico (which is fake according to whats been shown earlier in this thread) but I can't tell too much what actually changed code wise to make it not work thereafter?

@a-hurst
Copy link

a-hurst commented Sep 4, 2022

Im not sure if thats necessary, but could be tested by forking the project, adding and compiling with changes,

Tried it, unfortunately no difference. I ended up biting the bullet and ordering another Pico (this time from Amazon), and it worked perfectly for my RGH3, not a single "console not found" issue! For the sake of documentation, here's a photo of the backs of my two Picos (the left one is the new one that works great, the right one is the one that couldn't detect the console):

pico_compare

In addition to the differences in logo visibility on the front as mentioned before, I also noticed that on the back, the QR code for the problem Pico is much smaller and a different shade of gold, and also that the numbers in the middle are different (2121 - 1.18 vs 3221 - 6.20). The board is also a different shade of green with the traces more visible. Not sure if any of these are defining features of a fake Pico, but if anyone else can confirm their problem Picos share any of these traits it should help future people with identifying bad ones (hard to tell if your logo is faded until you have two side by side).

Not sure when I'll next have a disassembled 360 in front of me, but I think the best way to get to the bottom of this issue would be to load a fake Pico with PicoFlasher, load a second Pico with Scoppy or another Pico Logic Analyzer ROM (ideally one with SPI support), and then see what's actually getting sent from the problem Pico when it's failing to identify the console. There's not actually that much going on in the PicoFlasher code before sending the "read console identity" command (just setting a few pins high/low to get the 360 into the right state), so it should be fairly straightforward to see what the fake Pico is failing to do.

If we can figure out the why behind this, it might be possible to modify PicoFlasher to work around whatever limitation the fake Picos are running into.

@idevicedesigner
Copy link
Author

idevicedesigner commented Oct 11, 2022 via email

@TimoArrg
Copy link

Hello everyone. I'm having the same exact problem, I have a 4gB corona, picoflasher3.0 and i'm running jrunner 3.2.1 r2. I have tried absolutely everything i could to get thing thing to read the consoles nand but it just can't. i have even tried a new raspberry pi pico that according to the pictures shown here should be original but still, nothing. Is there any fix?

@Adran-Marit
Copy link

Hello everyone. I'm having the same exact problem, I have a 4gB corona, picoflasher3.0 and i'm running jrunner 3.2.1 r2. I have tried absolutely everything i could to get thing thing to read the consoles nand but it just can't. i have even tried a new raspberry pi pico that according to the pictures shown here should be original but still, nothing. Is there any fix?

Silly question but Is your pico wired up in the 4gb configuration

@TimoArrg
Copy link

Yes, absolutely. I have it setup with the 4gB wiring diagram. Not the same used in the phat consoles for example

@pacman362
Copy link

I have just ordered 10 RP2040 processors and im going to replace one on my pico that is not working with J-runner to see if the fake one can be brought to life fingers crossed.

@pacman362
Copy link

I have just ordered 10 RP2040 processors and im going to replace one on my pico that is not working with J-runner to see if the fake one can be brought to life fingers crossed.

Ok Update, fitted both my suspected FAKE Pico's with GENUINE RP2040's And im pleased to report they both work perfectly ! So in conclusion I suspect that the chips where indeed FAKE ! So all of you out there with dead Pico's Order yourselfs some new RP2040's and get reworking to bring them back from the dead for your RGH work.

@pacman362
Copy link

pacman362 commented Aug 6, 2023

Ps the new chips came from PIMORONI, 10 cost me £12 inc with postage and V.A.T.

Part Number/Code : SC0908-10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants