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.

3530 CBC errata - pbias_mmc1if connected as recommended hobbles SD card?

Other Parts Discussed in Thread: OMAP3530, OMAP-L137

Hi,

According to this: http://tiexpressdsp.com/index.php/Datasheet_Errata_for_OMAP35x_CBC_Package the pbias_mmc1 signal on ball N18 should not be connected.  Is this correct?  The Aug2009 omap3530.pdf datasheet recommends that this signal be connected to vdds_mmc1, but in our case this seems to lead to failure when trying to read the SD card.

 

I heard of and tested a workaround to get the SD card to mount in Linux by changing mmc->f_max in drivers/mmc/host/omap_hsmmc.c from 52000000 to a very low value such as 9000.  Without this workaround, and with pbias_mmc1 connected, I see the driver get the card parameters (speed, capacity), but produces timeout errors just after switching to high speed.

 

How painful.

,

John

  • The datasheet is wrong -- that's why I wrote the wiki page!  Correct, N18 should be a no-connect.

  • Hi Brad,

    Thanks for the confirmation.  I heard a rumor that the Aug2009 datasheet had corrected the error in the May2009 version, but I guess your page applies to both versions.

     

    ,

    John

     

  • Hi Brad,

    I want to chime in here and chastise TI in the strongest terms.  John and I are working on this project as consultants for a small high technology company.  He is the SW consultant and my company is consulting on the HW design and PCB layout.  We designed the PCB earlier this year based on the then latest documentation which included lots of errors - see my post:

    http://e2e.ti.com/forums/p/3548/13976.aspx#13976

    These errors had to be clarified before we could complete the PCB design.

     

    Then once we began testing of the prototype, we encountered a problem with accessing the NAND memory.  See my posts:

    http://e2e.ti.com/forums/p/10475/41051.aspx#41051

    http://e2e.ti.com/forums/t/10751.aspx

    This cost our client more than a week of two consultants working on the problem and will cost a board revision!

     

    Then this latest one with the error on even the latest release of the data sheet!  We were helped out on this problem by another forum member (not TI staff).

    Another week of wasted time and a definite board revision.  The modification to our prototype to verify that this will resolve our issue is definitely not something that can be done without taking the processor off the board and making modifications and then replacing it - not something that can be done without expensive equipment (back to the pcb assembly house for the modification) .

    We appreciate that there is a wiki page documenting it, but there is no reference on the OMAP3530 data page of the TI website to this wiki page, and TI customers (OMAP users) do not have the time to search all over the web for these little gems that clarify errors in the documentation.  I apprecaite that it may take TI time to release a new data sheet, but at least make sure that there are links to all the sources of information and surely it's not that difficult to issue frequent errata documents?

     

    Summing up, these errors have cost our client at least $ 15,000 considering our time, board modifications and a design revision and build of an extremely dense 12 layer board.  Finally, we are only one of many teams designing with this great processor, so I am sure that there are many other teams experiencing the same frustration over errors in the documentation.

     

    Howard V Robson

    President

    HRtronics, LLC

  • Howard,

    I'm very sorry to hear of your experiences.  We certainly strive to do much better.

    I completely agree that the wiki should not be a replacement for the datasheet.  We don't want to go that route.  I originally created that wiki page because I had a (2nd) customer using the CBC package and knew from the first experience that there were a bunch of mistakes.  My intent was for the wiki page to simply be a temporary band-aid.  I do not manage the datasheet so I cannot comment on why the update has taken so long.  However, I am told that a massive update is just around the corner (long overdue).  It's supposed to be out next week.

    I realize that does not help your situation in any way, but I wanted to at least let you know that we heard your message and are trying to fix things ASAP so that other customers don't have your same experience.

    Also, I think it's important to let you know that changes are in place to improve things in the future.  Right now our design and applications teams are stretched trying to cover the broad set of devices we've released recently (e.g. OMAP-L137/8, DM365, OMAP3530, etc).  Our next generation of devices currently being designed will have a lot more "common heritage" than the devices I just mentioned.  Not only will they be reusing a lot of pieces from this generation of devices, but also they will have more in common across the device families.  This will enable us to be much more efficient in terms of reusing documentation and software. Ultimately we hope this reuse will free up resources to improve the overall quality and the speed in which we can deliver enhancements and/or bug fixes.

    So, again, I apologize for your experience.  The OMAP3530 is an amazing device so I hope at the end of the day you're happy with your end product in spite of the headaches.  We hope you'll stay with TI processors for your future designs and we are working hard to make the next generation of processors better not only in features/performance, but also in your experience designing with it.

    Best regards,

    Brad Griffis
    TI Field Applications