Re-work hints for QSPI flash on PCA10056

[Julie H]

The design I'm working on will tentatively use "Original SPI" (like "Original Coke" ...), so I started cutting up the QSPI bridges to disconnect DIO2 and DIO3 (which are also other things ...) prior to pulling them up to Vcc.

Has anyone else done this? I'm comfy working under a microscope, but I'm an old geezer fart and I'm always looking for huge pads and buttons and knobs and dials I can use.

[Julie H]

I totally understand - the nRF52840 will be a great part in full-sized applications on account of having 48 GPIO pins. I'm not sure a 48+ pin "dongle" would be a "dongle" anymore.

I may have found a silk screen issue. I have to head into the office to try and resolve a completely different issue. As soon as I'm convinced the silk screen problem is real I'll post another question.

[ovrebekk]

I noticed the silk screen issue, but someone else is handling that one. If it is an error on the PCB I am sure we can fix it in time for the production part.

[Julie H]

Thanks for confirming that. The PCB itself is fine so far and I'm looking forward to using the PDK.

[ovrebekk]

Good to hear :)
I noticed the PCB hack from the other case, and I am still curious what you are trying to do?
Do you want to use a regular SPI interface to connect to the same memory chip?

[Julie H]

Yes - for the time being, I intend to use "Classic SPI" to talk to the SPI flash. I don't need the data rate bump that comes with QSPI, but I do need GPIO pins. That's why I asked if the USB "dongle" would break out all the GPIO pins.

The actual re-wiring of the flash part is only a few minutes work and should have been easier than changing code to either use QSPI or "set" the GPIOs for !WP and !HOLD. The bigger time-suck was figuring out that !CS and DIO2 were swapped with the silkscreen and that I had about half a dozen J-Link install directories and Eclipse was still picking one that didn't support the NRF52840_XXAA device.