This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3703 GPMC controller hangs/crashes after software writes page data to GPMC_NAND_DATA register.

Other Parts Discussed in Thread: AM3703

It appears that the AM3703 GPMC controller will hang/crash if software writes NAND page data to the GPMC_NAND_DATA register too quickly.

Observations:

- Once the GPMC controller has failed/hung, any attempt to read from the GPMC controller registers (e.g. 0x6e000000, the GPMC_REVISION register) will result in a data-abort exception being triggered in the processor.

- Once the GPMC controller has failed/hung, any attempt to access memory that was previously accessible on any of the GPMC chip-selects will now result in a data-abort exception being triggered in the processor.

- If the NAND GPMC timings are set to be as fast as the connected NAND device allows, only a short delay is required between each write to the GPMC_NAND_DATA register in order to prevent the GPMC controller from failing. If the NAND GPMC timings are set to be slower then a longer delay is required between each write to the GPMC_NAND_DATA register in order to prevent the GPMC controller from failing.

- When the code is modified so that the NAND page data is written to the NAND device using the NAND prefetch engine then the GPMC does not fail, regardless of the length of the configured NAND GPMC timings.

The current workaround will be to go with using the prefetch engine to write the page data.

I would like to understand why the GPMC controller can be made to hang by writing to the GPMC_NAND_DATA register too quickly, how to determine what the correct amount of delay needs to be when writing data repeatedly to the GPMC_NAND_DATA register, and/or if there is a better way to fix this problem.

  • The problem described above is another form of the problem described in the processor errata advisory 1.14. Contrary to the advisory, this failure occurs regardless of the GPMC_CONFIG[0].NANDFORCEPOSTEDWRITE setting. It also fails on the 255th write and not the 256th as stated in the advisory.

    Using the prefetch engine is the chosen solution.

    Advisory 1.14

    GPMC May Stall After 256 Write Accesses in NAND_DATA, NAND_COMMAND, or
    NAND_ADDRESS Registers


    Revision(s) Affected 1.2, 1.1 and 1.0


    Details

    The GPMC may stall if the following conditions are met:
    1. GPMC_CONFIG[0].NANDFORCEPOSTEDWRITE=1.
    2. Software performs more than 256 continuous write accesses in
    NAND_COMMAND_x, NAND_ADDRESS_x or NAND_DATA_x registers.
    3. GPMC_STATUS[0].EMPTYWRITEBUFFERSTATUS is always 0 (buffer not empty)
    during write accesses. This means the software has to write fast enough in GPMC
    registers in order to never have the write buffer empty.
    This mechanism is CS independent. If the software performs 128 write accesses in
    NAND_DATA_0 followed by 128 write accesses in NAND_DATA_1 then the bug will
    occur.


    Workaround(s)

    Accesses performed through the "prefetch and write posting engine" of the GPMC are
    not impacted by this limitation, and software should use this mechanism for the best
    performance.
    If the prefetch and write posting engine is not used, when
    GPMC_CONFIG[0].NANDFORCEPOSTEDWRITE=1 and after 255 write accesses in
    NAND_COMMAND_x, NAND_DATA_x or NAND_ADDRESS_x registers, the software
    has to wait until GPMC_STATUS[0].EMPTYWRITEBUFFERSTATUS=1 before sending
    the next 255 write accesses.