Cannot put external flash into deep sleep mode

⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.xmece.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
6 posts / 0 new
Last post
Eric Scammell
Offline
Last seen:2年12个月前
加入:2017-03-15 13:28
Cannot put external flash into deep sleep mode

I've been trying to put an external flash chip (MX25R1635F) into deep sleep mode using the SDK function spi_flash_power_down(), but having no success.
Having conducted some experiments with development boards, we've determined that the problem is the time which passes between the transmission of the deep sleep command (0xB9) and the chip select signal going high. The flash chip requires that chip select go high on the byte boundary, but there's a 4.1 microsecond delay.

Is there any way we can tighten the timing here? We've seen the command work with a 0.3 microsecond delay, but we're not certain how tight the requirement actually is.

Device:
MT_dialog
Offline
Last seen:3 months 1 day ago
工作人员
加入:2015-06-08 11:34
Hi Eric,

Hi Eric,

The timing that the flash requires for the CS to be high seems quite strict, in order for this to be accomplished it would require the CS control to be on SPI hardware itself, in the 585 case the CS is controlled via software. So no, i dont think that you will be able to reach a timing of 0.3 us, you might reduce the 4.1 us via deleting some instructions from the spi_access() command and make a custom function for powering down the flash but you will be able to reach a value of around 3us, reducing the time to 0.3us its highly unlikely. Also checking this internally in order to make sure, if there is something different from what i 've mentioned i will let you know.

Thanks MT_dialog

Eric Scammell
Offline
Last seen:2年12个月前
加入:2017-03-15 13:28
That's unfortunate, but thank

That's unfortunate, but thank's for the input.
Can you suggest an alternative flash chip which the sleep command is known to work with? We might be able to change our design, so long as the replacement part is at least 16Mb.

MT_dialog
Offline
Last seen:3 months 1 day ago
工作人员
加入:2015-06-08 11:34
Hi Eric,

Hi Eric,

Still checking to verify my previous answer with flash that you are allready using, i will also let you know if we have tested 16Mbit flashes as soon as i get a response from the team.

Thanks MT_dialog

MT_dialog
Offline
Last seen:3 months 1 day ago
工作人员
加入:2015-06-08 11:34
Hi Eric,

Hi Eric,

An update on your issue, regarding the flash that you allready use, we dont have that specific flash in order to test it but we have used flashes of the same family, asking around find out that there should be no strict timing in order for the chip select to go high in order for the flash to go to sleep mode, if there was such a tight timing the documentation should provide that value. The byte boundary that the documentation of the flash mentions means that as long as there is no additional clock on the line in order to push an extra command the device should be able to go in sleep mode, so perhaps you are sending something extra that cancels the sleep ? Tested on a MX25R2035 which is quite similar with the one that you have i was able to put the flash in sleep mode using the spi_flash_power_down() command.

Thanks MT_dialog

Eric Scammell
Offline
Last seen:2年12个月前
加入:2017-03-15 13:28
Thanks for your help. We've

Thanks for your help. We've discovered that the problem lay elsewhere, and our timing data was a red herring.
It now appears that spi_flash_power_down() is doing it's job perfectly.