Scratchpad SRAM bank Y seems to be defective

[matsobdev]

Tested now on Pico 2, but on Pico scratchpad y was causing troubles as well. Making y scratchpad full with RGB565 data and results are as follows.

Original data (y.bin):

Dump (y_dump.bin)

Files here: scratch.zip. On RP2040 scratchpad was tricky as well. For example putting some arrays of a JPEGDEC library and decoded files were a little bit corrupted sometimes. Removing them from scratchpads solved an issue. Just put some data there and read them back.

PS. It literally looks like (pictures are 64 x 32 x RGB565) the last 384 bytes are unreliable.

[will-v-pi]

By default, the end of scratch Y is used for the stack - so if you're trying to fill the whole of scratch Y with data, then the stack will be overwriting the end of that data, which would explain the corruption you're seeing. You'll also be corrupting your stack by writing data over it, which will cause other issues.

[matsobdev]

So it won't be visible by:

target_link_options(<program> PRIVATE
	-Wl,--print-memory-usage
	)

? I mean, it is not. But, should it be?

[will-v-pi]

Yes, currently the stack (and heap) usage don't show up under --print-memory-usage when using GCC, as they're not marked as allocatable ("a") - changing that had the risk of breaking linker scripts (see the comments at the bottom of crt0.S)

[kilograham]

not a bug