• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 335 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Unable to Access Nand Flash on OMAP3530DCBC

Howard Robson
Intellectual 415 points

Other Parts Discussed in Thread: OMAP3530

We are in the prototype debug stage on a new board based on the OMAP3530DCBC (14mm x 14mm package) and we have a Micron MT29C2G24MAKLACG-6 IT installed on the CPU.  We believe that this is a valid part to use with the OMAP3530DCBC, are you able to confirm this?

We are able to access and load the bootloader and kernel in RAM and DRAM in the POP memory and run the kernel, but we are unable to access the NAND flash at all.  We have attempted to access it in three ways:

  1. Manually via a JTAG debugger issuing manual commands to access the NAND flash registers.  The manufacturer & device IDs comes back as 0x00
  2. Via the bootloader which also fails to get the manufacturer/device ID
  3. Via the kernel which also gives error messages indicating that the NAND flash is not functional.

Any help would be much appreciated.

  • 0
    Intellectual 415 points

    I have been researching this further and have discovered to my dismay that gpmc_nbe0_cle is not connected to a ball on the top of the CBC package device, which if my understanding is correct, results in the NAND flash not responding to any commands.  Please confirm my understanding.

  • 0 in reply to Howard Robson
    Intellectual 540 points

    Hi,

     

    Did you remember to put a strong pull-up (1K ohm) on the OMAP pin GPMC_WAIT0?  I've heard about people needing a new board rev because they forgot that part.

     

    I'm using the CBB package so I can only say that this resistor is the only external part I needed to access the NAND.  How strange it would be if the CBC package really doesn't connect the CLE line!  That Micron chip definitely needs it.  I hear the CBC section of the OMAP datasheets are riddled with errors though.  It may very well be connected.

  • 0 in reply to MikeW9894
    Intellectual 415 points

    Hi,

    Thank you for your response.

    It's very disappointing that no one from TI has responded to this post yet.

    I am interested in your observation that a 1k pullup is required, the EVM does not have one whereas the Beagle Board does, did you find this documented somewhere?

    As far as the CBC package is concerned, my thorough investigation indicates that CLE is not connected to the POP memory and must be routed on the PCB between the gpmc_nbe0_cle ball (K2) and a feed through ball on the bottom (AF12) which connects to ball AA10 on the top, and hence to the CLE pin on the Micron POP Memory.  This information was only clarified in "Table 2-30. CBC Package Feed-Through Balls" which was added to the August 2009 Revision of "OMAP3530/25 Applications Processor" (the data sheet - document # SPRS507E).

    ATTENTION TI, THIS LACK OF DETAILED INFORMATION HAS COST MY CLIENT MORE THAN A WEEK OF MY TIME AND WILL COST A BOARD REV TOO!!!  A HANDFUL OF OMAP3530DCBC SAMPLES WOULD GO SOME WAY TOWARDS APPEASING ME AND MY CLIENT?

    Finally, you are correct that the data sheet was riddled with errors as far as the CBC part is concerned, I personally submitted a list of many errors (on this forum - see http://e2e.ti.com/forums/p/3548/13976.aspx#13976) that were confirmed, and hopefully corrected by TI.

    Regards

  • 0 in reply to Howard Robson
    Intellectual 540 points

    Hi Howard,

    You're right that the EVM schematic doesn't have it but I thought that they added it later.  My schematics are pretty old as I don't use the EVM anymore.  I could be completely wrong and I can't find where I thought I read that but it seems like something that should have been added even if the part never gets populated.

    There is another topic where someone is having a similar problem: https://community.ti.com/forums/t/10265.aspx  A TI employee suggests the internal pull-up strength is very weak.

    Wow, that CBC package CLE problem is real if they have an actual document describing a workaround.  That's a shame.  As an early developer of this hardware I've learned many things before there was complete documentation available too.  So you don't have this workaround on your board or did you figure it out on your own in time?  If not, at least you have your solution but having to get new boards made and populated is going to be a pain.  I'd take the opportunity to test the rest of the board for any errors and benefit from doing two things at once. ;)