cancel
Showing results for 
Search instead for 
Did you mean: 

Nor Flash

bharris
New Contributor II

Hello,
I am trying to write bit 3 of configuration register 3 in a S25HL250T device.  I see in the data sheet that the bit is only writeable in the nonvolatille memory space address 0x000004. 
My sequence is as follows:
read config 3 using a polling transfer routine // read data = 0x04... I was expecting 0x00 based on the data sheet??
data |=  0x08; //set bit 3 of the write data
WRENB_0_0;// write the write enable bit command 0x06

uint8_t command_buff[5] __attribute__ ((aligned (4)));

command_buff[0] = CYPRESS_WRITE_ANY_REG; //0x71
command_buff[1] = 0x00;
command_buff[2] = 0x00;
command_buff[3] = 0x04;
command_buff[4] = new_reg_data;

MSS_QSPI_polled_transfer_block(3, command_buff, 1, (uint8_t*)0, 0,0); 
//Polled transfer variables =(#address bytes, command, # of bytes after command, read buf, #of read bytes, # of idle cycles)

The write seems to work fine, but the register does not get written.
Any help would be appreciated.

Thanks,

Byron

0 Likes
9 Replies
BushraH_91
Moderator
Moderator

Hello,

Thank you for contacting Cypress Technical Support, an Infineon Technologies Company. We have received your inquiry and currently reviewing the case. We will get back to you as soon as we find the resolution.

Regards,

Bushra

0 Likes
YongQ_16
Employee

Hello Byron,

The command sequence and the register address (0x000004) are correct. However, the Configuration Register 3 value read from device does not seem to be right. Was the CR3 at factory default value before your writing it? The default CR3 should be 0x00.

Can you please try read device id command (0x9F) at 1-1-1 mode and 4-4-4 mode to see which mode it will work. Then read Configuration Register 1 and 2 values at the working mode. And share me the CR1 & 2 values.

Thanks!

Yong

0 Likes
bharris
New Contributor II

Hello Yong,

This click board  is new so I assumed that the defaults in all of the registers would be valid.
Until just a little bit ago I was getting JEDEC Flash ID: 342A1A (at 1-1-1).  I am now getting JEDEC Flash ID: CD0A86.  I removed power right after I started to do a sector erase cycle.  Is it possible I might have damaged the device?

Thanks
Byron

0 Likes
YongQ_16
Employee

Hello Byron,

Removing power during sector erase normally does not cause permanent damage to the device. It will cause incomplete erase (unstable data in the incomplete erased sector). It is recoverable. Re-erase the sector can recover. Removing power during register write operation may cause register corrupted and lead to unknow flash behavior.

What you observed (was able to get correct Flash ID, but failed now) seems like the flash device either damaged or configuration register corrupted.

Can you please also try read device id (command 0x9F) at 4-4-4 mode?

Thanks!

Yong

0 Likes
bharris
New Contributor II

Hi Yong,

You are correct, I have a spare click board and after powering it up and seeing the correct device ID, I ran it one time through the reads of all 3 configuration registers and that resulted in this board giving the same results as the first board.  I then figured out that I had completed a logical OR of 0x08 with the read result of 0xFF.  I then wrote the result to the configuration register 3 using a 01h command which works setting the upper nibble to 0xF, causing the Volatile Register Read Latency selection - Dummy cycles required for initial data access to 2/2/32.  I read the device ID with 2 Latency cycles getting the correct result of 0x342A1A.  Trying to read or write the configuration registers in 3 address mode using the RDARG_C_0 and WRARG_C_1 does not give the correct expected result.  I get 0x00 when I read all 3 registers, but configuration register 2 should be result in 0x08 (default), and when I write configuration register 3 = 0x08 using the 01h command that I know the command takes effect because it sets the  CFR3X[3] bit and I am able to erase all 256 sectors.

I am wondering if I need to use 4 BYTE addressing instead of 3 BYTE addressing since the full address is 0x00800004 (config reg 3)?

Thanks again for your help,

Byron

0 Likes
bharris
New Contributor II

FYI, I am not able to use 4-4-4 mode on my present setup.

0 Likes
YongQ_16
Employee

Hello Byron,

RDARG_C_0 and WRARG_C_1 commands support both 3-byte address and 4-byte address. It is determined by Configuration Register-2 bit7 (counted from 0). The default CFR2x[7] is 0, which requires 3-byte address for RDARG_C_0 and WRARG_C_1 commands. However, the register values on you click board could be corrupted, or not in default value, you may also try 4-byte address to see if there is difference.

You mentioned you used 01h command to write CR3. How did you do that? I meant what is the command sequence and input data? 01h command does not require address, but it needs the register values following 01h command in order, i.e., 01h + SR1 + CR1 + CR2 + CR3 + CR4.

Best Regards,

Yong 

 

0 Likes
bharris
New Contributor II

Hi Yong,
Since I am unable to read the correct value from the configuration registers (2&3) I cannot tell if they are corrupt or not.  Below is the output from my application and it includes the command sequence I am using for the command 01h.
[13.620041] Flash_erase(): Config REG 3 = 00
[13.625683] Flash_erase(): Config REG 2 = 00 Should Be 0x08
[13.631325] Flash_erase(): Config REG 1 = 00
[13.689637] Flash_erase(): Write Data = 08 data to write to config reg 3
Write using command 01h happens here

/****************************
static void write_cypress_cfg3reg
(
uint8_t new_reg_data
)
{


uint8_t command_buf[1] __attribute__ ((aligned (4)));
command_buf[0] = CYPRESS_WRENB_0_0; //0x01
MSS_QSPI_polled_transfer_block(0, command_buf, 0, (uint8_t*)0, 0,0);

wait_for_wel();

uint8_t cmd_buff[1] __attribute__ ((aligned (4)));

cmd_buff[0] = 0x30; //0x01
MSS_QSPI_polled_transfer_block(0, cmd_buff, 0, (uint8_t*)0, 0,0);

wait_for_wip();

 

uint8_t command_buff[6] __attribute__ ((aligned (4)));

command_buff[0] = CYPRESS_WRREG_0_1; //0x01
command_buff[1] = 0x00; // Status reg 1 default
command_buff[2] = 0x00; //Config reg 1 default
command_buff[3] = 0x08; // Config reg 2 default
command_buff[4] = new_reg_data; //Config reg 3 = 8 //TODO fix the R/M/W in the call
command_buff[5] = 0x00; // Config reg 4 default

MSS_QSPI_polled_transfer_block(0, command_buff, 6, (uint8_t*)0, 0,0);

wait_for_wr_strt();

wait_for_wip();
}

/******************************************************

[13.695105] Flash_erase(): Config REG 3 = 00 Read of Config REG 3 after the write using command 01h

I would like to make sure I am understanding your datasheet, configuration register 3 bit [3] states that the volatile register bit 3 is readable only V -> R.  Is this correct?  When a command 01h is used, is it writing the volatile or non-Volatile bit?
Do you have software snipets in you software of functions reading the configuration registers or using the RDARG_C_0 command that I can reference?

Thanks again for all of your assistance,

Byron

0 Likes
YongQ_16
Employee

Hi Byron,

Sorry for late response. Somehow I didn't get automatic notification when you posted the response.

Yes, your understanding is correct: configuration register 3 bit [3] volatile register bit 3 is readable only V -> R.  When a command 01h is used, it writes the non-Volatile bit. The volatile bit is automatically updated accordingly.

Can you please read Status Register 1 following below rules and let me know the result:

  • Use RDSR1_0_0 command (0x05), Or RDARG_C_0 command (0x65) + SR1 4-byte address (i.e., 0x00800000)
  • In Single SPI (1S-1S-1S) mode
  • Register Read Latency = 2 Clock Cycles

We do have low level drivers for SEMPER flash. Please follow the instruction on below link to register SEMPER Access Program and request for the low level driver software.

https://infineoncommunity.com/semper-eap

Best Regards,

Yong

0 Likes