OMAP4460 Schematics/Layout questions (SYSBOOT, WK GPIOs and TMP102 location)...

Hello Soren,

1) I'm assuming your question is about 4460 GPIO_WK[xx] pins. You are free to use them as a generic GPIO if needed. If you want OMAP system to wakeup from a low power state then you should use the GPIO's that are in the wakeup domain. There is no drawback of using such GPIO for general purpose applications.

2) For SYSBOOT pins, we highly recommend you use external PU/PD simply because these are system critical pins. Please note that SYSBOOT[0:5] have internal PD (of around 18K) only and SYSBOOT[6:7] does not have any internal PU/PD. Configuration of SYSBOOT[0:5] determines your system boot option and order and we recommend you use a strong external PU (e.g.; 3.3K) when you need to connect one the SYSBOOT[0:5] pins high. While it is ok to connect these pins directly to GND if these pins need to be low, using an external resistor gives you more design flexibility in case you decide to change system boot option or order later on.

3) Do not leave the SYSBOOT pin floating and soley rely on internal PD for those pins that are intended to be low. This is because the internal PD value can vary due to silicon process variation. It is best to connect these to GND externally.

4) The recommended distance is from the edge of the package, orientation is not critical, but placment is so you will have an accurate reading.

Regards

Shaheen

Hi Shaheen,

Sorry for my late reply on this...

1) OK - Thanks for the clarification. I think what however still isn't 100% clear to me is if/when this would be needed running i.e. http://www.omappedia.org/wiki/4AI.1.4-P1_OMAP4_Icecream_Sandwich_Release_Notes. As written originally I would i.e. assume it needed for waking up on an incoming WiFi package in case device is in idle, but WiFi IRQ signal on Blaze is routed to a normal GPIO => Apparently not needed for this use case.

Only WK GPIO actually used as input GPIOs on Blaze are for battery removal, which I guess is for an emergency shutdown reason, but in case phone is already in very deep sleep this actually might not be that necessary, so the actual usage/advantage/need for WK GPIOs are unfortunately still pretty weak to me...

Do you have any other examples/use cases from Blaze or any other example platform there the WK functionality is actually used/needed in order to achieve the lowest possible power mode?

2) Wrt SYSBOOT pins I know their functionality and agree that they of cause should be set correct as having them wrong is bad. This being said I still prefer to save PCB routing space if allowed and possible :-) My main question was mainly if you were 100% sure that they are at no point in time during reset/boot up set as outputs for just any very short time, which would short them to any hardwired VIO or GND in case of being hardwired instead fo being through a 3K3 resistor as recommended... Can you please confirm (just to be 100% sure) if/that this won't be a problem? In later SW (xloader, etc) I will of cause make sure they are always set as inputs.... :-)

3) I have heard this recommendation before as well. A question the other way: In case internal pull can't be judged strong enough to achieve valid operation, are there any plans for making it stronger in the future? After all having a pull which isn't considered "valid" is in my world just waste => Better get it removed or making it stronger :-)

4) Not sure I follow you 100% on this? TMP102 is 1.2x1.6mm nominal => Center will be 0.2mm offset dependent on orientation unless it's from OMAP edge to TMP102 center, but in this case TMP102 and OMAP will be places very close together?

I hope you can help be by clarifying above items - Best regard and thanks
  Søren

Hello, Soren;

1) Section 25.2.2, Table 25-1, Figure 25-4, 5 give a good representation of the GPIO configuration.  The GPIO1 block, containing gpio(0..31), is part of the WAKEUP power domain(see Chapter 3, Power Management).  So, any of the gpio(0..31) are good choices for wakeup interrupt generation(see Ch 25.4.6.2).  In particular, the gpio_wk balls of gpio(0..31) connect directly to L4, and thus only gpio_wk(0..10) and gpio_wk(29..31) can be used to generate a direct wake-up event.

2)  The reset and reset release state of Sysboot(0..5) is "L" => High Impedance with an active pulldown resistor.  Sysboot(6..7) is "Z" => High impedance.  The reset release Mode is 0; Sysboot(x), Input.  As Shaheen as said, it is a good idea to use external PU/PD for flexiblity.    If you wish to assume the risk, and assuming that they will always be inputs (PU/PD can be disabled in the xloader), there is no reason that you cannot connect directly to GND and VIO.  (but not our recommendation! :-)  )

3)  No silicon updates to the 4460 are planned.

3)  Essentially, place as close as possible (the center on the bottom side would be preferred).  The distance is not calibrated, so this will need to be taken into account when taking a reading for Tj.    It is EXTREMELY important that there be many solid GND plane connections to the OMAP4460 for both thermal and signal integrity reasons.

Kind regards,

Hi Michael,

Thanks for your feedback. Please hereby find my comments:

1) I agree to all of this stated here, but it unfortunately still doesn't answers my main question which is: "How is this _wk feature used/needed SW wise using a standard TI Android ICS release"? One thing is what silicon can do. Another is how this is supposed to be used together with the "full system" including SW and other peripheral chips.

Using again Blaze as an example, i.e. WLAN_IRQ signal is routed to GPIO_53 (which isn't in GPIO1 block => No WK feature). From this I conclude that Blaze either:

• Can't enter lowest possible power mode (where wk is needed) and simultaneously have WiFi enabled expecting to receive WiFi interrupts
• Having WiFI enabled will anyway (due to what ever other reason) prevent OMAP from entering lowest possible power mode => Not a problem to use a normal GPIO
• Last but not least it could as well be a bad design on Blaze which could and should be optimized on an end product, although I doubt it?

"Problem" with _wk pins are that several of them are i.e. in SIM-power domain (or muxed on sysboot pins) => You would need to keep SIM domain active to use them, so using these is a little more complex than using free "normal" GPIOs. In case WK feature therefore in reality isn't used for anything in any "practical SW" (but more is a HW thing) I would prefer avoiding them, which is why I'm looking for any practical purposes where they make a difference combined with official SW builds, and for now I haven't been able to find any unless Blaze isn't as optimized as it could be? I hope the question is clearer this time?

2) Great that you can confirm my understanding of SYSBOOT settings, as I can't find anything in TRM/DM preventing hard wiring either (although I know it isn't official recommendation). As said I know which SYSBOOT setting I want, and I prefer optimizing routing space compared to flexibility - Main thing for me is to ensure that I don't make any HW/Silicon-risk due to any undocumented feature :-). I however think one compromise (to account for the undocumented case if/that hard wiring would be bad) is to bundle the pins in groups (HIGH/LOW) and then connect the group to VIO/GND through a single resistor. This would give the benefit that you would never short a ball directly to a supply, but still only basically need routing of 2 signals (as the SYSBOOT pins are located closely in the chip ball out) as opposed to the full set = 8 signals ...

3) Great - Thanks for info => Latest silicon is ES1.1 which as well is that is in Mass Production - Correct/Right?

4) TMP102 - OK - Understood that it was calibrated as it was described in that great detail in the DM - I think I now got the point - Thanks. Wrt GND planes and VIAs I fully agree both in terms of thermal and in terms of SI reasons :-)

Best regards and thanks again - Help and support is as always highly appreciated
   Søren

We still have an open item about how WK domain GPIOs are used in current TI Android ICS releases, as I think WK pin assignment/ usage on Blaze seems a bit "strange" to me? I hope someone from TI SW team will be able to get back to me on this one, as I bet I'm not the only one being "confused" about this and the item has been open for quite some time now...

Best regards and thanks in advance
  Søren

Hi Friends ,

 Me too doing similar design based on OMAP4 , I need to implement the Power management similar to the Mobile phone , when user press the Power button system should go to sleep , if the system is active , and if user keep pressing the Power button system should go to shutdown . How I can Implement this , could any one help me in this

Regards,

Aneesh

Hi Aneesh,

First: Please stop hijacking threads, and please open a new thread for this question instead, as it's not related to open HW items above... :-)

Second: All the functionality of the power button you requested above (sleep, wake up, switch off dialog) is pure SW and all already standard implementation in Android...

Best regards - Good luck
  Søren

Soren,

In the current TI Android ICS releases (ie, 4AI.1.4-P1), the following WK GPIOs are used for our Blaze Tablet reference platform:

-          gpio_wk6 (msecure for TWL6030/6032 write access)

-          gpio_wk30 (USB EHCI power)

They are defined in /arch/arm/mach-omap2/board-44xx-tablet.c.

Regards,
Gina 

Hi Gina,

Yes - That I know. What I however don't understand is if/why any of them aren't used for waking up i.e. on incoming WiFi or 3G data or similar external event? In that way I would assume you could have the OMAP fully powered/clocked down in case of a device being idle in your pocket,, and still being able to wake-up when someone try to address it externally one way or another?

As I see it Blaze doesn't fully utilize the capabilities of the WK pin on OMAP, but it might be that it's unrealistic to believe that you could switch off IO domains (other than WAKEUP) when a device is in idle?

As such what I'm trying to understand is if/how wake-up domain is (supposed to be) utilized by TI SW as it to me seems that it isn't and that I therefore as well can use any normal GPIO as a GPIO in the WK domain for any interrupt source, as an Android system based on TI ICS release apparently anyway never will reach this low a power state (where WK contra normal GPIO is important) while being idle?

Can you confirm this or did I miss anything? I hope that my question/confusion is clear? Otherwise please let me know and I will see what more I can do to clarify?

Best regards and thanks again in advance
   Søren

Hi Michael,

Thanks for all your diffing around in TRM. I had seen the table but missed the note below it and the paragraph on WK-ring. I think it answers my question, as stuff beginning to settle and make sense, but I will need to read it in a bit more detail to be 100% sure I get every piece :-)

Only item which however still puzzles me a bit it what is the use of the WK GPIOs in case a random GPIO can be used for waking up the system? Only for the special case where you can switch of the 1V8 IO supply and run a very limited system only having the WKUP domain powered?

Anyway as such not a big matter, but just though to ask as it will be nice to get to know the thoughts behind it "once and for all" to get this thread 100% properly closed in case you can get (easily) access to any of the designers knowing the reasoning behind having the few special WK GPIOs...

Secondly I would like to apologize for my very long waited feedback on this, but I have been sidetracked due to other tasks and the summer, but now I'm back :-) - Again: Sorry for the delay on my feedback...

Thanks a lot for your help - Highly appreciated 
  Søren