Octal xSPI Memory
Blazingly Fast. Low Power Consumption
- High Bandwidth
- Low Power
- Read While Write
With the need for greater processing performance at lower power, execute-in-place (XiP) is quickly becoming the architecture of choice for IoT devices. EcoXiP’s blazingly fast performance and low power consumption allow even time-critical software to be executed directly out of non-volatile memory, reducing boot time and system cost.
Best performance, best power
CoreMark® test on NXP’s i.MX RT1050 with 8 instruction cache
invalidations every ms to simulate task switching & interrupt handling.
CoreMark® score / power consumption.
EcoXiP Octal xSPI Memory
|Density||Product / Datasheet||Speed||Vcc range||Interface||Details||Status||Samples|
|128Mbit||ATXP128 (up to 105°C)||150MHz||1.7V-1.95V||SPI Octal SDR/DDR||● Active||Order Samples|
|64Mbit||ATXP064B (up to 105°C)||170MHz||1.7V-1.95V||SPI Octal SDR/DDR||● Preview||Order Samples|
|32Mbit||ATXP032 (up to 105°C)||150MHz||1.7V-1.95V||SPI Octal SDR/DDR||● Active||Order Samples|
|ATXP128-CCUE-Y||24CC - 8x6|
|ATXP128-CCUE-T||24CC - 8x6|
|ATXP128-UUE-T||WLCSP - Contact Adesto|
|ATXP128-DWF||See Wafer-Die Solution Menu|
|ATXP032-CCUE-Y||24CC - 8x6|
|ATXP032-CCUE-T||24CC - 8x6|
|ATXP032-UUE-T||WLCSP - Contact Adesto|
|ATXP032-DWF||See Wafer-Die Solution Menu|
|ATXP064B-CCUE-Y||24CC - 8x6|
|ATXP064B-CCUE-T||24CC - 8x6|
|ATXP064B-UUE-T||WLCSP - Contact Adesto|
|ATXP064B-DWF||See Wafer-Die Solution Menu|
Adesto EcoXiP Octal EVK Hardware Setup
Adesto EcoXiP Octal EVK Software Setup
Read While Write feature improves system performance
3 months ago
AT25DF641A Trouble programming the memoryPosted by shreyasbkulkarni 90 points 30 replies
I'm having difficulty with AT25DF641A - the 64 Mbit SPI serial memory. We have a mature design that is based on an older, now obsolete version - the AT25SF041 which was a 4 Mbit memory. The 2 devices seem pin compatible and are almost supported with the same command and memory structures.
On the AT25DF641A, I'm having difficulty writing data into the memory locations. Here are the steps I'm following -
1) I'm resetting the chip to begin my process. I start this by writing 0x31 and 0x10 to the status byte 2. This allows the device to get reset (RSTE bit = 1). I ensure that the WP_ pin is high when doing this operation. When the device is reset, the Status Registers read as follows -
Byte 1 = 0x1C
Byte 1 = 0x00
2) I then unprotect the flash globally by writing 0x00 to Status Register Byte 1 (keeping WP_ high during this time). However, reading the status register after this operation results in the same 0x1C and 0x00 values.
3) My next step is to pick an address, and erase the 4K block. I do this by ensuring that the particular memory location's sectors are not protected or locked. I clock in 0x03C (for reading sector protection register) and 0x35 (reading sector lockdown register) which all return 0x00 for both cases. I then do the 4K erase by doing a write enable first (WP_ is high and I clock in 0x06. When write enable is executed, the status register reads byte 1 = 0x1E, byte 2 = 00.
Then the 4K erase is performed by clocking in 0x35 (adn WP_ is kept high during the operation), followed by the 3 byte address. The status register reads 0x1C, and 0x00 after the erase.
4) After the 4K block erase, I'm writing my data to the location, by
a) Doing a write enable (WP_ kept high)
b) Clocking in 0x02, followed by 3 byte address (again WP_ high)
Upon reading the same location, I get 0xFF as the value, which means my write failed.
Anything obvious that I may be missing/overlooked? I know it is hard to tell without the code and actual logs, but any insight will be super appreciated!
One thing that is obviously bothering me is that I am unable to get the status register bytes to read (byte 1 =) 0x02 and (byte 2 = ) 0x00. My status register byte 1 always toggles b/w 0x1C and 1E, i.e. SWP bits are always 11 (default- all sectors protected) but when I do read the protection/lockdown status, they read 0x00.