PROCESSOR-SDK-AM437X: NAND erase issue on evmAM437x

Hi KTM,

KTM said:

Does this example work on the evmAM437x board?

This regression test log for PRSDK 6.1.0.8 shows this test passing, but only a read test is performed. I don't have an AM437x GP EVM to test it myself. Hence I can't say for certain this NAND write test passes. 

KTM said:

Is there a better example to follow?

I can't locate a better example in the PRSDK.

KTM said:

I don't have a jumper on J2.

I checked the schematic, and this looks correct (output enable not disabled on bus transceiver).

I suggest debugging further as follows:

• check the error return from Board_flashEraseBlk()
• step into Board_flashEraseBlk() to determine cause of failure

To aid in debugging, you can use the debug board library build.

• build the debug board library: gmake lib LIMIT_SOCS=am437x LIMIT_BOARDS=evmAM437x BUILD_PROFILE=debug
• link to debug board library: add "Board.Settings.libProfile = "debug"; to gpmc_arm_evmam437x.cfg

Let me know how it goes.

Regards,
Frank

Frank,

Thanks for the guidance.  I'll rebuild the board library as indicated and let you know what I find.

KTM

KTM,

Thanks, I'll wait for your reply.

Regards,
Frank

Frank,

I built the debug version of the board library and made the change to the cfg file.  Debugging is now a lot easier!  Thanks.

The function Nand_gpmcDeviceStatus is returning NAND_DEV_PROTECTED (see line 400 in nand_gpmc.c).  This function is called from Nand_gpmcErase().

I did notice this E2E post for the AM3358 but changing GPMC_WPn to a GPIO didn't seem to help.  Maybe I didn't make the change correctly.   

What should I try next?  I'll see if I can capture GPMC_WPn.

Thanks,

KTM

Hi KTM,

KTM said:

What should I try next?  I'll see if I can capture GPMC_WPn.

Yes, this is a good next step.

Can you connect with JTAG and check the state of the CTRL_CONF_GPMC_WPN register?

This register is located in the CONTROL_MODULE.

• CONTROL_MODULE base address: 0x44E10000
• CTRL_CONF_GPMC_WPN offset: 0x874.

Regards,
Frank

Frank,

The mode bits for CONTROL_MODULE_CTRL_CONF_GPMC_WPN were set to 0  (gpmc_wpn).  That got me thinking about some GPIO changes we made to file  am43xx_gpevm_pinmux_data.c using the TI pinmux tool SysConfig.  I reverted back to the original am43xx_gpevm_pinmux_data.c file and noticed that the mode bits were now 9 (gpio5_31),and the Flash erase error has gone away.  It turns out that the original am43xx_gpevm_pinmux_data.c overrides in section GPIO5 of the file the gpmc_wpn mode of 0.

I noticed that if I import the file gpevm_config.pinmux from the SDK then SysConfig doesn't generate a duplicate file to am43xx_gpevm_pinmux_data.c from the SDK.  In fact there are a lot of differences.  This was a surprise to me and something I should have checked more closely.  Is this intentional on TI's part or did I misuse SysConfig?

The application now throws a NAND_ECC_UNCORRECTABLE error during reading of the Flash but the data verify passes.  Not sure why I'm getting that error.  Thoughts?

Thanks,

KTM

Hi KTM,

KTM said:

Flash erase error has gone away

It's strange the error goes away when the pin is configured for gpio5_31 outout. It seems like the pin should be configured for gpmc_wpn. How do the other CTRL_CONF_GPMC_WPN bit field compare for the working and non-working cases?

KTM said:

Is this intentional on TI's part or did I misuse SysConfig?

I need to check into this. Can you please provide an outline of how you used the SysConfig tool and share the files so I can compare?

KTM said:

application now throws a NAND_ECC_UNCORRECTABLE error

Are you using the OOB demo code? Where is this error observed, i.e. which function?

Regards,
Frank

Frank,

(1) Based on my testing, setting pin GPMC_WPN to mode 0 (gpmc_wpn) or mode 7 (gpio0_31) results in a flash erase error.  Mode 9 (gpio5_31) does not result in the flash erase error.  Recall that above I referenced a previous E2E post that also solved a similar issue (although with a different Sitara part) by setting pin GPMC_WPN to a GPIO.

(2) Run SysConfig (cloud-based version) and load gpevm_config.pinmux from C:\ti\sdk_am437x_06_01_08\pdk_am437x_1_0_16\packages\ti\starterware\tools\pinmux_config\am43xx.  Examine file am43xx_pinmux_data.c in the right-hand window and search for GPIO5.  There is only one entry and it is not related to pin GPMC_WPN.

(3)  I believe the code is OOB (except that I allowed the data verification routine to execute even if an error occurs).  Function Nand_gpmcEccCheckAndCorrect() called from Nand_gpmcReadPage() in nand_gpmc.c appears to be returning the NAND_ECC_UNCORRECTABLE error.  BTW, comparisons such as

if(status & NAND_ECC_ERR_CORRECTED)

  from line 889 of nand_gpmc.c seem suspicious when "status" and NAND_ECC_ERR_CORRECTED are not restricted to be powers of two.  Perhaps I don't understand the author's intent.

Thanks,

Kevin

Hi Kevin,

KTM said:

(1) Based on my testing, setting pin GPMC_WPN to mode 0 (gpmc_wpn) or mode 7 (gpio0_31) results in a flash erase error.  Mode 9 (gpio5_31) does not result in the flash erase error.  Recall that above I referenced a previous E2E post that also solved a similar issue (although with a different Sitara part) by setting pin GPMC_WPN to a GPIO.

Thanks, I recall the E2E post you referenced before. However, I don't understand why it works and no explanation is provided. Are any other bit-fields in CTRL_CONF_GPMC_WPN different between the working and non-working cases, or is CONF_GPMC_WPN_MMODE the only difference?

KTM said:

(2) Run SysConfig (cloud-based version) and load gpevm_config.pinmux from C:\ti\sdk_am437x_06_01_08\pdk_am437x_1_0_16\packages\ti\starterware\tools\pinmux_config\am43xx.  Examine file am43xx_pinmux_data.c in the right-hand window and search for GPIO5.  There is only one entry and it is not related to pin GPMC_WPN.

I think you're using the SysConfig tool correctly. It appears the AM437x GP EVM .pinmux & .C files don't match, i.e. these files don't match:

./ti/starterware/tools/pinmux_config/am43xx/gpevm_config.pinmux
./ti/starterware/board/am43xx/am43xx_gpevm_pinmux_data.c

Further, none of the AM437x .pinmux files match with the data in am43xx_gpevm_pinmux_data.c. I think this is a bug. I see the same issue exists in the AM437x PRSDK 6.3 release.

KTM said:

BTW, comparisons such as

if(status & NAND_ECC_ERR_CORRECTED)

Agreed, this seems like another bug. If Nand_gpmcEccCheckAndCorrect() is returning NAND_ECC_UNCORRECTABLE, why isn't the code in the if() clause executed?

ti/board/src/flash/nand/nand.h:91:#define NAND_ECC_ERR_CORRECTED (-9U)
ti/board/src/flash/nand/nand.h:94:#define NAND_ECC_UNCORRECTABLE (-10U)

            status = Nand_gpmcEccCheckAndCorrect(handle, pEccData, pRxData);
            Nand_gpmcEccDisable(handle);

            if(status & NAND_ECC_ERR_CORRECTED)
            {
                    eccCorFlag = 1U;
            }
            else if(status & NAND_ECC_UNCORRECTABLE)
            {
                    break;
            }
            else
            {

            }

As I mentioned before, I don't currently have access to an AM437x GP EVM. I'll try to obtain one in the next few days so I can better assist you.

Regards,
Frank

Frank,

When the Flash erase passes, here's the configuration for pin GPMC_WPN:

    {
    /* My GPIO 5 -> gpio5[31] -> B3 */
    PIN_GPMC_WPN, 31, \
    ( \
        PIN_MODE(9) | \
        ((PIN_PULL_UP_EN | PIN_DS_VALUE_OVERRIDE_EN | PIN_DS_OP_DIS | PIN_DS_PULL_UD_EN) & \
        (~PIN_PULL_UD_DIS & ~PIN_RX_ACTIVE & ~PIN_DS_OP_VAL_1 & ~PIN_WAKE_UP_EN))
    ) \
    },

CTRL_GPMC_WPN shows 0x0B020009.

With this setting for pin GPMC_WPN the Flash erase fails:

    {
       /* My GPMC 0 -> gpmc_wpn -> B3 */
       PIN_GPMC_WPN, 0, \
       ( \
           PIN_MODE(0) | \
           ((PIN_PULL_UP_EN | PIN_DS_VALUE_OVERRIDE_EN | PIN_DS_OP_DIS | PIN_DS_PULL_UP_EN) & \
           (~PIN_PULL_UD_DIS & ~PIN_RX_ACTIVE & ~PIN_DS_OP_VAL_1 & ~PIN_DS_PULL_UD_EN & ~PIN_WAKE_UP_EN))
       ) \
    },

CTRL_GPMC_WPN shows 0x13020000.

Were you able to find a AM437x GP EVM board?

Any update on why the pinmux data file generated by the SysConfig tool doesn't match the corresponding file in the SDK? 

Thanks,

KTM

Hi Kevin,

I notice differences between the DS0 mode settings:

GPIO5_31 0000 1011 0000 0010 0000 0000 0000 1001
GPMC_WPN 0001 0011 0000 0010 0000 0000 0000 0000

GPIO5_31 [27] CONF_GPMC_WPN_DSPULLUDEN = 1b
GPMC_WPN [27] CONF_GPMC_WPN_DSPULLUDEN = 0b
DS0 mode Pull-Up/Down enable.
This is an active low signal.
1 = Pullup / Pulldown disabled
0 = Pullup / Pulldown enabled

GPIO5_31 [28] CONF_GPMC_WPN_DSPULLTYPESELECT = 0b
GPMC_WPN [28] CONF_GPMC_WPN_DSPULLTYPESELECT = 1b
DS0 mode Pull-Up/Down selection
0 = Offmode Pull-Down selected
1 = Offmode Pull-Up selected

GPIO5_31 [28] CONF_GPMC_WPN_DSPULLTYPESELECT = 0b
GPMC_WPN [28] CONF_GPMC_WPN_DSPULLTYPESELECT = 1b

I doubt these differences will make a difference, but have you tried using the GPIO5 DSN0 settings in the WPN case?

KTM said:

Were you able to find a AM437x GP EVM board?

I've asked my management above this, but I still don't have one. I'll keep you posted.

KTM said:

Any update on why the pinmux data file generated by the SysConfig tool doesn't match the corresponding file in the SDK? 

As I said before, I believe this is a bug. I'll inform the development team, and it might be fixed in a future release. Were you expected some other kind of update?

Regards,
Frank

Hi Kevin,

I'm still trying to acquire an AM437x GP EVM. In the meantime, have you tried the OOB example on an AM437x GP EVM using PRSDK 6.3?

https://software-dl.ti.com/processor-sdk-rtos/esd/AM437X/06_03_00_106/index_FDS.html

Regards,
Frank

Frank,

I tried the OOB example from PRSD 6.3.  Here's the UART output:

                                                                               
    GPMC flash device ID: 0xdc90, manufacturer ID: 0x2c                            
                                                                                
    GPMC flash block erase test passed.                                            
                                                                                
    GPMC flash write test passed.   

The app hung in Nand_gpmcBchEccCheckAndCorrect() in file nand_gpmc.c at line 729:   while(intrStatus == 0).  This is something I haven't seen with the earlier PRSD.

Also, CTRL_CONF_GPMC_WPN read 0x0B020009 for the app, which indicates the app is setting the mode for pin gpmc_wpn as gpio5_31.

I also tried using the GPIO5 DSN0 settings in the WPN case and got flash erase failure message again.

Thanks,

KTM

Hi Kevin,

KTM said:

The app hung in Nand_gpmcBchEccCheckAndCorrect() in file nand_gpmc.c at line 729:   while(intrStatus == 0).  This is something I haven't seen with the earlier PRSD.

So now the test passes the erase (Board_flashEraseBlk()) and write (Board_flashWrite()), but you observe a failure inside the read (Board_flashRead())?

KTM said:

CTRL_CONF_GPMC_WPN read 0x0B020009 for the app, which indicates the app is setting the mode for pin gpmc_wpn as gpio5_31.

I also tried using the GPIO5 DSN0 settings in the WPN case and got flash erase failure message again.

Ok, thanks for checking. For now I think it's safe to assume the 0x0B020009 setting is proper.

I should acquire an AM437x GP EVM this week so I can check the PRSDK 6.3 behavior.

Regards,
Frank