我一直试图使用SDK函数spi_flash_power_down()将一个外部闪存芯片(MX25R1635F)放入深度睡眠模式，但没有成功。
我们用开发板进行了一些实验，确定问题出在深度睡眠指令(0xB9)的传输和芯片选择信号上升之间的时间。闪存芯片要求芯片选择的字节边界很高，但有4.1微秒的延迟。
有什么办法能把时间安排得更紧些吗?我们已经看到这个命令在0.3微秒的延迟下工作，但是我们不确定这个要求到底有多严格。
关键词:
设备:
你好埃里克,
flash要求的CS是高的时间似乎相当严格，为了实现这一点，它将要求CS控制在SPI硬件本身，在585的情况下，CS是通过软件控制的。所以,我不认为你将能够达到0.3的时机,通过删除一些你可能会减少4.1我们的指令spi_access()命令,让一个自定义函数驱动下闪光,但你将能够达到大约我们的价值,减少了时间0.3我们极不可能。同时在内部检查，以确保，如果有什么不同于我所提到的，我会让你知道。
由于MT_dialog
很不幸，但还是谢谢你的建议。
你能建议一种替代的闪存芯片，睡眠命令是已知的工作?我们也许可以改变我们的设计，只要替换的部分至少是16Mb。
你好埃里克,
我还在用flash验证我之前的回答，你已经在使用了。如果我们测试了16Mbit的flash，一旦我得到团队的回复，我也会让你知道。
由于MT_dialog
你好埃里克,
更新你的问题,关于flash,您已经使用,我们没有具体的flash为了测试,但我们使用的同一家庭,问周围发现不应该有严格的时间为了去高为了flash芯片选择去睡眠模式,如果时间安排如此紧凑，文档应该提供该值。字节边界的文档flash提到意味着只要没有额外的时钟线为了推动一个额外的命令的设备应该能够进入睡眠模式,所以也许你发送一些额外的取消睡眠?在MX25R2035上测试，这是非常类似的一个，你有我能够把闪光灯在睡眠模式使用spi_flash_power_down()命令。
由于MT_dialog
谢谢你的帮助。我们发现问题出在别处，而我们的时间数据是用来转移注意力的。
现在看来，spi_flash_power_down()的工作做得很好。