Flash Programming Write & Erase fails on QSPI_B

[keithw]

On our board design, we have two QSPI Flash Chips (1Gb each) that we will be operating in parallel mode on a LS1046A.  We are using the Flash Programmer utility in Code Warrior (version 11.5.12) to program the devices.  When we program QSPI A flash (Starting Address 0x40000000), everything works as expected.  When we attempt to program QSPI B flash (0x48000000), the data is not written to flash.  We also cannot successfully execute erase commands.  If we program the QSPI B chip using an external device (Corelis JTAG), we are able to successfully read in parallel mode.

Upon investigation of the problem, we instrumented the QSPI Clock, Chip Select, and 4 data lines for the two QSPI chips.  When we issue an Erase command on QSPI A, we see a series of commands go out the QSPI A bus.  I think it’s a status register read, another status register read, a write enable, a status register read, and finally a series of sector erase commands.  This works as expected.

When we issue the Erase command on QSPI B, the same set of commands are sent but the status register read and write enable commands are transmitted out to the QSPI A device while the Erase is sent to the QSPI B device. Since the QSPI B device has not received the WRITE enable command, the Erase does not work.  I’ve attached a scope capture that shows this behavior.

QSPI_B Scope Capture

Here are the scope signals:

D0 – QSPI_A Clock

D1 – QSPI_A Chip Select

D2 – QSPI_A D0

D3 – QSPI_A D1

D4 – QSPI_A D2

D5 – QSPI_A D3

D6 – QSPI_B Clock

D7 – QSPI_B Chip Select

D8 – QSPI_B D0

D9 – QSPI_B D1

D10 – QSPI_B D2

D11 – QSPI_B D3

Any ideas on what may be going on to cause this behavior?

[keithw · Accepted solution]

I finally solved this issue.  There are a few bugs in the QSPI_64b.bin file.  As shown in the original scope capture, all the status register reads and write enable commands are sent to the incorrect device.  This is controlled by the SFAR register of the QSPI controller.  In the QSPI_64b.bin logic, SFAR is set to the xspi_base_device address in these routines, which is hard-coded to 0x40000000 which results in these commands always going to QSPI A1. 

The source code for the QSPI_64b.bin file can be obtained as discussed in this article: https://community.nxp.com/t5/CodeWarrior-for-QorIQ/Adding-a-flash-device-configuration-CodeWarrior-1...

Application Note 5398 (https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/qoriq-grl/7636/2/AN5398%2520Adding%2520D...) provides details on how to build and debug the QSPI algorithm file.

@yipingwangYou might want to pass this along to the development team so that they can properly update this algorithm file to properly support the additional QSPI devices.

[keithw]

@yipingwangHave you heard anything back from the expert team?  Do you need any additional information from me to help figure this out?

[yipingwang]

I am still working for the update from the expert team now.

I have contacted them again, will update to you as soon as possible.

[yipingwang]

Do refer the section 27.7.7 Parallel mode in LS1046ARM to operate the QSPI flash in parallel mode.
Check with the customer if the pin muxing is correctly set in IFC_GRP_[F/E1/D]_EXT RCW field for the QSPI A and B flash. Please Refer to section 3.4.7 IFC, QSPI, FTM and GPIO2 signal multiplexing in LS1046ARM for the same.

We are further investigating the issue on our end.

[keithw]

If we program the chips using external tools, we are able to boot and read from the parallel flash chips which confirm that the pin multiplexing settings in the RCW are correct.  I have verified these settings.  This issue only appears when programming using the CodeWarrior Flash Programming utility. 

[yipingwang]

In the following "QSPI Initialization" section in "Target Initialization File", please configure 

QSPI_BFGENCR[PAR_EN] and QuadSPI_IPCR[PAR_EN] as "1".

###################################################################
# QSPI Initialization
###################################################################
def Init_QSPI():
# QSPI_CFG
CCSR_BE_M(0x157015C, 0x20100000)

# SMPR
CCSR_BE_M(0x1550108, 0x00000000)

# QuadSPI_FLSHCR
CCSR_BE_M(0x155000C, 0x00000303)

# Set top address for each device
CCSR_BE_M(0x1550180, 0x44000000)
CCSR_BE_M(0x1550184, 0x48000000)
CCSR_BE_M(0x1550188, 0x4C000000)
CCSR_BE_M(0x155018C, 0x50000000)

# BUF0CR
CCSR_BE_M(0x1550010, 0x00000000)
# BUF3CR
CCSR_BE_M(0x155001C, 0x80000000)
# BFGENCR
CCSR_BE_M(0x1550020, 0x00000000)

# QuadSPI_MCR
CCSR_BE_M(0x1550000, 0x000f4000)

In the following section in "Adds Flash devices for this board" in "Target Initialization File", please configure "address" as 0x48000000.

# Add QSPI device
fl.add_device({"alias": "qspi", "name": "S25FS512S", "address": 0x40000000, "ws_address": 0x10000000, "ws_size": 0x1FFFF, "geometry": "8x1", "controller": "QSPI"})

[keithw]

We have made the suggested changes to our target initialization script and are still unable to program the device on QSPI B.  Our target initialization script was configured as you suggested with the exception of QSPI_BFGENCR[PAR_EN] and QuadSPI_IPCR[PAR_EN] as "1".  We added that change and saw the same behavior when attempting to program the QSPI_B flash chip.

[yipingwang]

Please refer to the following update from the AE team.

Please request the following information from the customer:

1) The connection scheme (schematic) of their design.
2) The scripting file or target initialization file used for initializing the QSPI flash devices. Have there been any changes to this file?
3) Are you able to access QSPI flash devices (A and B) in individual mode and successfully execute the erase command? Can the read and write commands be executed on the QSPI flash device? Please note that in parallel mode, only read commands are supported, whereas in individual flash mode, all supported commands are available. Refer to section 27.6.1 "Serial Flash Access Schemes" in the LS1046ARM for detailed information.
4) Is there a specific reason for using the CodeWarrior Flash Programmer utility to program the QSPI flash devices?

[keithw]

I am back to troubleshooting this issue. Based on your latest comments, I have setup the target initialization file to not be in parallel mode and am attempting to do a simple erase on the Flash B device. We are using the MT25QU01GBBB (1 Gbit / 128 MB) part for both Flash A and Flash B. I have configured the top addresses for each device (A1, A2, B1, B2) as 0x48000000, 0x50000000, 0x58000000, and 0x60000000 respectively. I have configured a single flash device for the programmer using address 0x50000000 so I would expect all commands issued to go to Flash device B1. I am still seeing the same behavior as the original scope capture -- status register reads and Write Enable commands are going out on Flash A lines while the erase command is going out on the Flash B lines.

I have attached the target initialization script as requested. I am unable to provide full schematics, but I have provided a snip of the schematic showing the two Flash devices. Again, if I program the flash devices using a different programmer, we are able to boot the board using the parallel mode so I believe the physical connections to the devices are correct.

[keithw]

@yipingwang As a more simple test case, I use the gdb command line interface to the flash programmer (using cwflash.py) with a target init script configured as described in my above response.  When I issue a fl_id command, the scope shows the register read occurring on the QSPI A lines.  If I issue a fl_dump command, I see the read activity correctly occurring on the QSPI B lines.  I believe there is an issue in the QSPI_64b.bin logic that executes these commands on the target, but I don't have access to the source code for this logic.  I suspect the Serial Flash Address Register (QuadSPI_SFAR at 0x1550100) is not being set properly which results in transactions occurring on chip A1 instead of the proper chip.

[yipingwang]

Discussing with the expert team.

[keithw]

Any updates?