Initializing external flash SPI speed to SPI_FLASH_MAX_BAUDRATE, instead of using driver default speed (32MHz), before probing JEDEC identifier.

[PontusO]

On our challenger_840 boards using the 32MHz driver default SPI clock to probe the JEDEC ID fails, so I added an initialization to SPI_FLASH_MAX_BAUDRATE before the framework tries to probe for the JEDEC ID.

Also increased max speed for our board to 20MHz.

[dhalbert]

Two questions:

1. Do your boards not use QSPI for the external flash?
2. There is a serious problem with SPIM in battery-only operation: nRF52840 - SPIM3 not working if VBUS not powered when reset #5233. We encountered this, and disrecommend using SPIM3 under those circumstances. So I'm wondering whether your board might have the same issue. It's also possible to disable SPIM3 completely at compile time.

[PontusO]

1. No, our board uses standard SPI.
2. I don't think this is the same issue. I noticed when probing sclk that the frequency was 32MHZ which caused problem when reading the JEDEC ID. Reducing the clock to Max clock makes it work again. The problem is that the SPI interface is initialized to the max frequency when creating the bus and only reduced after having detected what memory device is attached. Could that be the problem you are also seeing ? This would occur after power on and reset.

[dhalbert]

2. I don't think this is the same issue. I noticed when probing sclk that the frequency was 32MHZ which caused problem when reading the JEDEC ID. Reducing the clock to Max clock makes it work again. The problem is that the SPI interface is initialized to the max frequency when creating the bus and only reduced after having detected what memory device is attached. Could that be the problem you are also seeing ? This would occur after power on and reset.

EDIT: Sorry, I didn't mean to imply it was the same issue. It is a separate issue that might affect you.

We are not seeing a flash problem with SPIM3. It is that SPIM3 is not working at all if VBUS is not powered. See
https://devzone.nordicsemi.com/f/nordic-q-a/74754/nrf52840-application-won-t-completely-run-without-power-applied-to-vbus,
https://devzone.nordicsemi.com/f/nordic-q-a/83266/spim3-not-work-standalone/350598

Is it possible on your board to have VBUS not powered? If so, does SPIM3 work for you in that circumstance?

[PontusO]

Is it possible on your board to have VBUS not powered? If so, does SPIM3 work for you in that circumstance?

It does work yes, I just retested to be sure. Both directly after power on and after reset running only on battery and VBUS totally disconnected. I have attached a schematic for your reference (The body diode on the mosfet is drawn backwards).

And this is with the fix I implemented to reduce the SPI speed during initial JEDEC probing. Otherwise it just hangs, waiting for a non FF byte to be read. Interesting note here is that it seems to be on the limit, it works with some flash memories and some fail but by reducing it to 20MHz in our case it works.

Challenger-840_V0.3.pdf

[dhalbert]

That is interesting -- thanks! Just to confirm: R5, the zero ohm jumper between VDD and VDDH is populated on your board? Your schematic is very similar to the Feather nRF52840.

I don't know why you don't see this SPIM3 problem. We saw it when trying to use SPIM3 much later, after CircuitPython starts, and as you can see from the Nordic DevZone complaints, other users are also having trouble when SPIM3 is used by user code.

I or @tannewt will review this more. I just want to make sure setting the clock speed specifically as is done here is not going to affect other boards.

[PontusO]

Just thinking out load here. Could it be that we are only using SPI and not QSPI that allows the block to work on our boards....

[dhalbert]

Just thinking out load here. Could it be that we are only using SPI and not QSPI that allows the block to work on our boards....

It is possible, we're not at all sure why we don't see SPI SCK on SPIM3 when VBUS is not powered. But I'm not sure the other folks in DevZone were using QSPI at the time.

Did you choose SPI instead of QSPI so you would have more pins for other uses?

[PontusO]

We selected SPI as we have tons of those chips =)

[dhalbert]

We selected SPI as we have tons of those chips =)

It looks to me like the flash chips listed in mpconfigboard.mk are all QSPI-capable (I looked at the datasheets). We were curious: which chip are you using that's SPI only? Thanks.

[dhalbert]

I tested on a variety of boards (SAMD, STM, RP2040, Esprsesif) to make sure this wasn't causing any issue with current boards.

We are still interested in which chip you're using that's SPI only.