DRA829V: OSPI Flash issue in custom board with DRA829V HS SR1.1 processor

Hi, 

Any update on the above mentioned query? We are stuck with the issue. Please support

Regards

Saravanakumar

Hi,

[6:23 PM] Saravanakumar Balasubramanian

Regarding the above mentioned query, We have observed Glitch in D2 data line with an amplitude of 3.3V during SPI,xSPI mode for CYPRESS Flash. In eMMC mode, glitch was reduced to 1V. But on the other data lines D3,D4 no glitches were observed. We have made external pullups as unpopulated. We don't know why glitch is coming at only D2 line.

Regards

Saravanakumar

First I want to establish if there is a real correlation between the failure and the glitch on D2.  It sounds like you still have 5 boards (or is it 4 boards?) with the old uboot image.

1) Do you see the glitch on any of the good boards?

Also, can you get a scope capture that includes the glitch on D2 and the CS signal?  I'd like to see that for both the failing board and a good board.

2) Could you explain the green line in your scope captures?

The label is VCC, which implies that it is one of the power signals, possibly VCCQ_IO_3V3.  But I would expect the power supply to be stable at 3.3V before any toggling on the data lines happen.  That is not what I'm seeing on the scope pictures.  I'm also not sure what is going on with the pullup resistors.

3) Are pullups installed on D2?  Do you see the glitch on D2 with the pullup?  Without the Pullup?  Both?  Did you take the pullups off after the failures occured?

I'd also like to establish whether there is a correlation between uboot image version and the failure. 

4) Is it still possible to flash the OSPI on the failing board?  If so, does the old uboot image recover the failing board?

-Zack

Hi Zack,

We checked with OSPI flash vendor CYPRESS. They have confirmed that the glitch on D2 line is not an issue since it is within the absolute max rating. But one nonvolatile reg Configuration_Register_3 bit 3 (CFR3N[3])  is being written as 1 in the driver code to select uniform sector mode. CYPRESS is telling that writing to a non-volatile register may corrupt the other internal registers in the flash. 

(Below is the comments given by CYPRESS for this reg.

This bit changes sector architecture in the device which is always nonvolatile configuration option. If customer changes CFR3N once then they do not need to and they should not keep changing this nonvolatile bit or register at every power on. Since this is an NV change, the device will keep the configuration upon every POR. So customer should remove this NV change routine from POR cycle. We have volatile bit as read only because we don’t want customers to change the sector architecture frequently. Generally, customers changes the sector architecture once as per their requirement)

Whether the driver code was already tested with CYPRESS flash and DR829 or any of the Jacinto processor?  

Below, I have given comments for your queries

1)In both good board and faulty board, same glitch coming. Attached scope image here.

2)Green line is VCCQ_IO_3v3 only.

3)No. We haven't connected external pullup on D2 line.

4)No after the flash failure, we are unable to read the device id of the flash. So it is not allowing to do any read, write operations.

Regards

Saravanakumar

"CYPRESS is telling that writing to a non-volatile register may corrupt the other internal registers in the flash"

Could Cypress elaborate which registers could become corrupted?  You should be able to write to the non-volatile registers without corrupting other non-volatile registers.  If the claim is that writing to non-volatile registers could corrupt volatile registers, and thus a reset is required after writing non-volatile registers, that would make sense.  And if you are writing to the non-volatile configuration register on every power up, then that could be the root cause of this problem.  I agree that it should only be done once.  Have you tried running the previous version of the flash driver on the failing board by booting through the emmc?  Then, can you comment out the non-volatile register write and run that on the failing board?

Hi Zack,

As per the U-boot driver for CYPRESS OSPI Flash, the non-volatile register CFR3N is being written on every Power on cycle. Please see the below U-boot driver snapshot of the file spi_nore_core.c in the path "ti-processor-sdk-linux-j7-evm-08_00_00_08/board-support/u-boot-2021.01+gitAUTOINC+53e79d0e89-g53e79d0e89/drivers/mtd/spi/"

Whether this driver has been validated with CYPRESS flash in any of the boards? We see that in DRA821 EVM, the CYPRESS Flash was used. Please provide us the modified driver as per your suggestion "CFR3N register to be written only once and in the Power on cycles, CFR3N register should not be written"

For failing board, we can't access the register since flash is not allowing to do any read/write operation and sf_probe command is not working.

I'm working with some software experts to learn more about this non-volatile memory write, but you should be able to avoid it by commenting out everything in your picture underneath the comment "/*Set the uniform sector mode bit*/".  If it's been written correctly once, you shouldn't need that line any more.  You could also change SPINOR_REG_CYPRESS_CFR3N to CFR3V.

I can't comment with certainty on the test coverage, but generally all SDK releases are tested on EVMs, and our J7200 EVM has a flash device very similar to the one you use. One hardware difference I noticed is that on the EVM has a 10K pull-up resistor on line D2, and only line D2.  If it's an easy change to make on your board, could you try adding that pull-up?

-Zack

Hi Zack,

In Micron Flash, D2 pin having the write protection functionality with active low signal. In Cypress flash datasheet, no write protection functio

Cypress is telling that new patch is available with TI for S28HS512T flash in the TI sdk as per the attached driver code.

static int s28hs512t_setup(struct spi_nor *nor, const struct flash_info *info,
			   const struct spi_nor_flash_parameter *params)
{
	struct spi_mem_op op;
	u8 buf;
	u8 addr_width = 3;
	int ret;

	ret = spi_nor_wait_till_ready(nor);
	if (ret)
		return ret;

	/*
	 * Check CFR3V to check if non-uniform sector mode is selected. If it
	 * is, set the erase hook to the non-uniform erase procedure.
	 */
	op = (struct spi_mem_op)
		SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RD_ANY_REG, 1),
			   SPI_MEM_OP_ADDR(addr_width,
					   SPINOR_REG_CYPRESS_CFR3V, 1),
			   SPI_MEM_OP_NO_DUMMY,
			   SPI_MEM_OP_DATA_IN(1, &buf, 1));

	ret = spi_mem_exec_op(nor->spi, &op);
	if (ret)
		return ret;

	if (!(buf & SPINOR_REG_CYPRESS_CFR3V_UNISECT))
		nor->erase = s28hs512t_erase_non_uniform;

	return spi_nor_default_setup(nor, info, params);
}

.   In the mainline u-boot, the driver just reads CFR3V to determine current sector arch setting (please see attached snippet).  The driver you attached (Writing CFR3N) looks like the one in early revision of the patch submitted (submitter is TI) to the mainline.  I think the “SDK” that the customer using picked up early revision of S28HS512T patch, or the customer is using older version of TI SDK.

But we checked the latest TI sdk, still the new patch for Cypress flash S28HS512T is not available in the latest TI sdk. Please release the latest driver for Cypress flash S28HS512T to use in our custom board.

Hi Zack, 

Hi Saravanakumar,

https://source.denx.de/u-boot/u-boot/-/blame/master/drivers/mtd/spi/spi-nor-core.c#L3357

Could you hand pick the code related to this from the mainline U-Boot file shared above?
Let us know.

Best Regards,
Keerthy

Hi Keerthy,

When we used the code in the above link you referred, we are unable to write to CYPRESS flash. Erase itself not happening. Below is the error log.

Hi Keerthy,

Any update on the above issue?  Please suggest any solution

Hi,

I am checking with internal team on the behavior. I will update you on the progress next week.

Thanks,
Keerthy

Hi Keerthy,

Any progress on the query?

Regards

Saravanakumar