Follow your finding on the unexpected TPS65217C behavior, I patched the 
tps65217 driver with irq handling. The 3.2 kernel does not handle 
nNMI/PMIC_INT interrupt; the 3.8 kernel does. I placed printk in the 
interrupt handler and got the same result as yours. The PMIC_INT was issued 
every 2 seconds which is caused by the USBI flag in the TPS65217C interrupt 
register. 

[  217.095367] tps65217_irq: USB power status change
[  217.259338] tps65217_irq: USB power status change
[  219.096801] tps65217_irq: USB power status change
[  219.256103] tps65217_irq: USB power status change
[  221.094177] tps65217_irq: USB power status change
[  221.262084] tps65217_irq: USB power status change
[  223.095611] tps65217_irq: USB power status change
[  223.259033] tps65217_irq: USB power status change
[  225.097045] tps65217_irq: USB power status change
[  225.255859] tps65217_irq: USB power status change
[  227.094024] tps65217_irq: USB power status change
[  227.262908] tps65217_irq: USB power status change
[  229.095489] tps65217_irq: USB power status change

I paste part of the log above. The actual timing of USBI status change is 
at a inteval of 0.16, 1.84 seconds interval. I lowered the CPU frequency 
from 1G to 300MHz. I don't observe any change in this timing.

I also loaded an Angstrom (3.8 kernel) on the BBB. By inspecting the 
interrupts (cat /proc/interrupts), it seems that 3.8 kernel does NOT have 
the same behavior. I will be checking the PMIC configuration difference 
between 3.2 and 3.8 kernel.

Also, if USB is connected to the mini USB connector. This behavior is going 
away.

Thanks.



On Wednesday, November 27, 2013 3:30:16 AM UTC-5, ance...@gmail.com wrote:
>
> I have soldered a 15 ohm power resistor between SYS_5V (P9.8) and DGND 
> (P9.2). This increases SYS_5V load by 333mA. After three days of test I can 
> confirm that random reboot frequency have not changed so it seems that the 
> current load is not the problem.
>
> BTW: I have found and unexpected TPS65217C behavior related to the USB 
> power detection. I have posted this issue at 
> http://e2e.ti.com/support/arm/sitara_arm/f/791/t/305879.aspx
>
> Best regards.
>
>
> El jueves, 21 de noviembre de 2013 20:52:39 UTC+1, lisarden escribió:
>>
>> I don't think that connecting a USB cable reduces the current load to the 
>> PMIC because there are two different switches in the power path for the AC 
>> and USB inputs. They can't be opened at the same time because the PMIC 
>> can't be sure that two sources have the same voltage. If both switches are 
>> opened then current can flow backwards to a weaker source IMHO. Probably 
>> it's really a ground issue as Gerald said before
>>
>>
>> 2013/11/21 Maxim Podbereznyy <lisa...@gmail.com>
>>
>>> I doubt the issue is connected with the floating nRESET pin. If you have 
>>> a look at the "Figure 1. Global State Diagram" at page 16 the PMIC always 
>>> waits for 1 second after a *FAULT*. Please read the following:
>>>
>>> FAULT = UVLO || OTS || PGOOD low|| PWR_EN pin not asserted within 5s of 
>>> Wakeup event.
>>> If no battery is present, OVP on AC input also leads to OFF mode. With 
>>> battery present, device switches
>>> automatically from AC to BAT if AC is>6.5V and back to AC when voltage 
>>> recovers to<6.5V.
>>> Device will remain in RESET state for at least 1s.
>>>
>>> UVLO = Under Voltage Lockout
>>> OTS = Over Temperature Shutdown
>>> OVP = Over Voltage Protection
>>>
>>>
>>> 2013/11/21 Lei Wang <lei...@gmail.com>
>>>
>>>> Thanks for sharing the captured trace. It is very helpful. I wonder if 
>>>> you could further zoom in on the falling edge. I am really interested in 
>>>> the order of SYS_5V voltage drop and SYS_RESETn voltage drop. 
>>>>
>>>> Also I noticed in TPS65217 datasheet, if the nRESET pin is pulled low, 
>>>> there will be a minimum 1s delay before the PMIC returns to Active state 
>>>> (page 15). The nRESET pin is not connected on BBB. It should have an 
>>>> internal pull-up resistor of 100k (supposed to an alway-on supply). TI's 
>>>> engineer may have better insight on this.
>>>>
>>>> I did some measurement on the current consumptions of different Kernels 
>>>> (showing below). As you can tell 3.8 Kernels do draw less current.
>>>>
>>>>  *image*
>>>>  
>>>> Angstrom (3.8 kernel)
>>>>  
>>>> Android(3.8 kernel)
>>>>  
>>>> Android(3.2 kernel)
>>>>   
>>>> *clock (Hz)*
>>>>  
>>>> 1G
>>>>  
>>>> 1G
>>>>  
>>>> 1G
>>>>   
>>>> *Display type*
>>>>  
>>>> HDMI
>>>>  
>>>> HDMI
>>>>  
>>>> HDMI
>>>>   
>>>> *current (mA)*
>>>>  
>>>> 290
>>>>  
>>>> 300
>>>>  
>>>> 375
>>>>  
>>>>
>>>>
>>>>
>>>> On Thursday, November 21, 2013 7:53:20 AM UTC-5, Antonio Cebrián wrote:
>>>>
>>>>> I have captured a BBB A5B random reboot with the oscilloscope (see 
>>>>> attached image).
>>>>>
>>>>>   Ch1 → VDD_3V3B (P9.4)
>>>>>   Ch2 → VDD_5V (P9.6)
>>>>>   Ch3 → SYS_5V (P9.8)
>>>>>   Ch4 → SYS_RESETn (P9.10)
>>>>>
>>>>> This confirms that the random reboot is produced by 1 second SYS_5V 
>>>>> fall.
>>>>>
>>>>> Best regards.
>>>>>
>>>>>
>>>>>
>>>>> 2013/11/20 <ance...@gmail.com>
>>>>>
>>>>> After reading the Jakub thread the new conclusion is that this seems 
>>>>>> to bee a hardware related problem (related to PMIC). This may explain 
>>>>>> why 
>>>>>> changing kernel or changing CPU frequency doesn't resolve the problem 
>>>>>> (only 
>>>>>> minimizes it). 
>>>>>>
>>>>>>  I will test the Jakub hardware workaround (external MOSFET) in my 
>>>>>> own system.
>>>>>>
>>>>>> About your questions:
>>>>>>
>>>>>> - I'm using a BBB A5B with a custom cape that includes: a LVDS 
>>>>>> converter for a LCD, a resistive touchscreen, a MAX3232 converter for a 
>>>>>> RS232 port and a buffer for some push buttons.
>>>>>>
>>>>>> - I have recompiled the TI 3.2 kernel (from LINUXEZSDK-BONE v06.00) 
>>>>>> to include the proper LCD initialization.
>>>>>>
>>>>>> - The system runs a Qt application with CPU load below 10%. The CPU 
>>>>>> works all time at default 1 GHz frequency.
>>>>>>
>>>>>> - I have two identical systems under test and I got one reboot each 2 
>>>>>> to 3 hours but some days both systems work without reboots for 10 to 15 
>>>>>> hours. 
>>>>>>
>>>>>>
>>>>>> Best regards.
>>>>>>
>>>>>>
>>>>>> El miércoles, 20 de noviembre de 2013 19:33:26 UTC+1, Lei Wang 
>>>>>> escribió:
>>>>>>
>>>>>>> It seems that Angstrom 3.8 kernel is more robust. But I couldn't 
>>>>>>> confirm that it will resolve the random reboot issue. I haven't done 
>>>>>>> long 
>>>>>>> term testing. I remember seeing someone also has problem with it. It 
>>>>>>> could 
>>>>>>> be just that kernel is more optimized which draws less current.
>>>>>>>
>>>>>>> Limiting the CPU frequency only made BBB random reboot less often. I 
>>>>>>> can confirm that. I believe it is also related to the current draw. The 
>>>>>>> slower the clock the less the power is drawn from PMIC.
>>>>>>>
>>>>>>>  By plugging in both DC power and USB cable (mini connector), it 
>>>>>>> increases the PMIC current capacity. PMIC has two power paths (AC->SYS 
>>>>>>> and 
>>>>>>> USB->SYS), which reduces the stress placed on a single path (AC->SYS). 
>>>>>>> I am 
>>>>>>> suspecting the PMIC thermal shutdown causes the random reboot. Please 
>>>>>>> take 
>>>>>>> a look at the other thread I mentioned in a previous post. Jakub 
>>>>>>> suggested 
>>>>>>> putting in a Mosfet to bypass VDD_5V to SYS_5V path after boot up. 
>>>>>>>
>>>>>>> BTW, could you tell me what is your setup besides using TI prebuild 
>>>>>>> kernel? Are you driving a HDMI display or a LCD cape? what else do you 
>>>>>>> connect to the BBB?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Lei
>>>>>>>
>>>>>>>
>>>>>>> On Wednesday, November 20, 2013 12:28:36 PM UTC-5, 
>>>>>>> ance...@gmail.comwrote:
>>>>>>>>
>>>>>>>> I confirm that I have the same issue with a BBB A5B using TI 3.2 
>>>>>>>> kernel.
>>>>>>>>
>>>>>>>> After reading the full thread I guess that the posible workarounds 
>>>>>>>> are:
>>>>>>>>
>>>>>>>> - Using Angstrom 3.8 kernel.
>>>>>>>> - Powering the BBB from USB.
>>>>>>>> - Limiting the CPU frequency.
>>>>>>>>
>>>>>>>> Can anybody confirm it?
>>>>>>>>
>>>>>>>> Best regards.
>>>>>>>>
>>>>>>>>
>>>>>>>> El martes, 12 de noviembre de 2013 15:37:07 UTC+1, Lei Wang 
>>>>>>>> escribió:
>>>>>>>>>
>>>>>>>>> I have similar issue. I have (2) versions of BBB (A5A and A5C). 
>>>>>>>>> They both randomly reboot themselves while I am running TI prebuilt 
>>>>>>>>> BBB 
>>>>>>>>> android image (from a couple hours to ten to fifteen hours). When I 
>>>>>>>>> plug in 
>>>>>>>>> the USB (DC is still powered) for logging with logcat, the reboot 
>>>>>>>>> issue 
>>>>>>>>> seems to disappear.
>>>>>>>>>
>>>>>>>>> I don't have problem with BBB Angstrom image (based on 3.8 
>>>>>>>>> kernel). I don't have problem with Andrew Henderson's android image 
>>>>>>>>> (based 
>>>>>>>>> on 3.8 kernel) either.
>>>>>>>>>
>>>>>>>>> Another issue is that when I run TI BBB android image, the clock 
>>>>>>>>> randomly jumps forward 2^17 seconds. This happens on both of my BBB 
>>>>>>>>> boards. 
>>>>>>>>> The problem goes away when I run Angstrom or Andrew's android. 
>>>>>>>>>
>>>>>>>>> I suspect it has something to do with the processor, DDR3 (BBB: 
>>>>>>>>> AM3359 1GHz + 512MB DDR3), the configuration, or apply workaround of 
>>>>>>>>> errata. We have an AM335x EVM kit (AM3359 720MHz + 256MB DDR2). I 
>>>>>>>>> also 
>>>>>>>>> loaded TI prebuilt android image. I have run it for several months. 
>>>>>>>>> It is 
>>>>>>>>> rock solid. I never had problem with it.
>>>>>>>>>
>>>>>>>>> Here are the links to my other posts in regarding to this issue.
>>>>>>>>> https://groups.google.com/forum/#!category-topic/beagleboard
>>>>>>>>> /advanced/5qSJ4dQdar4
>>>>>>>>> http://e2e.ti.com/support/embedded/android/f/509/t/297726.aspx<http://www.google.com/url?q=http%3A%2F%2Fe2e.ti.com%2Fsupport%2Fembedded%2Fandroid%2Ff%2F509%2Ft%2F297726.aspx&sa=D&sntz=1&usg=AFQjCNFNp-bsLCgqLguXpYlSGbA7sSnOaQ>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thursday, October 31, 2013 6:32:16 PM UTC-4, Illutian Kade 
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> And now the board won't power on from the Debug Port, but will 
>>>>>>>>>> form the DC jack. At this point I'm about to say "fuck this shit".
>>>>>>>>>>
>>>>>>>>>> On Saturday, October 5, 2013 7:12:06 AM UTC-4, Illutian Kade 
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Has anyone experienced their BBB rebooting at random?
>>>>>>>>>>>
>>>>>>>>>>> It was running solid for two days straight and this morning it 
>>>>>>>>>>> just keeps rebooting. This last time the power light even went out.
>>>>>>>>>>>
>>>>>>>>>>> *I've checked and all cables are secured. The entire setup is 
>>>>>>>>>>> running of a PFC UPS; so power fluctuations shouldn't be an issue.
>>>>>>>>>>>
>>>>>>>>>>> *CPU doesn't seem to be under load; ~20% utilization
>>>>>>>>>>>
>>>>>>>>>>> *I've done a total unplug-let-sit and restart
>>>>>>>>>>>
>>>>>>>>>>> *From what logs I've looked through (message and kern.log) the 
>>>>>>>>>>> board does a total restart and loses even the date (goes form Oct 5 
>>>>>>>>>>> to Aug 
>>>>>>>>>>> 26)
>>>>>>>>>>>
>>>>>>>>>>> *I've not made any changes other than unplugging the Syba 
>>>>>>>>>>> C-media USB sound card and transferring it back to my main computer 
>>>>>>>>>>> after I 
>>>>>>>>>>> wake up (BBB is doubling as a media player)
>>>>>>>>>>> -This has worked for a grand total of 'uptime' 2 days and some 
>>>>>>>>>>> odd hours with no issues.
>>>>>>>>>>>
>>>>>>>>>>> ..I really hope this doesn't mean the board is defective :\
>>>>>>>>>>>
>>>>>>>>>>> OS: Debian Wheezy (BBB-eMMC-flasher-debian-7.1-2013-08-26.img)
>>>>>>>>>>> Power: AC Adapter 
>>>>>>>>>>> (http://www.adafruit.com/products/276<http://www.google.com/url?q=http%3A%2F%2Fwww.adafruit.com%2Fproducts%2F276&sa=D&sntz=1&usg=AFQjCNEvq3gmvP89fzs-F5q-Np8TKs0UdA>)
>>>>>>>>>>>  
>>>>>>>>>>> [specifically recommended by Adafruit]
>>>>>>>>>>>
>>>>>>>>>>
>>>>>  -- 
>>>> For more options, visit http://beagleboard.org/discuss
>>>> --- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "BeagleBoard" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to beagleboard...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>
>>>
>>>
>>> -- 
>>> LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
>>>  Company - http://www.linkedin.com/company/mentorel
>>> Facebook - https://www.facebook.com/mentorel.company
>>>  
>>
>>
>>
>> -- 
>> LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
>> Company - http://www.linkedin.com/company/mentorel
>> Facebook - https://www.facebook.com/mentorel.company
>>  
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to