Issue using Macronix MX25L12845GZNI-08G (which combines RESET and SIO3 pin)

[markgs]

We have used Macronix QSPI parts on several designs connected to the NRF52840 (and other similar Nordic processors with the QSPI peripheral) and had no problems.

We usually used a Macronix package that had a dedicated reset pin, but Macronix is deprecating those packages and going to an approach where they MUX the SIO3 line and the RESET, with the RESET only being active in simple SPI mode.

Our most recent design uses one of these parts, specifically the MX25L12845GZNI-08G.

We have built a beta run of 100 boards.  About 60 of the boards work flawlessly and we have never had an issue talking to the QSPI flash part through the QSPI peripheral.

On the other 40 boards, they vary from being able to get the flash initialized on perhaps 20 or 25% of the power-up to well under 1% of power ups.

On these particularly stubborn samples, I find that if I run the code in the debugger, with a breakpoint where the error is thrown if the QSPI part fails to initialize, and keep hitting the "restart" button in the debugger, over and over again, eventually the breakpoint will not be hit and the QSPI flash is initialized.

Once the flash is initialized, we do the following sequence as a regular feature of our code to save power:

Command flash part into deep sleep -> switch off Nordic QSPI peripheral -> Switch on Nordic QSPI peripheral -> Command part out of deep sleep.

That cycle will work flawlessly over and over again, as long as we get the Macronix part talking to the QSPI peripheral on power up.

There also seems to be a component to all this that smacks of a residual voltage effect:  Specifically, on these "stubborn" boards, if you depower them for one or two minutes and restore power, they come right back up.  However, if you depower them for 30 minutes or more, they do not (I must go through the "thrash" described above to get the QSPI flash working again.)

The FAE from Macronix is focused on the MUXED reset / SIO3 pin, thinking something the Nordic is doing makes the Macronix chip think it is being reset. 

So, finally my question is:  Has anyone seen a similar issue with QSPI parts that have this MUXED reset?  If so, how did you solve it?

Thanks,

Mark Sutton 

Principal Engineer -Globalstar

[markgs]

We have some awesome new information:
 
We took some “bad” samples and soaked them at 45 degrees C for 30 minutes, depowered, and then powered them up in the “warm” temperature chamber.  It made them work correctly.
 
We took some “good” samples and soaked them at 0 degrees C for 30 minutes, depowered, and then powered them up in the “cool” temperature chamber.  It caused them to not work!
 
We appear to have a situation where they work “warm” and don’t work “cool”, and the specific threshold temperature between working and not working varies from unit to unit, but appears to “always” be fairly close to a normal room temperature, either just above or just below.
 
Those units that are particularly intermittent have a “threshold” temperature very close to a typical room temperature.
 

[Simonr]

Hi

This sounds very strange, but then it sounds like one of the components on your designs don't handle low temperatures very well. This is not the nRF52840 or the MX25, but have you made sure the rest of the components are certified for lower than 0 degrees C? Are you able to reproduce this issue on a Development kit or only on your custom boards? Please also confirm what Hugh suggests, and that you have a pull-up on your CS# line.

Best regards,

Simon