Small ESP32 Modul ( all include in new ESP32-PICO )

[seonroz]

Hey rudi... the CLK and DATA pin can share an IO (GPIO10) ? How is that possible?

Cheers,

Seon
unexpectedmaker.com

damn... now the confuse begins from start again want edit it but to late - you read my last (deleted) post

you can share only the data pins between psram and flash.
for flash you need own cs ( and clk )
and for psram you need own cs ( and clk )
the limits for clk is cause 80MHz / 40 MHz

sry for confuse

best wishes
rudi

Ok, cool, I thought you found some secret magic

Can I confirm you are using a 10k pull-up on CS? I am as that was what was confirmed for me here...
viewtopic.php?f=12&t=6866&p=33097#p33097

But that also points to pins that cause the PICO to crash... so, um... confidence is low

I'm going to make a new RAM breakout and try that in case I damaged this one with all of my futzing around.

Thanks everyone for your help and PATIENCE with me... I am so far out of my comfort zone on this it's not funny... when @Matty suggested "lets throw some PSRAM on the TinyPICO" I thought to myself, how hard could that be??? hahahahha

Cheer

Seon
unexpectedmaker.com

[rudi ;-)]

yes - only cs is pulled up with 10k. clk is like it is.

btw caused clk need separate pin
Sharing CLK may not work b/c CLK to PSRAM is routed through GPIO matrix. Need to clock in one or two extra cycles, depending on the freq.

the psram theme is a long theme

keep us updated to your tiny tiny pico psram board and how you go on.


best wishes
rudi

[rudi ;-)]

btw "some secret magic"
yes this are given in this "psram" theme in many ways
you have only to find it out and believe in your own thinking and own making.
best wishes
rudi

last btw:
one magic is in SD Card + PSRAM on a PICO-D4
but this is an other theme

[seonroz]

Ok, more progress...

I have a new SPIRAM IC on a new breakout board that's now breadboard friendly, and I soldered pins onto the 6 extra header holes on the PICO-KIT and everything is now breadboarded for easier "manipulation"... breadboards are SO unreliable

10k pull-up on CS and 100nF CAP on VCC for good measure.



Now when I boot the PICO-KIT I consistently get...

I (916) spiram: SPI RAM mode: flash 40m sram 40m
I (919) spiram: PSRAM initialized, cache is in low/high (2-core) mode.
I (926) cpu_start: Pro cpu up.
I (930) cpu_start: Starting app cpu, entry point is 0x400816ac
I (0) cpu_start: App cpu up.
E (1830) spiram: SPI SRAM memory test fail. 49066/131072 writes failed, first @ 3F800040

E (1831) cpu_start: External RAM failed memory test!
abort() was called at PC 0x40081877 on core 0

Backtrace: 0x40095b94:0x3ffe3bf0 0x40095d5b:0x3ffe3c10 0x40081877:0x3ffe3c30 0x400790ef:0x3ffe3c50 0x400791a1:0x3ffe3c80 0x400791bf:0x3ffe3cc0 0x400794c1:0x3ffe3ce0 0x40080359:0x3ffe3df0 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20

CPU halted.

Which is great... as it's recognising the RAM every boot now.... just not passing the ram test.

Interestingly it's not failing every write, only 35%(ish) of them.... or is it failing on the first 35% and then stopping?

I'm using this Lyontek LY68L6400SLIT (for those that joined late).
https://lcsc.com/product-detail/RAM_Lyo ... 61881.html

Which is 3.3V and though bigger than what can be addressed atm, should work just fine.

Cheers

Seon
unexpectedmaker.com

[ESP_Angus]

Hi Seon,

I'm very glad to see you're making some solid progress!

I have a new SPIRAM IC on a new breakout board that's now breadboard friendly, and I soldered pins onto the 6 extra header holes on the PICO-KIT and everything is now breadboarded for easier "manipulation"... breadboards are SO unreliable

1*snip*
I (916) spiram: SPI RAM mode: flash 40m sram 40m
I (919) spiram: PSRAM initialized, cache is in low/high (2-core) mode.
I (926) cpu_start: Pro cpu up.
I (930) cpu_start: Starting app cpu, entry point is 0x400816ac
I (0) cpu_start: App cpu up.
E (1830) spiram: SPI SRAM memory test fail. 49066/131072 writes failed, first @ 3F800040

Are the number of failed writes different each time?

40MHz is quite fast for a breadboard and jumper wires, I expect these are probably introducing signal integrity problems leading to failures.

Having those extra wires/breadboard and the associated extra capacitances and stubs hanging off the SPI flash bus may also cause random crashes when running code from SPI flash (due to mis-reads).

Some suggestions to try, in order from "least painful" to "aargh":

• Drop the SPI flash clock speed to 20MHz (which should lower the PSRAM clock speed to match). EDIT: I forgot PSRAM only runs at 40MHz or 80MHz.
• Remove the breadboard entirely and connect the jumper wires directly pin to pin (breadboards can add a *ton* of capacitance and cross-talk between rows).
• Find shorter jumper wires
• Dead-bug the PSRAM chip on the TinyPICO and solder short-as-possible wire wrap wire (or similar) to the pins.
• New board spin

Good luck!

[seonroz]

Hey Angus,

Yeah I was already eliminating the breadboard out of the equation.



But I have the same RAM test failure, but the number of writes failed has increased now...

Yes it's slightly different every time, but around the same ballpark.

I (854) boot: Disabling RNG early entropy source...
D (855) psram: ESP32PICOD4 - Ignore - DISABLE OUPUT FOR IO16/17
D (861) psram: Flash ID: 13123606 <-> 13131798
I (866) spiram: SPI RAM mode: flash 40m sram 40m
I (870) spiram: PSRAM initialized, cache is in low/high (2-core) mode.
I (878) cpu_start: Pro cpu up.
I (881) cpu_start: Starting app cpu, entry point is 0x40081504
I (0) cpu_start: App cpu up.
E (1777) spiram: SPI SRAM memory test fail. 50747/131072 writes failed, first @ 3F800040

E (1777) cpu_start: External RAM failed memory test!
abort() was called at PC 0x400816b7 on core 0

Backtrace: 0x40094674:0x3ffe3bf0 0x40094817:0x3ffe3c10 0x400816b7:0x3ffe3c30 0x400790ef:0x3ffe3c50 0x400791a1:0x3ffe3c80 0x400791bf:0x3ffe3cc0 0x400794c1:0x3ffe3ce0 0x40080335:0x3ffe3df0 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20

CPU halted.

There is some extra logging in there in blue from me...

So the proto-board seems to have made it worse lucky I put female headers on and didn't hard wire the PICO-KIT and PSRAM

Interestingly, it's failing at the same point first @ 3F800040 every time. Incompatible ram?

hahahaha

Seon
unexpectedmaker.com

[seonroz]

So how critical is trace length and via count per data line going to be at 40mHz?

TinyPICO is a small board, so trace lengths are short in general, but due to how small and compact it is, and the fact that the RAM is on the bottom means some creative routing is necessary to get everything connected, so though every trace does only have 1 via, trace lengths are different by a factor of up to 2x.... though still short

Do I need to add bumps to get matching lengths on data lines and clock at this speed? Do they have to be matched perfectly? Or is close enough good enough?

At this point I'm thinking of just making a rev5 TinyPICO to try... as trace length will be < 10% the length of what I am using on the protoboard above.

For reference, here are my trace lengths

Trace mil mm
7 321 8.1
8 194 4.9
9 348 8.8
10 200 5.0
11 139 3.5
17 370 9.4

So longest is less than 10mm, but difference between shortest and longest is > 2.5x

Thanks

Seon
unexpectedmaker.

[ESP_Angus]

So how critical is trace length and via count per data line going to be at 40mHz?

Not super critical at 40MHz, just may need to be better than breadboard wiring.[*] The new protoboard layout looks a lot less precarious to me.

The PSRAM uses quad data lines, maybe one of the high data lines is still connected wrong or missing? Can you modify the IDF startup code to log the addresses and expected vs bad values for each error in PSRAM (this will produce a lot of log spam, but you might see a pattern...)

[*] Not to say that it's impossible to do a bad layout at 40MHz, but I think that you're right that TinyPICO is so small - plus 4 layer - so you're unlikely to have major problems.

[ESP_Angus]

Maybe squeeze a decoupling cap on or near the PSRAM power pins? Although I don't think this will be the problem here, either.

[seonroz]

Yeah the protoboard is working worse than the breadboard (in terms of failed write count), so something still isn't right with the connections/pin mappings.

The protoboard has a 100nF cap on the VCC pin of the SPIRAM (so did the breadboard version)... so I don't think It's power.

"Can you modify the IDF startup code to log the addresses and expected vs bad values for each error in PSRAM (this will produce a lot of log spam, but you might see a pattern...)"

Um, no idea how to do that, or where to even insert that... hahaha... This is the first time Ive even touched the IDF.... I use the Arduino IDE (shock horror) because that's what 95% of my YT viewers use.

I don't think the PICO has a power domain issue for IO does it? Like the ESP32 and 3.3v versus 1.8v on some IO?

But anytime I try to tweak or change an IO on the PSRAM I go back to that crash and halt (but no catch fire) - luckily.

Cheers,

Seon
unexpectedmaker.com