Modify boot2_w25q080.S (and others?) to allow for changing driver strength configuration registers #1433

New issue

Open

opened 2023-06-19 09:50:08 -05:00 by leelindquist · 5 comments

leelindquist commented

2023-06-19 09:50:08 -05:00

(Migrated from github.com)

According to the part specs this should work, but I have a theory that the edge times are too slow, or the flash chip isn't sourcing enough current to drive the RP consistently at the higher speed. I found a reference to an "Output Driver Strength" config register in the winbond spec sheet (which defaults to the lowest value) and I would like to try modifying that, but I am unfamiliar with this ARM assembly code.

The necessary change to test my theory would be to set the DRV1, DRV0 bits in Status Register 3 during configuration of the winbond chip. I just don't know how to do that. I'm assuming adding more flexibility and configuration options to this file would be beneficial for other users who wish to test out additional capabilities of the flash memory as well.

I am troubleshooting an issue on a custom PCB design with the RP2040 and the Winbond W25Q64JVZPIQ part where I am seeing what appear to be occasional bit errors when booting with PICO_FLASH_SPI_CLKDIV set to 2. According to the part specs this should work, but I have a theory that the edge times are too slow, or the flash chip isn't sourcing enough current to drive the RP consistently at the higher speed. I found a reference to an "Output Driver Strength" config register in the winbond spec sheet (which defaults to the lowest value) and I would like to try modifying that, but I am unfamiliar with this ARM assembly code. The necessary change to test my theory would be to set the DRV1, DRV0 bits in Status Register 3 during configuration of the winbond chip. I just don't know how to do that. I'm assuming adding more flexibility and configuration options to this file would be beneficial for other users who wish to test out additional capabilities of the flash memory as well.

kilograham commented

2023-06-19 10:45:47 -05:00

(Migrated from github.com)

You can override it; just set PICO_FLASH_SPI_CLKDIV=4 in your target_compile_definitions in the CMakeLists.txt or you a custom PICO_BOARD (note the divider of 2 is likely coming from your board config file, as the default in w25q080.S is 4.

You can override it; just set `PICO_FLASH_SPI_CLKDIV=4` in your `target_compile_definitions` in the `CMakeLists.txt` or you a custom `PICO_BOARD` (note the divider of 2 is likely coming from your board config file, as the default in `w25q080.S` **is** 4.

leelindquist commented

2023-06-19 11:01:35 -05:00

(Migrated from github.com)

I am overriding the clock divider already.

I am asking for a modification to the flash config that will set the driver strength to an explicit value. The 2nd stage boot configures the flash chip for QSPI mode, but does not set the driver strength (Status Register 3) and I am asking for a modification that will allow setting the driver strength explicitly.

There is some related discussion in #401 , and I think it would be a useful defined option in this file.

I am overriding the clock divider already. I am asking for a modification to the flash config that will set the driver strength to an explicit value. The 2nd stage boot configures the flash chip for QSPI mode, but does not set the driver strength (Status Register 3) and I am asking for a modification that will allow setting the driver strength explicitly. There is some related discussion in #401 , and I think it would be a useful defined option in this file.

kilograham commented

2023-06-19 11:34:03 -05:00

(Migrated from github.com)

ah; i misread

👍 1

lurch commented

2023-06-20 11:19:18 -05:00

(Migrated from github.com)

There is some related discussion in https://github.com/raspberrypi/pico-sdk/pull/401 , and I think it would be a useful defined option in this file.

#1304 might also be related ?

> There is some related discussion in https://github.com/raspberrypi/pico-sdk/pull/401 , and I think it would be a useful defined option in this file. #1304 _might_ also be related ?

leelindquist commented

2023-06-20 12:55:25 -05:00

(Migrated from github.com)

There is some related discussion in #401 , and I think it would be a useful defined option in this file.

#1304 might also be related ?

I've read through that as well, and I have seen the same failure mode where sometimes the flash SPI clock is coming in way too fast, presumably because the crystal isn't stable yet. That's a more rare occurrence compared with the issue I am describing here, and I haven't extensively tested the PICO_XOSC_STARTUP_DELAY_MULTIPLIER 64 suggestion yet. However, the failure I am troubleshooting presently seems to be a true bit error. I setup my logic analyzer to record all 4 data lines, and compared the results from a normal boot and a failed / hung boot. The failed one is identical for the first few hundred bytes, and then it starts to diverge. I don't have an analog trace of this behavior yet, but my suspicion / theory is that the driver strength of the flash chip could be playing a role in the rise time, and the data line is getting read on the wrong SPI clock cycle.

> > There is some related discussion in #401 , and I think it would be a useful defined option in this file. > > #1304 _might_ also be related ? I've read through that as well, and I have seen the same failure mode where sometimes the flash SPI clock is coming in way too fast, presumably because the crystal isn't stable yet. That's a more rare occurrence compared with the issue I am describing here, and I haven't extensively tested the `PICO_XOSC_STARTUP_DELAY_MULTIPLIER 64` suggestion yet. However, the failure I am troubleshooting presently seems to be a true bit error. I setup my logic analyzer to record all 4 data lines, and compared the results from a normal boot and a failed / hung boot. The failed one is identical for the first few hundred bytes, and then it starts to diverge. I don't have an analog trace of this behavior yet, but my suspicion / theory is that the driver strength of the flash chip could be playing a role in the rise time, and the data line is getting read on the wrong SPI clock cycle.