By the way when I connected 5vdc directly to the additional ldo ic I have grounded Vusb as well and the board worked without any reboot issue during 1 week. Probably I was in a wrong direction thinking that it was totally depending on the current overload at tps65217. One of the ideas was about the USB grounding and I combined all solutions at once
Will test only grounded Vusb to check your hypothesis 03 дек. 2013 г. 21:32 пользователь "Lei Wang" <[email protected]> написал: > 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, [email protected] 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 <[email protected]> >>> >>>> 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 <[email protected]> >>>> >>>>> 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 <[email protected]> >>>>>> >>>>>> 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, >>>>>>>> [email protected] wrote: >>>>>>>>> >>>>>>>>> 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 [email protected]. >>>>> 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 [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
