P1013 Bus monitor timeout

Showing results for 
Search instead for 
Did you mean: 

P1013 Bus monitor timeout

Contributor II

I'm getting a Bus Monitor timeout error when attempting to read from NAND flash on my P1013-based board.

So address I/O[0..7] pins on the flash part (MT29F8G08ADBDAH4-IT) tied to P1013 LB_AD[0..7].

This is the set-up, to make the NAND chip accessible:

// LAWBAR6 - Local Bus NAND

    //   bit 8 - 31 = 0xEFF00000 - base addr

    MM_LAWBAR6 = 0x000eff00;


    // LAWAR6

    //   bit 0 = 1 - enable window

    //   bit 7-11 = 00100 - Local Bus

    //   bit 26-31 = 001111 64k - size

    MM_LAWAR6 = 0x8040000f;

    // CS0 - NAND Flash    

    //   BR0 base address at 0xEFF00000, port size 8 bit, FCM

    eLBC_BR0 = 0xEFF00C21;

    //   OR0 64KB flash size, FCM (large page NAND Flash)

    eLBC_ORf0 = 0xFFFF07AE;

    // Flash Timeout: 8,388,608 cycles of LCLK

    eLBC_FMR = 0x0000F000;

And this is an attempt to read the signature from the NAND part:

  eLBC_FCR = 0x90000000;   // Cmd Reg: "READ ID " cmd, no-op, no-op, no-op

    eLBC_MDRf = 0x00000000;     // Data Reg: set flash offset as zero

    eLBC_FPARl = 0x00000000;    // Flash Page Reg: set page #0

    eLBC_FIR = 0x43BBBBB0; // Instruct Reg: stream of 4-bit opcodes
    eLBC_FMR = 0x0000F002;   // Mode Reg: exec cmds in FIR on next LSOR write
    eLBC_LSOR = 0x00000000;  // trigger actions on NAND on Bank 0


    wait(200);   // NOTE: wait time can be reduced by clocking the eLBC at higher speed

    eLBC_NAND_Data = eLBC_MDRf;    // copy read value to variable for return

When I do that write to LSOR, I get:

    LTESR == 0x00000001

    LTEATR == 0x10040801

These indicate a Bus Monitor timeout on read.  Also, I do not see activity on CS0 when viewed with a logic analyzer.

Any thoughts as to why I'm getting the timeouts?


0 Kudos
4 Replies

NXP Employee
NXP Employee

"Bus monitor timeout" is 0x80000000 in LTESR.  0x00000001 is "FCM command completion event".  I don't think it should cause an error in LTEATR (but note that erratum eLBC 1 says that LTEATR can be unreliable) or the lack of activity on the bus, but one obvious problem I see is that you're issuing the RS command (0xB) five times (in addition to using MDR for UA (0x3)), when there are only four AS fields in MDR.  The command sequence that we use in Linux for READID is CM0, UA, RBW (0x43E00000) with the ID data going into SRAM.

You're also supposed to wait for LTESR[CC] rather than waiting a fixed amount of time.

Erratum eLBC-A001 says that LBCR[BMTPS] needs to be set to 0xf, and LBCR[BMT] needs to be set to 0; are you doing that?

0 Kudos

Contributor II

Thanks for the reply, Scott.

1. Yes, my head was on backward re the LTESR bits.

2. Can point me to the P1013 eLBC errata you referenced?

3. Regarding the 5 reads, I used " NAND flash read identification command sequence example" (from doc

P1022RM / Rev. 2, 04/2013) as an example.  Plus, my NAND part describes 5 reads to get the full value of the ReadID command.

4. As I see the problem even when single-stepping from the code, I don't think I have a timing issue.  Though you are surely right that a dumb wait is not the way to go.

5. Yes at the time of triggering the read, I have LBCR == 0x4000000f (apparently that '4', in a reserved field, is stuck on).

I changed the FIR from 0x43BBBBB0 to 0x43E00000 per your recommendation, but still am reading zero from MDRf where there should be a NAND device ID.  The change did result in FECC{0,1,2,3} being set to 0x80000000 on attempted read; I don't think I've seen that behavior before.

Thanks again.

0 Kudos

NXP Employee
NXP Employee

I don't see the errata sheet for this chip on the public website, unfortunately.  I suggest filing an official support request, or talking to your sales contact if you have one.  You can find an example of the LBCR workaround being applied in U-Boot and Linux (though, you already have the correct value there).

I don't know why the example in the manual has five reads.  If you read five times the last byte will be discarded, and the NAND chip shouldn't care if you read fewer bytes than it has available (and not all chips claim to want five reads).  But I tried that sequence (both with and without the extra 0xB) on a similar chip and it successfully read the ID into MDR.  I saw the same spurious error data in LTEATR.  So, the remaining mystery is why you're not seeing activity on the bus.  Do any other eLBC accesses work (at least to the extent of generating bus activity)?

0x43E00000 places the data in the SRAM buffer, not in MDR.  If you use that, you'll need to set the desired number of bytes to read in FBCR.  If you leave FBCR as zero, it will try to do a full-page read with ECC correction (which is why you saw FECC change) which will fail because the ID data has no ECC.

0 Kudos

NXP TechSupport
NXP TechSupport

P1013 Errata document is not available publicly, but the same errata item "eLBC-A001" is present in other public documents, for example in MPC8308 device errata:


As long as this document is public, I guess I can copy the contents here

eLBC-A001: Simultaneous FCM and GPCM or UPM operation may erroneously trigger bus monitor timeout

Description: When the FCM is in the middle of a long transaction, such as NAND erase or write, another transaction on the GPCM or UPM triggers the bus monitor to start immediately for the GPCM or UPM, even though the GPCM or UPM is still waiting for the FCM to finish and has not yet started its transaction. If the bus monitor timeout value is not programmed for a sufficiently large value, the local bus monitor may time out. This timeout corrupts the current NAND Flash operation and terminate the GPCM or UPM operation.

Impact: Local bus monitor may time out unexpectedly and corrupt the NAND transaction.

Workaround: Set the local bus monitor timeout value to the maximum by setting LBCR[BMT] = 0 and LBCR[BMTPS] = 0xF. Fix plan: No plans to fix

0 Kudos