Pi Pico[W] Peripheral Expansion Box Side Port Device

[JasonACT]

13 hours ago, RickyDean said:

Well I got up and some 32k testing and here are the results, there is still an issue, not as pronounced but still there. In the ver 2.2 photos, it tested 0 -15 pages good, but failed on pages 16-23, if this gives a clue?

There are two possible reasons, the first being it's now too slow, however, I ran a full SAMS tests on all 3 of my boards @ 128MHz last night and they all passed.

 

So it's most probably the same issue as before, your PSRAM chip possibly doesn't run well at 128MHz.  Looking at the datasheet, at 3.3v, they are only rated at 109MHz - it's at 3.0v they are rated for 133MHz...  It does say 3.0v +/- 10% which puts it within spec, and I tested my Pi Pico's last night with a DMM and they are just a bit under 3.3v.  Now unfortunately, I have test cases that fail at the next lower frequency (127MHz) unless I disable some features.  I.E. the more code that gets compiled, the less chance GCC will optimise code paths to use registers, and so the code gets slower.

 

I'll have to run a few tests to work out which things I need to turn off (I think it's the PCode Card & the Action Replay feature) so I can't provide an update right away.

 

I reckon, if you have bought a handful of PSRAM chips, they will all be from the same batch and will most likely have the same limit (even though mine run at 138MHz and 135MHz for the two I bought) but it might be worth swapping one over to try.  Or are you able to order an ESP-PSRAM64H chip to test with?

 

The only other thought I have is, maybe there's some solder flux still hanging around on your board?  I did a fairly detailed clean up on all of mine and burned off anything remaining after that with my hot air rework station.

[RickyDean]

I bought two sets of 10 of the APS6404L-3SQR, the first being APS6404L-3SQR-ZR, therefore the wrong ones as they were USON IC's, so I had to reorder, or try to solder fine wire onto these and make them work. So I reordered the APS6404L-3SQR-SN and here I am. How would I go about changing the speeds? Maybe I can tinker on my side and make it work? I may be able to order one of the others, but I'll have to wait a bit as money has gotten a bit tight. So I have to be careful, for the moment on my spending, gone for at least awhile, are my two or three, electrical component orders from Mouser, Digikey, and Jameco, a week!

 

As for flux, I, after finishing my soldering, do take my boards outside and use carburetor cleaner and a tooth brush to clean them, does a great job of removing flux. On this second one, since I laid the pico on the pcb to solder it, used an alcohol wipe, down under the middle of the pcb that faces the underside of the pico, to remove excess flux, before soldering. I can't say for sure something isn't down under, but I can be fairly confident, flux isn't the issue

 

I did get the first one to flash after reflowing the solder at the risers, but it is still failing the 32k test with nothing passing. This using all three of your pico programs, so I must still have a solder issue or something else going on. I haven't tried changing around sd cards yet since I got it to flash.

 

Have a good day.

[JasonACT]

4 hours ago, RickyDean said:

I bought two sets of 10 of the APS6404L-3SQR, the first being APS6404L-3SQR-ZR, therefore the wrong ones as they were USON IC's, so I had to reorder, or try to solder fine wire onto these and make them work. So I reordered the APS6404L-3SQR-SN and here I am.

I'm sorry to hear that, I'll update my doco.

 

4 hours ago, RickyDean said:

How would I go about changing the speeds? Maybe I can tinker on my side and make it work?

The Arduino tool has the speed as a menu option, my doco explains how to add the extra options, once selected you need to edit my .ino file to match the frequency for 3 values (CPU, SD and PSRAM) from the table in the doco.  But don't bother doing this, I've tried now, and anything below 256MHz doesn't work for me - no matter which options I disable (I would have to fetch an old build from 2 months ago for it to work now, but there would be bugs in those old versions).  Actually, the 2.2 memory test does pass at 250MHz, but one of my other test cases does not, and I'm hesitant to upload a known bad image before more investigations...

 

4 hours ago, RickyDean said:

As for flux, I, after finishing my soldering, do take my boards outside and use carburetor cleaner and a tooth brush to clean them, does a great job of removing flux. On this second one, since I laid the pico on the pcb to solder it, used an alcohol wipe, down under the middle of the pcb that faces the underside of the pico, to remove excess flux, before soldering. I can't say for sure something isn't down under, but I can be fairly confident, flux isn't the issue

Yeah, your board looked pretty clean, but I thought I'd mention it.

 

4 hours ago, RickyDean said:

I did get the first one to flash after reflowing the solder at the risers, but it is still failing the 32k test with nothing passing. This using all three of your pico programs, so I must still have a solder issue or something else going on. I haven't tried changing around sd cards yet since I got it to flash.

I half suspect the risers on mine are what's holding back the ESP PSRAM chip to 130MHz.  I don't know for sure though, and I've run out of bare Pico's to try another.

 

I'm attaching a modified exptest, I edited JediMatt's, which outputs the 1st error detected, it might be worth running it a few times, so we can see how random your errors are (if they are not random, then it could be a bad chip).

 

 

exptest_c.zip

Edited January 10 by JasonACT

[RickyDean]

8 hours ago, JasonACT said:

I'm attaching a modified exptest, I edited JediMatt's, which outputs the 1st error detected, it might be worth running it a few times, so we can see how random your errors are (if they are not random, then it could be a bad chip).

 

 

exptest_c.zip 3.92 kB · 2 downloads

Okay, here are the results of the testing with this file. These tests were made one right after another, turning the console off and then back on, to be sure it was reset each time. Seems like as the unit was heating up, issues got worse. Picture 3 was made while it was running the test.

[RickyDean]

[+chue]

1 hour ago, RickyDean said:

Seems like as the unit was heating up, issues got worse.

Maybe you can put a fan on it and see if that makes a difference.  A bit of moving air should be fine - if the errors go away, then you know it is the chips running hot.

[RickyDean]

53 minutes ago, chue said:

Maybe you can put a fan on it and see if that makes a difference.  A bit of moving air should be fine - if the errors go away, then you know it is the chips running hot.

I'll have to see if I can find a small fan around. I was going to give it some cool down time and check it again, while I'm working other projects.

 

Well it'd been an hour or so. I just tried it again and got this screen, so heat may have some to do with it. If you look at the pages it's testing it goes some way when starting cold, before it errors. Do I need a heat sink on PSRAM, @JasonACT?

Edited January 10 by RickyDean

[RickyDean]

Well there goes that theory, I let it set about another 1 to 1.5 hours and tested it and it came up with this screen.

[JasonACT]

11 hours ago, RickyDean said:

Do I need a heat sink on PSRAM

I'm not using a heat sink at all, but if I were to put one anywhere it would be on the Pico.  It's also been near 30 degrees C here the past 2 days, without issue.

 

BTW: E=Expected Value, V=Value read & 2=2nd read (to see if the error was with writing or reading back).  So, you can see, it's mostly writing data correctly, if not always (the 2nd read may get the value wrong twice in a row).

 

You seem to be having issues with the high-byte (that is read last on the 4A) which is actually an optimised area in my code, since I've already got the address and I just need to mask off the A15 bit.  There's also a pattern you can sort of see, where 1 bit in the middle of the byte is flipped the wrong way, but it starts and ends mostly fine.

 

When I overclock mine to 280MHz (140MHz PSRAM) these are the errors I see:

 

 

I'm mostly having issues with the 1st byte being read (the low-byte).

 

So I'm stumped!

Edited January 11 by JasonACT
I wrote TMS9900, but meant 4A

[JasonACT]

Oh, I can see mine are at random addresses, yours seem to repeat at the same location - I can't explain that from the point of view of my software - there's nothing special happening at any particular address.

[RickyDean]

Okay not in any hurry, let me know if something comes to mind. As I said earlier, I at first thought it could be heat related, but then the last one came up with a bunch of errors, after about an hour or two cool down. So it is probably something else.

Edited January 11 by RickyDean
spelling

[JasonACT]

@RickyDean The guy on GitHub who wrote the PSRAM PIO code (that I stole - https://github.com/polpo/rp2040-psram ) did remove the fast slew rate setting some time after I downloaded his code.  I read today that using the fast rate may be noisy in some way, but I had kept it because turning it off meant I couldn't overclock the PSRAM as much.  Now that I'm underclocking it for you, I guess it's worth trying a version with it switch off:

PPEB2.ino.uf2.zip

[RickyDean]

14 minutes ago, JasonACT said:

@RickyDean The guy on GitHub who wrote the PSRAM PIO code (that I stole - https://github.com/polpo/rp2040-psram ) did remove the fast slew rate setting some time after I downloaded his code.  I read today that using the fast rate may be noisy in some way, but I had kept it because turning it off meant I couldn't overclock the PSRAM as much.  Now that I'm underclocking it for you, I guess it's worth trying a version with it switch off:

PPEB2.ino.uf2.zip 378.97 kB · 0 downloads

Running a memory test now, will let you know if it passes tonight, then I do a more strenuous series of test tomorrow. thanks 

[RickyDean]

39 minutes ago, JasonACT said:

@RickyDean The guy on GitHub who wrote the PSRAM PIO code (that I stole - https://github.com/polpo/rp2040-psram ) did remove the fast slew rate setting some time after I downloaded his code.  I read today that using the fast rate may be noisy in some way, but I had kept it because turning it off meant I couldn't overclock the PSRAM as much.  Now that I'm underclocking it for you, I guess it's worth trying a version with it switch off:

PPEB2.ino.uf2.zip 378.97 kB · 0 downloads

Okay, it made it much further down the road tonight, all the way to pages 192-199. But it still failed.

I test some more tomorrow. Have a great evening, good night.

 

 

Edited January 11 by RickyDean
additional content

[JasonACT]

Interesting (and frustrating!)...  And again one of the same addresses that regularly fail for you.

 

I'd be swapping the chip out, just to see if the failing addresses change - there's no good reason for it to always happen at those addresses.

[RickyDean]

2 minutes ago, JasonACT said:

Interesting (and frustrating!)...  And again one of the same addresses that regularly fail for you.

 

I'd be swapping the chip out, just to see if the failing addresses change - there's no good reason for it to always happen at those addresses.

I'll pull the PSRAM tomorrow and try another, thanks, will let you know the results.

[RickyDean]

@JasonACT

I must have a batch of bad chips, as I've replaced the ones on this board 3 times, with multiple reflows on the solder points to be make sure they were on the board tight. I get different address issues with each one, so I don't think its an issue with the placement of my pico, but I hit those solder points again as well. I don't know how well these psrams stand up too heat. I had tried to reflow the first two with a combination of tip and reflow blower, but this last IC I just stuck with a tip, in case I was overheating them. i may have to wait and get another style psram to test.

 

I'm ordering 10 Adafruit Accessories Generic 64 Mbit Serial Pseudo SRAM - 3.3V 133 MHz, which is what comes up at Mouser when I look for ESP-PSRAM64H psram.

Edited January 12 by RickyDean
spelling, added content

[JasonACT]

5 hours ago, RickyDean said:

I get different address issues with each one, so I don't think its an issue with the placement of my pico, but I hit those solder points again as well.

Wow, I don't know what to say.  But I reckon your Pico is fine too.

 

5 hours ago, RickyDean said:

I don't know how well these psrams stand up too heat.

I'm not sure, maybe it doesn't, that chip is tiny and is packed with ~67 million tiny capacitors.

 

6 hours ago, RickyDean said:

this last IC I just stuck with a tip, in case I was overheating them.

Yeah, that's how I did 2 of mine, but my first one was on the prototype board with wires.  All of them were done with a cooling delay between each pin too.

 

6 hours ago, RickyDean said:

I'm ordering 10 Adafruit Accessories Generic 64 Mbit Serial Pseudo SRAM - 3.3V 133 MHz, which is what comes up at Mouser when I look for ESP-PSRAM64H psram.

Ah, yeah, I ordered 5 of those, but have only tested 1 so far.  They are ESP chips, but the thing I didn't like was, they were not in original sealed packaging.  Mine came in 5 anti static bags with an Adafruit sticker part number 4677, and 2 of them had a bent pin each.  3 of them had the text wiped off, I tested the one with the clearest markings left on.  As you might know, that one maxed out at 130MHz, and I feel those guys might be testing the chips before selling them and keeping the ones that can be overclocked...  I can't explain why they were in such bad shape otherwise.  130MHz is plenty fast though.

[RickyDean]

Understood, I don't want to keep using these, when they all may be bad. I even replaced the psram on  board with the risers, the TI was saying no memory detected, so I replaced it with one of these that I've pulled to see what happened, this time it saw memory, but still failed, right after testing. It'll be a few days till those others come in, hopefully Saturday.

[JasonACT]

On 1/5/2024 at 6:34 PM, JasonACT said:

Also, yesterday, I built another unit with sockets - just for kicks - and with my latest build here, it fails JediMatt's SAMS memory test...  I'm using an ESP-PSRAM64H 8MB chip on that board and it turns out it only works up to 132MHz (Pi Pico overclocked to 264MHz) and not the 133MHz stated in the specs...  Or 135MHz slight overclock I'm using here...  I'm having a love/hate relationship with that company, a lot of their stuff is good but some is just bad.

After re-reading the notes I had made in my .ino file tonight, I saw the ESP chip had worked at 132MHz - not the lower 130MHz I remembered - which I can see now was a decision I had made to make the first fail-safe download, lowering it a bit and setting the SD card speed to something most cards would work with.  I also did some research today, and the Teensy forum suggests 132MHz is the top speed for their QSPI interface when using these chips.

 

I'm keeping my fingers crossed for you @RickyDean

[RickyDean]

On 1/15/2024 at 4:52 AM, JasonACT said:

After re-reading the notes I had made in my .ino file tonight, I saw the ESP chip had worked at 132MHz - not the lower 130MHz I remembered - which I can see now was a decision I had made to make the first fail-safe download, lowering it a bit and setting the SD card speed to something most cards would work with.  I also did some research today, and the Teensy forum suggests 132MHz is the top speed for their QSPI interface when using these chips.

 

I'm keeping my fingers crossed for you @RickyDean

Well I got in the 10 of these. The package says 64Mbit Serial Psuedo, http://adaru.it/4677. I removed the old psram and point to point soldered this one and it errors out first thing. I then reflowed, same errors. I may attempt one more replacement, tomorrow, then if that fails, I'll do something else. Don't want to keep throwing money at these. Maybe I can put in console memory and use the rest of the features, on these two boards. Or build a couple of the side mount 32k or Sams, with pass through if the plans for it are online somewhere.

[JasonACT]

43 minutes ago, RickyDean said:

and it errors out first thing. I then reflowed, same errors.

The two tester images above are the same test, can you post another image of a new test with the same chip?  It looks random to me, which is what I was getting when it was set too fast.  Maybe re-download the 260MHz .uf2.zip, so you know for sure which one is being flashed to the Pico, and try again?

 

I don't think it's worthwhile pulling this PSRAM chip off and trying another, there's probably something else wrong, and the heat required to get them off may be enough to ruin them unnecessarily.

[RickyDean]

3 minutes ago, JasonACT said:

The two tester images above are the same test, can you post another image of a new test with the same chip?  It looks random to me, which is what I was getting when it was set too fast.  Maybe re-download the 260MHz .uf2.zip, so you know for sure which one is being flashed to the Pico, and try again?

 

I don't think it's worthwhile pulling this PSRAM chip off and trying another, there's probably something else wrong, and the heat required to get them off may be enough to ruin them unnecessarily.

Same program two different tests, two different photos, first after the initial soldering, when I saw it was already showing those errors at the beginning, I took the photo, then pulled the unit and retested, with the same errors, so the reflow didn't change anthing. I will try the various files tomorrow, been a busy day today. Thanks for your response. Have a good evening.

[JasonACT]

4 minutes ago, RickyDean said:

Same program two different tests, two different photos, first after the initial soldering, when I saw it was already showing those errors at the beginning, I took the photo, then pulled the unit and retested, with the same errors, so the reflow didn't change anthing.

Wow, this is super crazy, and I can't (yet) think what's going wrong then.  It's basically getting the exact same set of wrong V: values and right 2: values each time in perfect sequence through the address range.  Your other chip(s) were not really doing that.  I do see that when the other chips were getting it wrong, it was often the same wrong V: value, but I didn't think much of it at the time.

 

Your new test from the images above, and this particular error there is really interesting:

 

 

Err at: >28D4 E: >046A V: >066A 2: >046A

 

It appears in the new, completely different brand chip, as it did in the old chips: (same address, same bad 1st read, same good 2nd read)

 

 

Again, it's not worth pulling this new chip, something else is going wrong.

[JasonACT]

On 1/11/2024 at 4:29 PM, JasonACT said:

@RickyDean The guy on GitHub who wrote the PSRAM PIO code (that I stole - https://github.com/polpo/rp2040-psram ) did remove the fast slew rate setting some time after I downloaded his code.  I read today that using the fast rate may be noisy in some way, but I had kept it because turning it off meant I couldn't overclock the PSRAM as much.  Now that I'm underclocking it for you, I guess it's worth trying a version with it switch off:

@RickyDean Don't use the version with the fast slew rate disabled.  Use the one before that, which I had said flashes the LED if no SD card was detected.

 

I've just spent a couple of hours trying to work out why my socketed build wouldn't work anymore, since I figured we should be testing the same chips now (the ESP chip) and then I remembered I had disabled the fast slew rate...  I was getting errors just like you were with this chip.