PROCESSOR-SDK-AM437X: NAND Bad Block Management and ECC usage

Hi,

Are you aware of advisory 15 of the AM437x errata?

This may be the root cause to the issues you've seen. I'm reaching out to other experts internally for confirmation and will get back to you asap.

Regards,

Jianzhong

Hi Jianzhong,

thanks for your reply.

I have checked our Hardware and we are using silicon revision 1.2. I assume the errata advisory 15 only affects silicon revision 1.1.

The ROM bootloader in our case loads the SBL from the NAND. The SBL is responsible to load the main application and this fails. The SBL does not correct the bitflips while reading the NAND pages. I guess this cause our problem.

Hi,

It's good to know that you have silicon revision 1.2 which doesn't have advisory 15 issue. Let me do some research about the SBL, but it will likely take a few days. I'll get back to you early next week.

Thanks and regards,

Jianzhong

Hi,

While I'm doing research internally, maybe you can check out a few things:

1. The bootloader and flashing utility were written for AM437x EVM. Have you done any testing of the system on this EVM? Did NAND booting work well?

2. Can you run some NAND diagnostic to ensure the NAND operation is working with ECC (irrespective of ROM)?

3. Check AM437x TRM, chapter 5.2.6.4 NAND Memory and make sure your system design meets the requirements given there.

4. The PDK version you are using is a pretty old one. The latest is 1.0.17 from Processor-SDK 6.3. Can you upgrade and see if it makes any difference?

Thanks,

Jianzhong

Hi,

tanks for your fast reply.

1. We have not tested the bootloader on the EVM because we have no EVM board. But the NAND booting works well as long as no bitflips occur on the NAND. If we have programmed the devices (includes the external NAND) in our production line, the devices must pass an production end test which require a successful boot process. Therefore I claim the NAND booting work well on our board in general. This means all devices our customers return, have been working well while we deliver it. The problems comes after operation time in the customer application due to single bitflips on the NAND. I i reprogram the device the failure is gone and the device is booting again. 

2. I will try to do some diagnostics in the next days and will give a feedback to this point. At first I have to check how can I simulate a bitflip on the NAND.

3. I guess our design meets the requirements. At least I have found nothing what the opposite proves. We use a Micron MT28EW512ABA1LPC-0SIT NAND flash device. This device is ONFI compatible and should meet the timing requirements.

4. We are using the PRU ICSS Profinet package version 1.0.2. These package release use SDK-RTOS 04_02_09 (which includes PDK 1.0.9). In the past we have problems with our application if we switch the SDK respectively the PDK. Furthermore it could be problematic for profinet certification if we upgrade any components of our software that are responsible for Profinet network connectivity. But I have compared the source file of the SBL of both PDK versions. For we there are no differences which can explain our problem. Also the release notes of the components does not indicate anything to this issue.

Does the starterware SBL make any assumption about ECC handling is done by internally by the external NAND device? If I understand it correctly, the ROM bootlaoder use the SYSBOOT option to determine this. How does the SBL handle this?

marc elsner said:

Does the starterware SBL make any assumption about ECC handling is done by internally by the external NAND device? If I understand it correctly, the ROM bootlaoder use the SYSBOOT option to determine this. How does the SBL handle this?

I'll check this out.

marc elsner said:

We use a Micron MT28EW512ABA1LPC-0SIT NAND flash device.

Can you provide a link to the data sheet for this device?

Some additional information from the TRM:

Can you check if you have SYSBOOT[6] cleared to enable ECC by ROM?

I have made a mistake. The NAND is an Micron MT29F1G08ABADAH4.

here is an link to the micron device page:

MT29F1G08ABADAH4 (micron.com)

I have no account to download the datasheet but I have an offline copy. How can I provide the offline copy to you?

Furthermore I'm aware that the device status is obsolete. For our product, we have replaced this NAND by another vendor part. But we have many devices delivered to our customers where this Micron NAND is a part of.

You are right, this is a problem in our design. The SYSBOOT[6] is not cleared. it has a pull-up resistor and this could cause addtional problems for our device if the fist block of the NAND, which holds the SBL, is corrupted.

But nevertheless this should only effect the ROM bootloader if I understand the manual correctly, the SYSBOOT option is only used within the ROM bootloader code. Correct?

Or does this option also effect the SBL behavior?

Thanks for the link. I briefly looked at the data sheet and it actually has internal ECC. But anyway, if NAND doesn't do ECC, ROM ECC should be enabled, i.e. clearing SYSBOOT[6]. 

marc elsner said:

But nevertheless this should only effect the ROM bootloader if I understand the manual correctly, the SYSBOOT option is only used within the ROM bootloader code. Correct?

This is correct. SBL is not affected by SYSBOOT.

I have a few questions for clarification:

1. what is the exact flashwriter that you used to flash the SBL into NAND? Which ECC algorithm did you choose when you did the flashing?

2. did you use the SBL in this folder pdk_am437x_1_0_9\packages\ti\starterware\binary\bootloader\bin\am43xx-evm\gcc?

I double checked the SBL source code and confirmed that it does perform error correction using BCH8. Please keep in mind that the SBL only supports BCH8. So the flashing has to use BCH8 too. Otherwise, the SBL won't be able to correct bit errors.

Hello,

Jianzhong Xu said:

1. what is the exact flashwriter that you used to flash the SBL into NAND? Which ECC algorithm did you choose when you did the flashing?

we use the flashwriter sources from this folder:

pdk_am437x_1_0_9\packages\ti\starterware\tools\flash_writer\src\nand-flash-writer_AM335x

We have made some changes. But all of our changes does not effect the nand driver. We use also the BCH8 ECC.

If you will check our flashing sources, i can provide the CCS project to you. 

Jianzhong Xu said:

2. did you use the SBL in this folder pdk_am437x_1_0_9\packages\ti\starterware\binary\bootloader\bin\am43xx-evm\gcc?

yes, we use this SBL. We have made some minor changes to the sources to support our custom board. The changes only effect the DDR3 timings and the PLL initialization. We have made no changes to the nand driver or ECC driver.

If the ECC algorithms are different between bootlaoder and flashing utility, you are right, the bootlader can't correct bit errors. But shouldn't anyway detect the bootloader that the ECC value is completely different from the calculated. What happens in this case on the SBL?

marc elsner said:

If the ECC algorithms are different between bootlaoder and flashing utility, you are right, the bootlader can't correct bit errors. But shouldn't anyway detect the bootloader that the ECC value is completely different from the calculated. What happens in this case on the SBL?

After looking into the SBL NAND ECC code, I believe no action is taken if bit errors are not correctable. The NAND ECC function is called by NANDLibPageRead() in starterware/library/nandlib/nand_lib.c. You can see from the code snippet below that whenever there are  uncorrectable errors, the read stops and function returns:

                    status = gNandLibObj[chipSel].pFnEccCorrect(pNandLibInfo, pEccData, pRxData);
                    gNandLibObj[chipSel].pFnEccDisable(pNandLibInfo);

                    if(status & NAND_LIB_ECC_ERR_CORRECTED)
                    {
                        eccCorFlag = 1U;
                    }
                    else if(status & NAND_LIB_ECC_UNCORRECTABLE)
                    {
                        break;
                    }

Then, from starterware/bootloader/src/sbl_nand.c, you can see that if NANDLibPageRead() fails, no action is taken except printing out  a diagnostic message.

Jianzhong Xu said:

Then, from starterware/bootloader/src/sbl_nand.c, you can see that if NANDLibPageRead() fails, no action is taken except printing out  a diagnostic message.

I had a deeper insight to this.

I do not see the diagnostic message on the debug output on our devices while booting. Therefore I guess the NANDLibPageRead() function does not have an uncorrectable error.

Nevertheless I guess here is the next potential problem of the SBL. The return value of the function SblNandReadFlash() function which is called from the SBL is not checked for errors in fucntion SblNandImageCopy(). This function is called by the SBL to  load the binary image to RAM. Therefore I guess the bootloader starts anything independent from the return value of the NANDLibPageRead() function. See the code snippet below.

static uint32_t SblNandImageCopy(uint32_t *pEntryPoint)
{
    ti_header imageHdr;
    int32_t status = S_PASS;

    /* NAND read function to read the header. */
    SblNandReadFlash(&gSblNandObj, IMAGE_OFFSET, sizeof(imageHdr),
        (uint8_t *) &imageHdr);
    CONSOLEUtilsPrintf("\nCopying Header of the application image ");

    *pEntryPoint = imageHdr.load_addr;

    CONSOLEUtilsPrintf("\nCopying image from flash to DDR\r\n");
    /* Copies application from NAND flash to DDR RAM */
    SblNandReadFlash(&gSblNandObj, IMAGE_OFFSET + sizeof(imageHdr),
        imageHdr.image_size, (uint8_t *)(imageHdr.load_addr));

    return status;
}

The check function I use to detect the bitflips on the NAND, verify the NAND pages with following code snippet:

        if (AM335X_NAND_verifyPage(hNandInfo, blockNum, (count & countMask), dataPtr, gNandRx) != E_PASS)
        {
            CONSOLEUtilsPrintf("\tData block verification failed at block ");
            CONSOLEUtilsPrintf("%d", blockNum);
            CONSOLEUtilsPrintf(" on page ");
            CONSOLEUtilsPrintf("%d (Hex: 0x%x)", (count & countMask), (count & countMask));
            CONSOLEUtilsPrintf("\r\n\r\n");
            retCode = E_FAIL;
        }

The function AM335X_NAND_verifyPage() is part of the nand_writter I have mentioned in my previous post.

The function to verify the page AM335X_NAND_verifyPage() in nand.c calls a functions named NAND_readPage() from the same source file. This function returns E_PASS in our case but the following check for data read errors shows differences between expected and received data. The difference is always one bitflip on the faulty devices. If I repeat the test, the bitflip is always at the same position in NAND. Because of this I think this is no random read error.

Here is code snippet of the AM335X_NAND_verifyPage() function:

Uint32 AM335X_NAND_verifyPage(AM335X_NAND_InfoHandle hNandInfo,
		Uint32 block, Uint32 page, Uint8* src, Uint8* dest)
{
	Uint32 i, errCnt;

	if (NAND_readPage(hNandInfo, block, page, dest) != E_PASS)
		return E_FAIL;

	errCnt = 0;
	for (i = 0; i < (hNandInfo->dataBytesPerPage); i++) {
		// Check for data read errors
		if (src[i] != dest[i]) {
			errCnt++;
			DEBUG_printString("Data verification failed! Byte # ");
			DEBUG_printHexInt(i);
			DEBUG_printString(" Expected Data: ");
			DEBUG_printHexInt(src[i]);
			DEBUG_printString(", Received Byte: ");
			DEBUG_printHexInt(dest[i]);
			DEBUG_printString("\r\n");
		}
	}

	if (errCnt != 0) {
		return E_FAIL;
	} else {
		return E_PASS;
	}

}

I have checked the function with a new device from stock and everything works fine. The read data equals the expected data. Therefore I claim the the function works in general.

marc elsner said:

I do not see the diagnostic message on the debug output on our devices while booting. Therefore I guess the NANDLibPageRead() function does not have an uncorrectable error.

Did you see any other diagnostic messages? Just wanted to double check if console printing is enabled.

marc elsner said:

This function returns E_PASS in our case but the following check for data read errors shows differences between expected and received data. The difference is always one bitflip on the faulty devices.

Function NAND_readPage() does ECC. If it returns E_PASS, that means errors are corrected. But the following check shows 1-bit error. I don't understand why this was happening.

Which ECC did you choose for flashing?

When function AM335X_NAND_verifyPage() returns E_FAIL, that block is erased. Did you see corresponding diagnostic message?

Jianzhong Xu said:

Did you see any other diagnostic messages? Just wanted to double check if console printing is enabled.

Yes, other diagnostic messages were printed to the console

Jianzhong Xu said:

Which ECC did you choose for flashing?

We call Uint32 AM335X_Device_setECC()  with eccType 1 which should be BCH9 ecc sheme for flashing.

Jianzhong Xu said:

When function AM335X_NAND_verifyPage() returns E_FAIL, that block is erased. Did you see corresponding diagnostic message?

To check for NAND content errors, I have modified the nandwriter in a separate project to only check the flash without modification of any content. Therefore in my code no erase will happend. Only a diagnostic message is printed out to the debug console.

If I re-flash the device with the shipped nandwriter, the function AM335X_NAND_verifyPage() does not fail. If I have re-flashed the device, my NAND check function also pass.

marc elsner said:

Therefore in my code no erase will happend.

So do you rely on the NAND SBL to correct the bit flips when reading from NAND?

marc elsner said:

If I re-flash the device with the shipped nandwriter, the function AM335X_NAND_verifyPage() does not fail.

Does this mean there is no problem if you use the flashwriter from the PDK?

Jianzhong Xu said:

So do you rely on the NAND SBL to correct the bit flips when reading from NAND?

Yes, but I don't understand the relation of this question to my statement from my previous post. I rely on the SBL to correct bitflips as far as it is possible with the ECC sheme (BCH8) used.

Jianzhong Xu said:

Does this mean there is no problem if you use the flashwriter from the PDK?

In our production line we use the flashwirter from PDK with some modifications to support our custom board. The nandwritter from the PDK perform a AM335X_NAND_verifyPage() after the flash page was written. Here we have no errors in our production line. If the nandwriter fails in production line, the devices will not be delivered because they do not pass the factory end test. Therefore I guess the nandwriter from the PDK works in our production line.

The devices with the bitflips on the NAND are returns from our customers. I have analysed these returned devices with my custom NAND content verification firmware, which is also based on the nandwriter from the PDK but without erasing or writing to the flash. Only the page verification against the expected firmware binary is done and detects the bitflips. The verification firmware is written into the RAM with my debug probe from CCS and is not written to NAND. The NAND stays untouched.

If I re-program these devices in our production line with the same process, everything is OK and the NAND content is verified as expected.

Is it possible to disable ECC in your verification software to find the actual bit-flips in the NAND? This can tell us how many bit-flips are in the NAND and how many (if any) are corrected by the ECC. If ECC in NAND_readPage() doesn't correct any bit-flips, then we can focus on the  ECC in NAND library.

To  disable ECC in my software should be possible.

I will modify the software and will check the result. I won't be in the office until Tuesday. I will give you a feedback on Tuesday

That sounds good. Thanks.

unfortunately it is not so easy to disable ECC. 

I have changed the following line:

pObj->nandLibInfo.nandLibCtrlInfo.eccAlgo = NAND_LIB_ECC_ALGO_NONE;//NAND_LIB_ECC_ALGO_BCH_8BIT;

But if I init the NAND lib (nand_lib.c) with this modification, the NAND lib init failed function (NANDLibInit()) failed. The NAND lib requires NAND_LIB_ECC_ALGO_BCH_8BIT or NAND_LIB_ECC_ALGO_HAMMING_1BIT to initialize. Otherwise the NAND lib returns NAND_LIB_INVALID_PARAM.

Therefore I'm not sure how the ECC check can be disabled in my software. If I do not check the return value of the NAND lib init function, I guess it could lead to other failures.

Furthermore the function AM335X_Device_setECC is called in my code. These function also return an error if no ECC scheme is set. If I skip this function call, I'm not sure what happend with possible calls to the function pointers fxnEnable(), fxnDisable() of the NAND_ECC_Info_Handle in AM335X_ecc.c. These pointers will not be initialized if AM335X_Device_setECC is not called.

The function NAND_readPage does not perform any NULL pointer checks on the previous described functions pointers. Therefore it is also not possible to set the function pointers to NULL. Maybe I can write a dummy function and use this as function pointer. But nevertheless I'm not sure if this is possible way to disable the ECC of the NAND lib.

Are there any static code analysis werde made on the PDK source code? 

We do have static analysis for PDK source code, but it is not in the release. Let me look at the report and see what I find.

Hi,

I found a potential issue of using uninitialized array elements in function NandLibGpmcBchEccCheckAndCorrect():

        eccVal = (syndrome[12] | (syndrome[13] << 8) | (syndrome[14] << 16) |
                 (syndrome[15] << 24));

However, I've not yet been convinced that this would cause wrong error correction, because I don't fully understand how ECC is implemented. I'll continue to look into the code and the TRM.

Meanwhile, can you add some instrumentation to the code? For example, in SblNandReadFlash() in bootloader\src\sbl_nand.c, add a diagnostic message after NANDLibPageRead():

            if(NAND_LIB_PASS == status)
            {
                CONSOLEUtilsPrintf("\r\nReading Image From NAND");
            }
            else
            {
                CONSOLEUtilsPrintf("\r\nNANDLibPageRead() failed");
            }

In addition, add a few global debugging variables to track ECC stats in NAND lib. For example, in function NandLibGpmcBchEccCheckAndCorrect():

    if(ELM_ERR_LOC_PROCESS_STS_FAIL == result)
    {
        status = NAND_LIB_ECC_UNCORRECTABLE;
        
        // debugging counter - number of uncorrectable pages
        num_page_err_uncorrectable += 1; 
    }
    else
    {
        numOfErrs = ELMNumOfErrsGet(elmBaseAddr, 0);
        if(numOfErrs == 0)
        {
            status = NAND_LIB_PASS;
            
            // debugging counter - number of pages without any error
            num_page_no_err += 1; 
        }
        else
        {
            // debugging counter - number of pages with correctable errors
            num_page_err_correctable += 1;
            
            errNum = 0U;
             /* Get the error location and correct the same */
            for(i = 0; i < numOfErrs; i++)
            {
                errLoc = ELMErrLocBitAddrGet(elmBaseAddr, 0, errNum);
                if (errLoc >= (lastECCBit - 1))
                {
                   /* Error is at the Data bytes */
                    errBytePos = ((lastDataBit - 1) - errLoc) / 8;
                    /* Error Bit mask */
                    errBitMask = 0x1 << (errLoc % 8);
                    /* Toggle the error bit to make the correction. */
                    pData[errBytePos] ^= errBitMask;
                    status = NAND_LIB_ECC_ERR_CORRECTED;

                    // debugging counter - number of corrected errors
                    num_err_corrected += 1;
                }
                else
                {
                    /* Error is at the ECC bytes which we are not handling */
                    // debugging counter - number of errors in ECC bytes
                    num_err_unhandled += 1;
                }
                errNum++;
            }
        }
    }

Initialize these global variables to 0 in NANDLibGpmcInit(). Print them out in SBL, for example, after NANDLibPageRead() is called in SblNandReadFlash().

You can rebuild NAND lib using these commands:

C:\ti\processor_sdk_rtos_am437x_xx_xx_xx_xx>setupenv.bat
C:\ti\pdk_am437x_1_0_9\packages\ti\starterware>gmake clean libs PLATFORM=am43xx-evm PROFILE=release -s KW_BUILD=no
C:\ti\pdk_am437x_1_0_9\packages\ti\starterware>gmake libs PLATFORM=am43xx-evm PROFILE=release -s KW_BUILD=no

Hopefully with these instrumentation, we can understand better how well the NAND ECC works.

Thanks,

Jianzhong

Unfortunately I'm not able to clean the build

gmake failed with an error:

PS C:\ti\pdk_am437x_1_0_9\packages\ti\starterware> gmake clean libs PLATFORM=am43xx-evm PROFILE=release -s KW_BUILD=no
process_begin: CreateProcess(NULL, C:/ti/ccsv6/utils/cygwin/rm -f C:/ti/pdk_am437x_1_0_9/packages/ti/starterware/binary/dal/obj/am43xx-evm/a9/release/gcc/* C:/ti/pdk_am437x_1_0_9/packages/ti/starterware/binary/dal/obj/am43xx-evm/a9/release/gcc/.deps/* C:/ti/pdk_am437x_1_0_9/packages/ti/starterware/binary/dal/lib/am43xx-evm/a9/release/gcc/*, ...) failed.
make (e=2): Das System kann die angegebene Datei nicht finden.
C:/ti/pdk_am437x_1_0_9/packages/ti/starterware/build/makerules/common.mk:246: recipe for target 'clean' failed
gmake[1]: *** [clean] Error 2
Makefile:134: recipe for target 'dal_clean' failed
gmake: *** [dal_clean] Error 2

Hi,

Sorry, the right command to clean is: 

gmake libs_clean PLATFORM=am43xx-evm PROFILE=release -s KW_BUILD=no

I was able to build and here is my build log:

Microsoft Windows [Version 10.0.19042.928]
(c) Microsoft Corporation. All rights reserved.

C:\Users\a0869574>cd \ti\processor_sdk_rtos_am437x_4_02_00_09

C:\ti\processor_sdk_rtos_am437x_4_02_00_09>setupenv.bat
Optional parameter not configured : CG_XML_BIN_INSTALL_PATH
REQUIRED for xdc release build
Example: set CG_XML_BIN_INSTALL_PATH=C:/ti/cg_xml/bin
Optional parameter not configured : DOXYGEN_INSTALL_PATH
REQUIRED for xdc release build
Example: set DOXYGEN_INSTALL_PATH=C:/ti/Doxygen/doxygen/1.5.1-p1/bin
**************************************************************************
Environment Configuration:
    LIMIT_SOCS                : am437x
    LIMIT_BOARDS              : evmAM437x idkAM437x skAM437x
    PDK_INSTALL_PATH          : /ti/PD6FE3~1/packages
    C6X_GEN_INSTALL_PATH      : C:/ti/ti-cgt-c6000_8.2.2
    TOOLCHAIN_PATH_GCC        : C:/ti/gcc-arm-none-eabi-6-2017-q1-update
    TOOLCHAIN_PATH_A15        : C:/ti/gcc-arm-none-eabi-6-2017-q1-update
    TOOLCHAIN_PATH_A8         : C:/ti/gcc-arm-none-eabi-6-2017-q1-update
    TOOLCHAIN_PATH_A9         : C:/ti/gcc-arm-none-eabi-6-2017-q1-update
    TOOLCHAIN_PATH_M4         : C:/ti/ti-cgt-arm_16.9.3.LTS
    TOOLCHAIN_PATH_Arm9       : C:/ti/ti-cgt-arm_16.9.3.LTS
    TOOLCHAIN_PATH_EVE        : C:/ti/arp32_1.0.8
    CL_PRU_INSTALL_PATH       : C:/ti/ti-cgt-pru_2.1.5
    UTILS_INSTALL_DIR         : C:/ti/xdctools_3_50_03_33_core/bin
    HARDLIB_PATH              : C:/ti/gcc-arm-none-eabi-6-2017-q1-update/lib/gcc/arm-none-eabi/6.3.1/hard
    CROSS_TOOL_PRFX           : arm-none-eabi-
    XDC_INSTALL_PATH          : C:/ti/xdctools_3_50_03_33_core
    BIOS_INSTALL_PATH         : C:/ti/bios_6_52_00_12
    IPC_INSTALL_PATH          : C:/ti/ipc_3_47_00_00
    EDMA3LLD_BIOS6_INSTALLDIR : C:/ti/edma3_lld_2_12_05_30B
    NDK_INSTALL_PATH          : C:/ti/ndk_2_26_00_08
    IMGLIB_INSTALL_PATH       : C:/ti/imglib_c66x_3_1_1_0
    DSPLIB_INSTALL_PATH       : C:/ti/dsplib_c66x_3_4_0_0
    MATHLIB_INSTALL_PATH      : C:/ti/mathlib_c66x_3_1_1_0
    UIA_INSTALL_PATH          : C:/ti/uia_2_21_02_07
    IPC_PLATFORM: UNKNOWN
    IPC_ALT_PLATFORM:
    PROC_SDK_INSTALL_PATH     : C:/ti/processor_sdk_rtos_am437x_4_02_00_09
**************************************************************************
Changing to short name to support directory names containing spaces
current directory: C:/ti/processor_sdk_rtos_am437x_4_02_00_09
PROCESSOR SDK BUILD ENVIRONMENT CONFIGURED
**************************************************************************

C:\ti\processor_sdk_rtos_am437x_4_02_00_09>cd \ti\pdk_am437x_1_0_9\packages\ti\starterware

C:\ti\pdk_am437x_1_0_9\packages\ti\starterware>gmake libs_clean PLATFORM=am43xx-evm PROFILE=release -s KW_BUILD=no

C:\ti\pdk_am437x_1_0_9\packages\ti\starterware>dir binary\library\nandlib\lib\am43xx-evm\a9\release\gcc
 Volume in drive C is Windows
 Volume Serial Number is FCCB-4263

 Directory of C:\ti\pdk_am437x_1_0_9\packages\ti\starterware\binary\library\nandlib\lib\am43xx-evm\a9\release\gcc

05/12/2021  10:04 AM    <DIR>          .
05/12/2021  10:04 AM    <DIR>          ..
               0 File(s)              0 bytes
               2 Dir(s)  679,634,051,072 bytes free

C:\ti\pdk_am437x_1_0_9\packages\ti\starterware>gmake libs PLATFORM=am43xx-evm PROFILE=release -s KW_BUILD=no
# Compiling am43xx-evm:a9host:release:dal: i2c.c
# Compiling am43xx-evm:a9host:release:dal: uart.c
# Compiling am43xx-evm:a9host:release:dal: gpio.c
# Compiling am43xx-evm:a9host:release:dal: mcspi.c
# Compiling am43xx-evm:a9host:release:dal: gpmc.c
# Compiling am43xx-evm:a9host:release:dal: elm.c
# Compiling am43xx-evm:a9host:release:dal: qspi.c
# Compiling am43xx-evm:a9host:release:dal: edma.c
# Compiling am43xx-evm:a9host:release:dal: hs_mmcsd.c
# Compiling am43xx-evm:a9host:release:dal: dmtimer.c
# Compiling am43xx-evm:a9host:release:dal: epwm.c
# Compiling am43xx-evm:a9host:release:dal: vpfe.c
# Compiling am43xx-evm:a9host:release:dal: dss.c
# Compiling am43xx-evm:a9host:release:dal: dss_coefficients.c
# Compiling am43xx-evm:a9host:release:dal: wdt.c
# Compiling am43xx-evm:a9host:release:dal: ecap.c
# Compiling am43xx-evm:a9host:release:dal: tsc_adc_ss.c
# Compiling am43xx-evm:a9host:release:dal: rtc.c
# Compiling am43xx-evm:a9host:release:dal: dal_misc.c
# Compiling am43xx-evm:a9host:release:dal: dcan.c
# Compiling am43xx-evm:a9host:release:dal: cpsw.c
# Compiling am43xx-evm:a9host:release:dal: cpsw_ale.c
# Compiling am43xx-evm:a9host:release:dal: mdio.c
# Compiling am43xx-evm:a9host:release:dal: mailbox.c
# Compiling am43xx-evm:a9host:release:dal: pruss.c
#
# Archiving am43xx-evm:a9host:release:dal
#
# Compiling am43xx-evm:a9host:release:soc: armv7a/gcc/cp15.S
# Compiling am43xx-evm:a9host:release:soc: armv7a/gcc/exceptionhandler.S
# Compiling am43xx-evm:a9host:release:soc: armv7a/gcc/init.S
# Compiling am43xx-evm:a9host:release:soc: armv7a/gcc/pub2mon.S
# Compiling am43xx-evm:a9host:release:soc: soc.c
# Compiling am43xx-evm:a9host:release:soc: armv7a/startup.c
# Compiling am43xx-evm:a9host:release:soc: armv7a/gcc/cpu.c
# Compiling am43xx-evm:a9host:release:soc: am43xx/am43xx_chipdb.c
# Compiling am43xx-evm:a9host:release:soc: am43xx/hw_am43xx_chipdb.c
# Compiling am43xx-evm:a9host:release:soc: am43xx/hw_am43xx_chipdb_baseaddr.c
# Compiling am43xx-evm:a9host:release:soc: am43xx/hw_am43xx_chipdb_interrupt.c
# Compiling am43xx-evm:a9host:release:soc: am43xx/am43xx_prcm.c
# Compiling am43xx-evm:a9host:release:soc: am43xx/am437x/hw_prcm_data.c
# Compiling am43xx-evm:a9host:release:soc: am43xx/am437x/hw_prcm_data_names.c
# Compiling am43xx-evm:a9host:release:soc: cache_arm.c
# Compiling am43xx-evm:a9host:release:soc: mmu_arm.c
# Compiling am43xx-evm:a9host:release:soc: gic.c
# Compiling am43xx-evm:a9host:release:soc: armv7a/pl310.c
# Compiling am43xx-evm:a9host:release:soc: am43xx/am43xx_control.c
#
# Archiving am43xx-evm:a9host:release:soc
#
# Compiling am43xx-evm:a9host:release:board: board.c
# Compiling am43xx-evm:a9host:release:board: dcard.c
dcard.c: In function 'DCARDGetDCardList':
dcard.c:141:12: warning: 'pDCardList' may be used uninitialized in this function [-Wmaybe-uninitialized]
     return pDCardList;
            ^~~~~~~~~~
dcard.c: In function 'DCARDGetData':
dcard.c:247:20: warning: 'pDCardList' may be used uninitialized in this function [-Wmaybe-uninitialized]
         pDCardData = pDCardList[dCardId];
         ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
dcard.c: In function 'DCARDGetDevDCardId':
dcard.c:190:12: warning: 'dCardId' may be used uninitialized in this function [-Wmaybe-uninitialized]
     return (dCardId);
            ^
# Compiling am43xx-evm:a9host:release:board: platform.c
# Compiling am43xx-evm:a9host:release:board: pinmux.c
# Compiling am43xx-evm:a9host:release:board: am43xx/board_am43xx.c
# Compiling am43xx-evm:a9host:release:board: am43xx/dcard_am43xx.c
# Compiling am43xx-evm:a9host:release:board: am43xx/am43xx_gpevm.c
# Compiling am43xx-evm:a9host:release:board: am43xx/am43xx_evmsk.c
# Compiling am43xx-evm:a9host:release:board: am43xx/am43xx_idkevm.c
# Compiling am43xx-evm:a9host:release:board: am43xx/am43xx_eposevm.c
# Compiling am43xx-evm:a9host:release:board: am43xx/am43xx_custom.c
# Compiling am43xx-evm:a9host:release:board: am43xx/am43xx_gpevm_pinmux_data.c
# Compiling am43xx-evm:a9host:release:board: am43xx/am43xx_evmsk_pinmux_data.c
# Compiling am43xx-evm:a9host:release:board: am43xx/am43xx_idkevm_pinmux_data.c
# Compiling am43xx-evm:a9host:release:board: am43xx/am43xx_eposevm_pinmux_data.c
#
# Archiving am43xx-evm:a9host:release:board
#
# Compiling am43xx-evm:a9host:release:device: qspi_flash.c
# Compiling am43xx-evm:a9host:release:device: lcd_device.c
# Compiling am43xx-evm:a9host:release:device: pixcir_tsc.c
# Compiling am43xx-evm:a9host:release:device: camera_device.c
# Compiling am43xx-evm:a9host:release:device: enet_phy_device.c
# Compiling am43xx-evm:a9host:release:device: nand_device.c
# Compiling am43xx-evm:a9host:release:device: pmic_device.c
# Compiling am43xx-evm:a9host:release:device: pmic_device_tps65910.c
# Compiling am43xx-evm:a9host:release:device: pmic_device_tps65217.c
# Compiling am43xx-evm:a9host:release:device: pmic_device_tps65218.c
# Compiling am43xx-evm:a9host:release:device: clock_synthesizer.c
#
# Archiving am43xx-evm:a9host:release:device
#
# Compiling am43xx-evm:a9host:release:utils: console_utils_uart.c
# Compiling am43xx-evm:a9host:release:utils: console_utils.c
# Compiling am43xx-evm:a9host:release:utils: agraph.c
# Compiling am43xx-evm:a9host:release:utils: i2c_utils.c
# Compiling am43xx-evm:a9host:release:utils: ascii_utils.c
# Compiling am43xx-evm:a9host:release:utils: ramdiskutils.c
# Compiling am43xx-evm:a9host:release:utils: time_utils.c
# Compiling am43xx-evm:a9host:release:utils: dmtimer_utils.c
# Compiling am43xx-evm:a9host:release:utils: display_utils.c
display_utils.c: In function 'DISPLAYUtilsConfig':
display_utils.c:97:14: warning: comparison between pointer and integer
     if (NULL != frmBufAddr)
              ^~
# Compiling am43xx-evm:a9host:release:utils: display_utils_dss.c
#
# Archiving am43xx-evm:a9host:release:utils
#
# Compiling am43xx-evm:a9host:release:mmcsd_lib: mmcsd_lib.c
# Compiling am43xx-evm:a9host:release:mmcsd_lib: hsmmcsd_lib_port.c
#
# Archiving am43xx-evm:a9host:release:mmcsd_lib
#
# Compiling am43xx-evm:a9host:release:ff9b_lib: ./src/ff.c
# Compiling am43xx-evm:a9host:release:ff9b_lib: ./src/diskio.c
# Compiling am43xx-evm:a9host:release:ff9b_lib: ./port/fatfs_port.c
# Compiling am43xx-evm:a9host:release:ff9b_lib: ./port/fatfs_port_mmcsd.c
#
# Archiving am43xx-evm:a9host:release:ff9b_lib
#
# Compiling am43xx-evm:a9host:release:qspi_lib: qspi_lib.c
#
# Archiving am43xx-evm:a9host:release:qspi_lib
#
# Compiling am43xx-evm:a9host:release:nand_lib: nand_lib.c
# Compiling am43xx-evm:a9host:release:nand_lib: nand_lib_gpmc.c
#
# Archiving am43xx-evm:a9host:release:nand_lib
#

C:\ti\pdk_am437x_1_0_9\packages\ti\starterware>dir binary\library\nandlib\lib\am43xx-evm\a9\release\gcc
 Volume in drive C is Windows
 Volume Serial Number is FCCB-4263

 Directory of C:\ti\pdk_am437x_1_0_9\packages\ti\starterware\binary\library\nandlib\lib\am43xx-evm\a9\release\gcc

05/12/2021  10:06 AM    <DIR>          .
05/12/2021  10:06 AM    <DIR>          ..
05/12/2021  10:06 AM            20,088 libnand_lib.a
               1 File(s)         20,088 bytes
               2 Dir(s)  679,630,991,360 bytes free

C:\ti\pdk_am437x_1_0_9\packages\ti\starterware>

Hi Marc,

Have you been able to implement the instrumentations and determine if NAND ECC works as expected, or have you resolved this issue?

Thanks and regards,

Jianzhong

Hi,

I'm not able to implement the changes yet.
Last week we have decided to replace the NAND flash on our board with an QSPI NOR flash because we haven't seen a sustainable solution with the NAND flash. Since one month we try to find the problem with no effort.

Nevertheless I'm very unhappy with the TI PDK software package. This starts with the problem of the NAND ECC and ends with the description to create a new custom board in the PDK based on an am437 (I need it due to the new HW design with QSPI NOR Flash). I would expect more information about this. The PDK manual to add a custom board ends with the statement

"Currently the AM335x and AM437x board libraries re-use the board support that was used in legacy starterware software. AM335x and AM437x users will need to additionally modify build files in starterware to build their custom board library. Additional steps required for AM335x/AM437x will be added to this article soon in this section"

Since PDK version 04.03, this note is present in the manual. 2 Years later in version 06.03 no additional steps are added to the manual. This is also very poor.

If I'm honest, I wouldn't longer design a sitara chip on our boards. Maybe the chip has some advantages but the software package and the manual are not sufficient in my opinion.

For future development we will have a look at comparable other chips.

Thank you anyway.