IS25LP080 on v0.3 is broken

[activexray]

Hey!

I've been working on some firmware for a custom board that utilizes the IS25LP080 chip. Using 0.2 of this crate works fine, but simply switching to 0.3 prevents my design from booting. All I get back from probe-rs is

Frame 0: <unknown function @ 0x0160f206> @ 0x0160f206
Frame 1: <unknown function @ 0xfffffff8> @ 0xfffffff8
Error: CPU halted unexpectedly.

Frame 1's address doesn't even look to be valid. Not sure what to make of this, maybe something upstream broke the bootloader?

[jannic]

Interesting. Can you tell us what board you are running, and at what clock speed?

If you say 0.2 works, which exact 0.2 version did you try? v0.2.1?

Besides some build infrastructure, the only real difference between v0.2.1 and v0.3.0 is that the clock divisor was changed from 4 to 2, essentially doubling the flash access speed. Perhaps that's too fast for your chip?

[activexray]

The board is custom, the specific model of the flash chip is IS25LP080D-JULE. The specific version of boot2 is 0.2.1.

Datasheet lists

50MHz Normal and 133Mhz Fast Read
- 532 MHz equivalent QPI
- DTR (Dual Transfer Rate) up to 66MHz

That seems pretty quick to me.

[jannic]

Yes, as I understand it that should (in theory) be fine unless you overclock the rp2040 significantly.
With the rp2040 running at 125MHz, with PICO_FLASH_SPI_CLKDIV = 2 as v0.3.0 uses, the flash frequency will be 62.5MHz, far below the limit of 133MHz. (boot2_is25lp080 uses the 0xEB "fast read quad" operation.)

Still, this clock divider is the only difference between the two versions. Comparing the binary files shows:

--- /tmp/0.2.1	2023-10-27 20:46:29.427332879 +0000
+++ /tmp/0.3.0	2023-10-27 20:46:21.075239730 +0000
@@ -9,7 +9,7 @@
    2:	4b2b      	ldr	r3, [pc, #172]	; (0xb0)
    4:	2100      	movs	r1, #0
    6:	6099      	str	r1, [r3, #8]
-   8:	2104      	movs	r1, #4
+   8:	2102      	movs	r1, #2
    a:	6159      	str	r1, [r3, #20]
    c:	4929      	ldr	r1, [pc, #164]	; (0xb4)
    e:	6019      	str	r1, [r3, #0]
@@ -106,5 +106,4 @@
   d2:	1000      	asrs	r0, r0, #32
   d4:	ed08 e000 			; <UNDEFINED> instruction: 0xed08e000
 	...
-  fc:	3328      	adds	r3, #40	; 0x28
-  fe:	b243      	sxtb	r3, r0
+  fc:	fdee e22e 	stc2l	2, cr14, [lr, #184]!	; 0xb8

That's a diff of the disassembly generated using arm-none-eabi-objdump -b binary -m armv6-m -M force-thumb -D boot2_is25lp080.padded.bin. The last few lines are the checksum which is different for obvious reasons. In the actual assembly code, only the argument of the movs instruction at address 8 differs.

However, at these frequencies, signal quality also matters. Perhaps something is distorting the signal too much when running at 62MHz, while at 31MHz the signal quality is still sufficient?

While it would be great to find the root cause, the immediate fix probably is to stay with v0.2.1. The only advantage v0.3.0 would offer you is increased flash read speed.

(EDIT: Just saw "RF systems" in your profile, so you probably know much more about signal quality at those frequencies than I do 😄 )

[activexray]

Very strange indeed! I have no problems with v0.2.1, just wanted to bring this up.

This chip has also been pretty flaky, I had a small USON version of it on my old board that really had a hard time - lots of programming errors. I've since switched to the larger SOIC as I thought this was a solder reflow issue (and the programming problems did go away), but this still may just be a supplier problem (I ordered these from China).

As far as signal integrity is concerned, I don't think that's it - I more or less copied Pico's layout, properly decoupled power lines and all.

If there's anything I can read off the device that's useful, please let me know and I'd be more than happy to, however, I can't even get a breakpoint to set.

[jannic]

Yes, correctly diagnosing this seems difficult. One approach could be loading a test firmware directly into RAM, and then trying to access flash from that firmware. But I wonder if that's worth the effort. It might even happen that the flash is perfectly readable that way: In raspberrypi/pico-sdk#1304 (comment) there is a case were just waiting a little bit longer for the oscillator to stabilize makes the problem go away.

The important thing we know now is that there are situations where the faster clock doesn't work, even without overclocking. We shouldn't ignore that.

As long as it's only happening in rare cases, I don't think we should revert to the slower frequency. (It's not like we are overclocking the flash chip, or clock it faster than the C SDK would.) But we should improve our documentation, and ideally provide a better way to reduce the access speed if necessary. "Downgrade to v0.2.1" is a reasonable short-term solution, but I feel like we should aim for something better.