We're seeing occasional corruption of our Micron NAND with an AM3505 during power cycling. This is occurring with the system idle and the NAND being neither read or written during power loss. From the Micron datasheet (MP29F16G08)...
"It is recommended that the host drive WP# LOW during power-on until VCC is stable toprevent inadvertent PROGRAM and ERASE operations (see Device Initialization for additionaldetails)."
The TRM is very unclear how the "GPMC_NWP" (write protect) signal is controlled. Section 9.1.5.7 states ...
"The gpmc_nwp output pin value is controlled through the GPMC.GPMC_CONFIG[4] WRITEPROTECT bit,which is common to all CS."
However this bit is mentioned nowhere else - including in the register definition for GPMC_CONFIG4_i in section 9.1.7.2.13. Using the TI Android release we're observing the write protect goes inactive (high) immediately at power-up and stays there. (i.e. its inactive during power-down which may be an issue).
Questions:
1. How does the GPMC_NWP signal operate? Like a GPIO under firmware control, or hardware asserted framing write cycles to NAND?
2. Where can we find a description of the control bit(s) for this signal?
Thanks ... Jim Grimes
Hello Jim,
Jim Grimes Questions: 1. How does the GPMC_NWP signal operate? Like a GPIO under firmware control, or hardware asserted framing write cycles to NAND?
This pin is controled via bit 4 of the GPMC_CONFIG register not GPMC_CONFIG4. GPMC_CONFIG is a register common to all CS and is located at 0x6E000050 in the AM35x.
Jim Grimes 2. Where can we find a description of the control bit(s) for this signal?
The description for this bit is located in the GPMC Registers section of the TRM. Specifically Table 9-36 is for GPMC_CONFIG.
I have not seen anyone with this issue, but if you have access to the signal then maybe you can try externally controlling this line.
---------------------------------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question.---------------------------------------------------------------------------------------------------------
Best regards,Jeff
Same here. AM3715 processor, Micron MT29F4G16 NAND. We are finding that the flashing process via a Signum JTAG Jet sometimes fails verification. If you re-program it is usually successful. We can then boot the board and everything looks OK. Then at some point in the future on power up there is then a flash error. Probing with the JTAGJet it seems to be a single bit that is corrupted. That bit is then always corrupted. On different boards it is different bits that get corrupted.
I'll have a closer look at that pin state.
We're using Linux 2.6.32 psp 3.00.01.06
Ben,
We've been wrestling with this for awhile and believe its an issue with the TI code associated with ECC - we're in the process of using a pure SW solution and not the TI ECC calculation hardware. Here's a posting with a little more info ...
http://e2e.ti.com/support/embedded/linux/f/354/t/208906.aspx
Thanks for the feedback Jim. We'll keep an eye on that.
We are currently re-examining our choice of filing system on the NAND to make sure that is not contributing to the problem. We will look at the ECC issues at the same time.
Regards,
Ben