Pi Pico[W] Peripheral Expansion Box Side Port Device

[JasonACT]

11 hours ago, chue said:

At this point, I'm thinking I should just build another Pico PEB, but with a genuine PI.

 

Edit: Just to be more descriptive - I am seeing at pins D0-D7 on the edge connector, the voltage oscillating between 0 and 3.3.

It's an odd one, that's for sure.  We could look a little further into the DSR ROM contents, though I agree, building a new one will most probably work.  Can you try this in Mini Memory Easy Bug?

 

There's a few different values in the SD card file here that may help to understand what's going on?

 

There's also M435D =FF which would be interesting to see what value the TI is seeing.

[+chue]

10 hours ago, JasonACT said:

Can you try this in Mini Memory Easy Bug?

This is with the no-wifi firmare:

 

[Stuart]

4 hours ago, chue said:

This is with the no-wifi firmare:

 

If these values are supposed to be the same as the earlier screenshot, then it looks like the '2' bit of the second nibble is always low.

[+chue]

1 hour ago, Stuart said:

If these values are supposed to be the same as the earlier screenshot, then it looks like the '2' bit of the second nibble is always low.

You are correct Stuart, the trick is figuring out what the problem is.  At this point I am inclined to just build a new board - I am waiting for some Raspberry PIs to show up.

[JasonACT]

7 hours ago, chue said:

the trick is figuring out what the problem is.

I was hoping for something more than it just always being low, but there it is, just always being low.  We know the '245 data chip is in the right state.  We know there's no shorts.  We're sure there's no broken traces, might be worth checking the exact resistance you get though.  We are able to properly read both high-byte address and low-byte address, so the Pico's 8 DIO data pins are working as inputs, and the other 2 x '245s are working.  We get a successful slow signal out all 8 Pico data pins when configured as outputs.

 

I don't know, assuming the '245 chips didn't go back in the same socket after testing, they all appear good, and I guess you've tried another just in case with the same result.  It would then have to be something to do with the Pico's GP1 digital pin when being used at speed, maybe the RP2040 chip hasn't been successfully attached to the clone board and you're just getting a noisy signal out of it from a cold joint.

 

Wait and see with the new boards, I guess.

[JasonACT]

9 hours ago, chue said:

At this point I am inclined to just build a new board - I am waiting for some Raspberry PIs to show up.

If you have a no-clean flux pen, you could touch this area with it and heat it up with the hot air gun...

 

[wiloson]

Does anyone in Canada want to build this project with me?   I can order the PCB and assemble & test but it's cheaper to build if we order a batch of 5 or more.

I'm located in Toronto.

 

[+chue]

11 hours ago, JasonACT said:

might be worth checking the exact resistance you get though

My meter shows about 1/10th ohm among the following three points along the blue line in the image below: top card edge, U3, and bottom card edge. 

 

In this second image, the meter reads about 2/10ths ohm from U3 to the PI.

 

Measuring from any of the points along the blue lines above to ground shows an infinite resistance.

 

11 hours ago, JasonACT said:

I don't know, assuming the '245 chips didn't go back in the same socket after testing, they all appear good

Correct, I intentionally swapped U3 out with one of the others, although I did not try a new chip.

 

11 hours ago, JasonACT said:

It would then have to be something to do with the Pico's GP1 digital pin when being used at speed, maybe the RP2040 chip hasn't been successfully attached to the clone board and you're just getting a noisy signal out of it from a cold joint.

I concur that it has to do with the PI's GP1 pin running at full speed.  I can't think of another explanation.  Maybe it is an out of spec clone, or as you say a cold joint.

 

9 hours ago, JasonACT said:

If you have a no-clean flux pen, you could touch this area with it and heat it up with the hot air gun...

I will do this at some point, but for now I will put this build aside and try a new board with some genuine PIs.

 

Thank you for going "above and beyond" in troubleshooting this thing.

 

 

[Stuart]

Worth connecting a 1K pullup resistor to the line at the PI end and checking if it reads high in EasyBug? Might indicate whether the PI really is pulling it low (as opposed to being a bad joint on the PI) and whether the signal is making it through the '245s?

[+chue]

11 minutes ago, Stuart said:

Worth connecting a 1K pullup resistor to the line at the PI end and checking if it reads high in EasyBug?

I will definitely try that at some point.  Thanks!

[JasonACT]

2 hours ago, chue said:

I will definitely try that at some point.  Thanks!

When you do, make sure the DSR.ROM file on the SD card has been edited to alter the initial >AA byte.  You don't want the TI attempting to run the DSR power-up routine before you get a chance to review what the TI can see in Easy Bug.

[JasonACT]

@chue I've just now noticed this request for help at the Pico Arduino project issues page: https://github.com/earlephilhower/arduino-pico/issues/1981

 

From what I can tell, the WiFi module on these boards is connected to Pico digital pins 0 and 1, and you use the serial port on those pins to connect to and use the WiFi.  This means, the WiFi chip is probably messing with digital pin 1 (ESP WiFi chip transmit pin into Pico digital pin 1).  I'm sorry, but that's no good 

[+chue]

Good to know. So that means I just have to swap out the clone for a genuine pi. Will do it at some point.

 

I did build a second board using a genuine PI. I am still testing it out at the moment. 
 

CALL TIPI seems to work. Reading the ROM at 4000 using minimem works. Standard 32K expansion works.

 

what doesn’t work at the moment is the SAMS ram. I haven’t done the resistor bodge yet. I will do that next and if that fails will swap out the PSRAM.

[RickyDean]

Well I changed out my riser solution on my third one, I had used machine socket sips and when I bent the pins at a 90 degree angle they became brittle and a couple broke and didn't solder well. So I used a variation of the riser system on the first one, on the third and that fixed the issue. Then I still had to do the resistor mod to get the memory to detect and test right. It is now operational.

[JasonACT]

Attached is a new firmware for testing, along with the Foundation 128/512KB XBII ROM that can be optionally copied to your SD card.  CALL CARTMMO in TI BASIC (turns on Mini Memory RAM mode, but in this special case, the whole 8KB is now RAM) will switch the SAMS 1MB to a Foundation (/Myarc) 512KB at CRU >1E00...  Without the ROM, you can load whatever cartridge image [with a single ROM] you like, like the memory tester.  With the ROM, it will wipe out the loaded cartridge image and install the M-XBII booter.  If you have Mini Memory loaded, Easy Bug seems to also still work, since that part is in GROM and I don't wipe it, but best not to use a GROM cartridge image for this.  Without a cartridge image loaded, it won't do much.

 

The M-XBII booter requires a DSK image or directory set up with the appropriate files, before selecting the menu option.  NOTE: the images available have a LOAD file on them, which takes a minute to load and run, just wait until the demo starts.  I initially thought there was a problem, until I left it to run.

 

This firmware runs at 258MHz Pico speed.  If PSRAM chips have an issue at this speed, I can make a 256MHz version, I suppose.

PPEB2.ino.uf2.zip

Edited February 12 by JasonACT
EDIT: with a single ROM - since paged is disabled in RAM mode.

[JasonACT]

Attached is a new firmware (where have I read that before?).  This one has a new DSR.ROM too, you can't use the old DSR.ROM with this firmware, you can't use the new DSR.ROM with any old firmware.  Here are the updates:

 

TI BASIC:

 

CALL MYARCON - switch SAMS memory to Foundation/Myarc mode

CALL MYARCOF - switch back to SAMS mode

 

autoload.cfg:

 

MMMD=0   ; Minimem RAM mode: 0=8KB RAM, 1=4KB RAM, default is 8KB RAM (seemed to be the most sensible default)

MYARC=0  ; 0=Off, 1=On, default is off

 

Note: CALL CARTMMO no longer makes the automatic switch to Myarc Mode.  These changes allows the new SAMS version of Myarc XBII to be tested.

PPEB2.ino.uf2.zip

[+chue]

Ok, so this project has been kicking my butt.  I built a second board using a genuine PI and kept getting errors during the SAMS memory test.  Keep in mind I am using the FinalGrom as well as the 8 or 12 ma PICO PEB firmware.

 

I then pulled out my other TI (a beige one) and tried to run the memory test.  This is what I got:

 

 

I then went back to the first PICO PEB, removed the clone PI and installed another genuine PI.  I got the same errors as above.

 

Next I did some reflowing of both boards.  I used generous amounts of flux as well as a heating plate.  I did this in my garage where the temps are around freezing.

 

I reran both boards on both TIs that I have and got memory errors, as above.  The first TI always errored at F4D4, the second TI got errors at various other points.

 

At this point I was considering building a third board... then I thought, just for giggles I will run some older firmware.  I loaded the "failsafe" version, which I believe is the 3rd in this thread.  I happened to still have the beige (2nd) TI still hooked up.  Here's what I got:

 

 

It worked! Then I tried the silver (first) TI and got the same memory errors at F4D4.  It looks like my TI had some kind of problem all along!

 

But I wasn't done testing - I then tried the first foundation memory firmware.  I didn't want to do the "latest" because I didn't want to add another variable in the mix with the new DSR.  It worked in both modes.  Here's what I got with the Foundation memory test on the beige TI:

The SAMS test worked as well.
 

At this point I tried the cartridge functionality on the PICO PEB (no FinalGROM).  It didn't seem stable for me:

 

 

I also tested the 2nd Foundation firmware (new DSR), using the FinalGROM - it didn't work for me.

 

At this point I am happy that the SAMS memory is working using the FinalGROM.  Not super concerned about the onboard cart functionality, yet.

 

I also need to test the disk emulation.  Would love to get that working so I can finally play "Realms of Antiquity" on a real TI:

 

 

I am curious why some firmware works and others do not.  Perhaps Jason can shed some light on it, but no rush.

 

I am super excited to get this far! Thanks, @JasonACT!

[JasonACT]

44 minutes ago, chue said:

I then pulled out my other TI (a beige one) and tried to run the memory test.  This is what I got:

 

I know you got SAMS to pass on this beige console, but E000 -> EFEF (should be FFFF) and all those 'X's (which in my C code [that I added to Matt's] is the format string "Err at: >XXXX E: >XXXX V: >XXXX 2: >XXXX") are probably not due to my device, if you have the FinalGROM plugged in.

 

The memory tester is running from the FinalGROM and it's somehow having issues overwriting every 2nd X from the string after I first copy it to VDP RAM.. with the calculated ASCII version of what's in the CPU registers / GCC local variables.  In fact, "Err at: >0X0X" should be at least >EX or >FX since that's the bank which has started to fail here.  PSRAM passing or failing at these points should have had no effect on the output to the screen.

 

Have you measured the +5v voltage line coming out of the side port?  Being low won't affect the Pi Pico, but it might affect the TI motherboard and/or FinalGROM?

 

1 hour ago, chue said:

I also tested the 2nd Foundation firmware (new DSR), using the FinalGROM - it didn't work for me.

1 hour ago, chue said:

I am curious why some firmware works and others do not.  Perhaps Jason can shed some light on it, but no rush.

There's almost no difference between these 2 firmwares, I only moved around the Myarc switch code, and added 1 extra test in the memory write check to widen the space from 4K to 8K.  If you flash back the "working" one, is it consistently working?  Does unplugging and plugging back in both my device and the FinalGROM do anything different?  Just throwing out some ideas here, because this is a hard one!

[+chue]

33 minutes ago, JasonACT said:

Have you measured the +5v voltage line coming out of the side port?

+-5 volt line measurements

Silver TI: +5, -9

Beige TI: +5.1, -5

 

That probably explains the weird behavior on the Silver TI.  I'm surprised it is not dead, with the -9V coming out of the -5V line.

 

35 minutes ago, JasonACT said:

If you flash back the "working" one, is it consistently working?

Yes the SAMS on the beige TI consistently works.

 

36 minutes ago, JasonACT said:

Does unplugging and plugging back in both my device and the FinalGROM do anything different?

I'm pretty sure it is consistently working when unplugging and plugging them back in.  I have two TIs and was testing with only one FG and PICO PEB.

 

[JasonACT]

5 minutes ago, chue said:

+-5 volt line measurements

Silver TI: +5, -9

Beige TI: +5.1, -5

 

That probably explains the weird behavior on the Silver TI.  I'm surprised it is not dead, with the -9V coming out of the -5V line.

I was going to say, I like your silver one better, because it's more consistent - but after seeing this, maybe not.  Might be worth checking the 12v line too, after seeing that result.

 

7 minutes ago, chue said:

Yes the SAMS on the beige TI consistently works.

But only with one of the Foundation firmwares   Well, I guess that's something.

 

9 minutes ago, chue said:

I'm pretty sure it is consistently working when unplugging and plugging them back in.  I have two TIs and was testing with only one FG and PICO PEB.

Maybe, now it's partially working, you can continue testing and keep a record of anything strange that happens...  The more information we get, the more likely we'll figure this out.  I'll keep thinking about it, but nothing comes to mind just at the moment.

[JasonACT]

@chue Can you try this re-compile of the "newest" Foundation firmware?  It's set at 260MHz (130MHz PSRAM).  I reviewed the code I had added for the Myarc memory, and there was quite a lot actually (in both versions) so the Pico might need to run a bit faster to be fully stable now?

 

@RickyDean Do you want to test if your PSRAMs run at this speed too?

 

(BTW: The DSR.ROM isn't in this archive.  Edit: added as an additional download.)

PPEB2.ino.uf2.zip

DSR.zip

Edited February 18 by JasonACT

[RickyDean]

1 hour ago, JasonACT said:

@chue Can you try this re-compile of the "newest" Foundation firmware?  It's set at 260MHz (130MHz PSRAM).  I reviewed the code I had added for the Myarc memory, and there was quite a lot actually (in both versions) so the Pico might need to run a bit faster to be fully stable now?

 

@RickyDean Do you want to test if your PSRAMs run at this speed too?

 

(BTW: The DSR.ROM isn't in this archive.  Edit: added as an additional download.)

PPEB2.ino.uf2.zip 379.71 kB · 1 download

DSR.zip 2.42 kB · 1 download

I just tried this on my first two pico's and the 512k myarc test worked well. the 3rd is having issues, unknown why at this time. I am now testing the first two with the SAMS detection, will let you know the results tomorrow. 

[JasonACT]

30 minutes ago, RickyDean said:

I just tried this on my first two pico's and the 512k myarc test worked well. the 3rd is having issues, unknown why at this time. I am now testing the first two with the SAMS detection, will let you know the results tomorrow. 

I've loaded the latest firmware onto all my 4 boards now, and all my tests are passing.  The firmware before this one also passed the memory test, but I did get a random crash in a 32KB program loaded into SAMS.  That's when I figured it might be speed related, and I've been giving that some exercise now without any issue.

 

FYI - the Myarc mode is less taxing on the Pico than the SAMS, SAMS requires a look-up into an array whereas the Myarc is just adding an offset.

 

I also decided to "upgrade" my one ESP chip that didn't need the resistor mod, I ran out of 470 ohm resistors, so I used a 330 ohm...  It went from 133MHz stable to 140MHz stable after the mod.  That's pretty much where all my chips max out.  I'm pretty sure smaller values still would work, but I guess it depends on the PSRAM.

[RickyDean]

Well the last program and DSR works with the first two of my Pico units, both with Myarc enabled and with Sams enabled. The third is having issues, which I believe are still riser related. I have some 90 degree  single row headers coming from Amazon soon, so I'll try 1 more time before mounting it directly to the board.

[JasonACT]

3 hours ago, RickyDean said:

Well the last program and DSR works with the first two of my Pico units, both with Myarc enabled and with Sams enabled. The third is having issues, which I believe are still riser related. I have some 90 degree  single row headers coming from Amazon soon, so I'll try 1 more time before mounting it directly to the board.

It would be good to get a report of what the original memory "bench-only" tester reports (number of flashes) for all of these boards.  If it's up near 133MHz or beyond, then I can try a new firmware build with the timing altered.  At the current speed, I've got no real room to move, adding any additional code makes it fail for me when running a 32KB program in SAMS with SAMS paging mode enabled.

 

I've got to get to work now, but tonight I'll have a go at making something to test (will be interesting if your other TI starts doing something different with a new build with different timing, @RickyDean).  I was thinking, it can't be coincidence that @chue also gets that odd screen corruption at E000->FFFF.

Edited February 18 by JasonACT