[beagleboard] [Q] Why I cannot mmap this region in 3.13 kernel?
I'm using BeagleBone Black. PRU example code PRU_memAccess_DDR_PRUsharedRAM in PRU sw package does not run on 3.13.6 kernel. And I found where it does stop working; mmap(0, 0x0FFF, PROT_WRITE | PROT_READ, MAP_SHARED, nFDMem, DDR_BASEADDR); where DDR_BASEADDR is 0x8000. This code works in old, 3.8.13 kernel. Do anyone let me know why I cannot mmap this area in new Kernel 3.13 -- 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/d/optout.
[beagleboard] Re: SPI 2 input wires
Screw the question above, I dug into the issue something more and now I wonder if it is even possible? According to the processor data sheet it uses a shift register, which is filled from one register for write and fills another register for read. Now can I reverse this direction on the write command so it fills both registers? -- 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/d/optout.
[beagleboard] BBB is out of stock in India, Anybody willing to sell BBB?
BBB is out of stock in India, Anybody willing to sell BBB? -- 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/d/optout.
[beagleboard] Re: [Q] Why I cannot mmap this region in 3.13 kernel?
I found solution. I have to use interface function provided by pruss (which I had not known). prussdrv_map_extmem This function solves my problem. On Friday, April 4, 2014 4:23:39 PM UTC+9, Sungjin Chun wrote: I'm using BeagleBone Black. PRU example code PRU_memAccess_DDR_PRUsharedRAM in PRU sw package does not run on 3.13.6 kernel. And I found where it does stop working; mmap(0, 0x0FFF, PROT_WRITE | PROT_READ, MAP_SHARED, nFDMem, DDR_BASEADDR); where DDR_BASEADDR is 0x8000. This code works in old, 3.8.13 kernel. Do anyone let me know why I cannot mmap this area in new Kernel 3.13 -- 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/d/optout.
[beagleboard] Re: Help with PRU on Beaglebone Black
I took care of that in the boot device tree. Forgot to specify that, sorry. It was in the overlay as well; I saw a comment somewhere that re-enabling it could cause problems so I took it out. On April 4, 2014 12:05:06 AM CDT, brise...@yahoo.com.au wrote: You need a fragment that targets the pruss. Have a look at the BB-BONE-PRU-00A0.dts example in the kernel source -- Sent from my phone. Please excuse brevity/typos -- 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/d/optout.
[beagleboard] Help me running my first Hello word application on beagle board
Hi friends i am using Beagle Board for the first tym and am new to the Linux environment, i am using Eclipse C/C++ IDE and am using MinGW cross compiler tool chain, i have successfully compiled the example hello word application using cross GCC, but after that i am completely lost, i have the project files, i have completely setup beagle board for angstrom environment but kindly guide me through further steps that i need to know. -- 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/d/optout.
[beagleboard] Re: Possible TPS65217C/Beaglebone Black Issue
Just to confirm this. From the TPS datasheet: OFF In OFF mode the PMIC is completely shut down with the exception of a few circuits to monitor the AC, USB, and push-button input. All power rails are turned off and the registers are reset to their default values. The I2C communication interface is turned off. This is the lowest-power mode of operation. To exit OFF mode one of the following wake-up events has to occur: • The push button input is pulled low. • The USB supply is connected (positive edge). • The AC adapter is connected (positive edge). To enter OFF state, set the OFF bit in the STATUS register to ‘1’ and thenpull the PWR_EN pin low. Please note that in normal operation OFF state can only be entered from ACTIVE state. Whenever a fault occurs during operation such as thermal shutdown,power -good fail, under voltage lockout, or PWR_EN pin timeout, all power rails are shut-down and the device goes to OFF state. The device will remain in OFF state until the fault has been removed and a new power-up event has occurred. When the brownout occurs, the unit goes in the off state and happily stays there. Apperently, the voltages subject to brownout recovering does not define as a positive edge. If anyone has a pretty solution for this, I'd be interested. Obviously, I can implement some kind of a watchdog that cuts the 5V altogether at some point but is there a SW or other 'easy' solution? On Tuesday, December 17, 2013 1:35:13 PM UTC+1, James Littlefield wrote: As I said in the original post, the bench supply is capable of more than 3A...far more than the BBB takes.I've duplicated the problem on 2 difference bench supplies and with multiple BBBs (ie the problem is not specific to one particular BBB board). J- On Friday, December 13, 2013 10:49:07 AM UTC-5, Kees k wrote: Hey, did you try another power supply? Probably the PS has problem supplying the current and drops voltage? Or there is a current limitation. I tried to reproduce by only connecting P9.5, P9.6 and P9.1 (GND) , but could not. On Tuesday, November 19, 2013 2:00:55 AM UTC+1, James Littlefield wrote: New to BBB but experienced with embedded systems. I'm working on a project using the BBB.Supplying +5V (up to 3A) directly to the pins on P9 from a quality bench supply. I've found that briefly switching the +5V supply OFF and then back on can pretty reliably leave the BBB in an odd state characterized by... a) No LEDs on b) Very little current drawn from supply (10mA or less) c) +5 present on P9.5 and P9.6 d) 0.687V on P9.7 and P9.8 ( should be SYS_5V ). e) P9.9 = 3.57V f) P9.10 = 0V I've found that once the system is in this mode no amount of pressing/holding the momentary BBB pushbuttons will get the system working again.Removing input power, waiting 10 sec or so, then restoring power will get things working again. Has anyone else seen this?It seems sort of like an issue with the TPS65217C chip but I've not found any reported errata on that part. Thanks Jim -- 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/d/optout.
[beagleboard] std thread multithreading performance very low
Hi, I use ubuntu build from this page
http://elinux.org/BeagleBoardUbuntuhttp://elinux.org/BeagleBoardUbuntu.
When I create multiple threads with infinite loop(with sleep 10ms) by
std::thread - cpu load is too high.
For example I create 21 thread like this
void test_class::foo()
{
while (true)
{
std::this_thread::sleep_for(std::chrono::milliseconds(10));
}
}
and got cpu load about 40% !!! I'm new in beagle bone, so my questions:
It's normal? What i do wrong?
--
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/d/optout.
Re: [beagleboard] Powering BeagleBone Black from Expansion Header
Hello I am trying to powering up the BBB through the header p9.. but when using connecting the 5V to pins 5 and 6 it is still not turning on automatically. I still need to press its power button. So how to make it turn on by just connecting the power? Best Regards On Wednesday, June 26, 2013 8:52:21 PM UTC+2, Juan C. wrote: You can check out this link with all the expansion header pins. http://circuitco.com/support/index.php?title=Cape_Expansion_Headers On Wednesday, June 26, 2013 1:44:58 PM UTC-5, YT wrote: Thanks for the quick reply. My board is revision A5A. Should I be concerned with the SRM Rev A5.3 or I should be looking at A5.6 which is referring to Production A5C? Because Table 12 is not the same between the two SRM. On Wednesday, June 26, 2013 2:38:41 PM UTC-4, Gerald wrote: It is called P9. The pins are 5 and 6. It is in the System Reference Manual. Table 12 Gerald On Wed, Jun 26, 2013 at 1:30 PM, YT yihta...@gmail.com wrote: Hi all, I've been reading the reference manual of Beaglebone black, and in page 42, it says The 5VDC rail is connected to the expansion header. It is possible to power the board via the expansion headers from an add-on card. Can anyone point out which expansion header the manual is referring to and where is it? And is there any difference than supplying power from the barrel jack (eg. max current allowable)? Thanks a lot. Regards, Yeo -- 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. -- 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/d/optout.
Re: [beagleboard] Powering BeagleBone Black from Expansion Header
Sounds like you are doing something wrong. Those pins connect to the power jack, so it should power the board. What else can you tell me about your setup? Gerald On Fri, Apr 4, 2014 at 7:27 AM, Mahammad cair...@gmail.com wrote: Hello I am trying to powering up the BBB through the header p9.. but when using connecting the 5V to pins 5 and 6 it is still not turning on automatically. I still need to press its power button. So how to make it turn on by just connecting the power? Best Regards On Wednesday, June 26, 2013 8:52:21 PM UTC+2, Juan C. wrote: You can check out this link with all the expansion header pins. http://circuitco.com/support/index.php?title=Cape_Expansion_Headers On Wednesday, June 26, 2013 1:44:58 PM UTC-5, YT wrote: Thanks for the quick reply. My board is revision A5A. Should I be concerned with the SRM Rev A5.3 or I should be looking at A5.6 which is referring to Production A5C? Because Table 12 is not the same between the two SRM. On Wednesday, June 26, 2013 2:38:41 PM UTC-4, Gerald wrote: It is called P9. The pins are 5 and 6. It is in the System Reference Manual. Table 12 Gerald On Wed, Jun 26, 2013 at 1:30 PM, YT yihta...@gmail.com wrote: Hi all, I've been reading the reference manual of Beaglebone black, and in page 42, it says The 5VDC rail is connected to the expansion header. It is possible to power the board via the expansion headers from an add-on card. Can anyone point out which expansion header the manual is referring to and where is it? And is there any difference than supplying power from the barrel jack (eg. max current allowable)? Thanks a lot. Regards, Yeo -- 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. -- 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/d/optout. -- 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/d/optout.
Re: [beagleboard] Re: Availability - how come nobody has any BeagleBone Black to sell?
Sounds like you might want to try flashing the new Debian images, even if you plan to run Ubuntu, just so you don't have to hold the boot button. On Friday, April 4, 2014, chris.j.d...@gmail.com wrote: Thanks! With the boot button it does successfully boot the Ubuntu image on the SD card. On Thursday, April 3, 2014 7:05:43 PM UTC-7, RobertCNelson wrote: On Thu, Apr 3, 2014 at 8:46 PM, chris@gmail.com wrote: Hi Robert, I'm not expecting any help/support from you on this, but here is some additional info you may find interesting. :-) a) I haven't tried contacting Seeed about this. I did look around for a contact at Embest and I found a forum (http://www.embest-tech.cn/community/forum.php) and a way to file a support ticket (http://www.embest-tech.com/ticket/index.php). The forum is all Chinese. I spent some time looking at google-translated posts there hoping to find the magic fix, without luck. I suppose the next step will be to file a support ticket about it. b) The Embest BBB I received has the AM3359. I noticed that the element 14 website says their Embest BBB has the AM3358. This may not be relevant to my Ubuntu boot issue, but it seemed interesting. c) When I boot the Embest BBB and watch the console output, it ends like this: Hit any key to stop autoboot: 0 gpio: pin 53 (gpio 53) value is 1 mmc0 is current device micro SD card found mmc0 is current device gpio: pin 54 (gpio 54) value is 1 SD/MMC found on device 0 reading uEnv.txt 1204 bytes read in 3 ms (391.6 KiB/s) Loaded environment from uEnv.txt Importing environment from mmc ... Running uenvcmd ... reading zImage 3669712 bytes read in 420 ms (8.3 MiB/s) reading initrd.img 3005004 bytes read in 345 ms (8.3 MiB/s) reading /dtbs/am335x-boneblack.dtb 24884 bytes read in 9 ms (2.6 MiB/s) Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid gpio: pin 55 (gpio 55) value is 1 ** File not found /boot/uImage ** But I can literally pop that same SD card out and put it in my BBB model A6 and it boots fine. I googled around for the error messages near the end, and got a few hits, but nothing that made sense to me as a workaround or explanation of why it fails on the Embest BBB. d) I did some poking around in U-Boot. The version says this: U-Boot 2013.04-rc1-14237-g90639fe-dirty (Apr 13 2013 - 13:57:11) arm-angstrom-linux-gnueabi-gcc (Linaro GCC 4.7-2013.02-01) 4.7.3 20130205 (prerelease) GNU ld (GNU Binutils) 2.22 Ouch! That's the original April 2013 release. Right before i submitted a patch to Koen to fix u-boot. My Ubuntu/Debian images rely on at-least Angstrom's 2013.06.20 release to be flashed to eMMC. So as long as you hold down the boot botton on power up, it should still default to the bootloader on the microSD card. Wow, that's such an old and broken default image.. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- 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.comjavascript:_e(%7B%7D,'cvml','beagleboard%2bunsubscr...@googlegroups.com'); . For more options, visit https://groups.google.com/d/optout. -- 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/d/optout.
Re: [beagleboard] Re: BBB + PREEMPT_RT
Sorry for my late answer. I have posted my kernel configuration on March 5. Please take a close look at my postings. You mave have to log in to google to see the attachments. Am Mittwoch, 19. März 2014 16:06:07 UTC+1 schrieb winglion: hi,quikcjack. I had been fallowing the topic for some dates. I plan to build a CNC controler with BBBlack. I want to get your kernel config to make a PREEMPT/PREEMPT_RT capable kernel too. whould you please seem me your kernel confiuration too? Thanks. 2014-03-19 16:47:58 ： It's really nice to see that there is some interest in having a PREEMPT/PREEMPT_RT capable kernel for the BBB. Well, it's relatively easy to compile a kernel. If you want to develop applications for the BBB you need a compiler/toolchain. So I guess you might have that already. The instructions to compile a kernel are explained at https://github.com/beagleboard/kernel/tree/3.8. I could send you my modified kernel configuration. You simply have the replace the original kernel configuration to create the PREEMPT capable kernel. Am Freitag, 14. März 2014 13:03:51 UTC+1 schrieb mhfar...@gmail.com: Hi thats great! Is that possible to have your compiled kernel for BBB? I would avoid the compiling process. Thanks a lot, Morteza Am Mittwoch, 26. Februar 2014 14:53:05 UTC+1 schrieb quik...@gmail.com: I have recently tested kernel 3.8.13-rt9 ( https://github.com/beagleboard/kernel/tree/3.8-rt) using git:// git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I am using Ubuntu 12.04.4. The load was created using stress –cpu 1 which generates a cpu load of about 100%. I then used cyclictest: root@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l100 -m -n -t1 -p99 -i400 -q # /dev/cpu_dma_latency set to 0us T: 0 ( 770) P:99 I:400 C:100 Min: 14 Act: 19 Avg: 18 Max: 132 uname -a reports: root@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux I am absolutely surprised that the result is looking that good. Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...@gmail.com: I am trying to figure out how to create a kernel for the BBB that supports PREEMPT_RT. It's kind of strange that the BBB's default kernel does not even have PREEMPT activated. Such a board doesn't fit to many embedded applications where we need at least some kind of determinism. It is even worse, that nobody seems to care about this problem. Contrary to that, the Raspberry PI's standard kernel has PREEMPT activacted from the very beginning. I have tested Robert Nelsons kernel 3.8.13-r9 ( https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have PREEMPT_RT activated by default. When doing so, it does not boot. But activating PREEMPT does work. However, development of this branch has stopped several months ago. The official source for RT Linux (3.8.13) has evolved since then. Meanwhile there's an rt17 patch set ( https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody give this a try? Does it work with the BBB? -- 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 javascript:. For more options, visit https://groups.google.com/d/optout. 在此邮件中未发现病毒。 检查工具：AVG - www.avg.com 版本：2013.0.3462 / 病毒数据库：3722/7208 - 发布日期：03/17/14 = = = = = = = = = = = = = = = = = = = = = = 致 礼！ winglion wing...@163.com javascript: 2014-03-19 -- 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/d/optout.
[beagleboard] Announcement: Power Cape (UPS)
Hello fellow enthusiasts, Please check out my Power Cape http://andicelabs.com/beaglebone-powercape/and let me know what you think. Yes, they are for sale but I would also value your feedback. Thanks, -Ron -- 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/d/optout.
Re: [beagleboard] Connection to Display doesn't work properly
Thanks Gerald, I tried another keyboard but the only key that seems to do something is the power off key. When i hit it - after like a minute or so - the following text appears on the screen: ngström ngström Distribution Beaglebone rom v2012.12 - Kernel 3.8.13 ebone login: this - like the beaglebone logo when i boot - appears on the top left part of the screen with, as you can see, the leftmost part missing. it appears for a second or so and then the beaglebone powers down. first i thought ok maybe the image is just not centered on the screen and in fact there would be something displayed after the beaglebone logo as well, but my display has a light wich is blinking when it gets no input so i know there is nothing to display. also i tried another display without any difference... -- 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/d/optout.
[beagleboard] Re: Debian boot - need a little help
On Thursday, April 3, 2014 9:47:31 PM UTC-6, Doug wrote: Why is ethernet not supported at initial boot? Hi Doug, The Debian images use wicd to start the network interfaces instead of the /etc/network/interfaces file to avoid a possible delay on boot when the BBB is not connected to a wired network. Unfortunately, at least in my experience, wicd is not set to enable the wired ethernet interface by default. I had to go into the wicd preferences page and check Always show wired interface, and then manually click the connect button on the wicd main screen. I only had to do this manually once, and ever since it has automatically re-connected the wired ethernet interface. The eth0 lines in my /etc/network/interfaces file are still commented out. HTH Dennis Cote -- 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/d/optout.
Re: [beagleboard] Connection to Display doesn't work properly
So when it powers down, is the power LED off? Gerald On Fri, Apr 4, 2014 at 10:17 AM, plutoda...@gmail.com wrote: Thanks Gerald, I tried another keyboard but the only key that seems to do something is the power off key. When i hit it - after like a minute or so - the following text appears on the screen: ngström ngström Distribution Beaglebone rom v2012.12 - Kernel 3.8.13 ebone login: this - like the beaglebone logo when i boot - appears on the top left part of the screen with, as you can see, the leftmost part missing. it appears for a second or so and then the beaglebone powers down. first i thought ok maybe the image is just not centered on the screen and in fact there would be something displayed after the beaglebone logo as well, but my display has a light wich is blinking when it gets no input so i know there is nothing to display. also i tried another display without any difference... -- 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/d/optout. -- 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/d/optout.
[beagleboard] Where did /sys/bus/iio/devices/iio\:device0/in_voltage[0-3]_raw go in saucy 3.13.X kernels?
Starting with a brand-new, out of the box BBB, I flashed it with *https://rcn-ee.net/deb/flasher/saucy/BBB-eMMC-flasher-ubuntu-13.10-2014-03-27-2gb.img.xz*which is of course the 3.8.13-bone40 kernel. The analog inputs were enabled once the # echo cape-bone-iio /sys/devices/bone_capemgr.*/slots command was given. The raw analog inputs were then readable at */sys/bus/iio/devices/iio\:device0/in_voltage[0-7]_raw*. However, after reading the inputs over a period of time, I started seeing errors reading the inputs, the Resource temporarily unavailable others have reported. Know the support for iio was updated in later kernels. I decided to update the kernel to see if that made a difference. Using the update script at *https://rcn-ee.net/deb/saucy-armhf/v3.13.8-bone8/install-me.sh*, I updated to the latest pre-built kernel. Now, I see analog inputs with no additional prodding required (perhaps the magic is now buried in the boot sequence?), but I don't see all the inputs, just 3: */sys/bus/iio/devices/iio\:device0/* *in_voltage[4-6]_raw*. What am I missing? Is there something I need to enable/disable in the /boot/uboot/uEnv.txt? Thanks. -- jda -- 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/d/optout.
Re: [beagleboard] Powering BeagleBone Black from Expansion Header
Hi Gerald.. many thanks for your support.. I revised the the cape design again and I found my mistake.. I was connecting power to pin 7 and 8 as well.. it seams like those pins should stay without any volts applied before the device start and supply them with 5V itself. Thanks.. On Friday, April 4, 2014 2:34:42 PM UTC+2, Gerald wrote: Sounds like you are doing something wrong. Those pins connect to the power jack, so it should power the board. What else can you tell me about your setup? Gerald On Fri, Apr 4, 2014 at 7:27 AM, Mahammad cai...@gmail.com javascript:wrote: Hello I am trying to powering up the BBB through the header p9.. but when using connecting the 5V to pins 5 and 6 it is still not turning on automatically. I still need to press its power button. So how to make it turn on by just connecting the power? Best Regards On Wednesday, June 26, 2013 8:52:21 PM UTC+2, Juan C. wrote: You can check out this link with all the expansion header pins. http://circuitco.com/support/index.php?title=Cape_Expansion_Headers On Wednesday, June 26, 2013 1:44:58 PM UTC-5, YT wrote: Thanks for the quick reply. My board is revision A5A. Should I be concerned with the SRM Rev A5.3 or I should be looking at A5.6 which is referring to Production A5C? Because Table 12 is not the same between the two SRM. On Wednesday, June 26, 2013 2:38:41 PM UTC-4, Gerald wrote: It is called P9. The pins are 5 and 6. It is in the System Reference Manual. Table 12 Gerald On Wed, Jun 26, 2013 at 1:30 PM, YT yihta...@gmail.com wrote: Hi all, I've been reading the reference manual of Beaglebone black, and in page 42, it says The 5VDC rail is connected to the expansion header. It is possible to power the board via the expansion headers from an add-on card. Can anyone point out which expansion header the manual is referring to and where is it? And is there any difference than supplying power from the barrel jack (eg. max current allowable)? Thanks a lot. Regards, Yeo -- 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. -- 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 javascript:. For more options, visit https://groups.google.com/d/optout. -- 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/d/optout.
Re: [beagleboard] Powering BeagleBone Black from Expansion Header
Glad you figured it out! Gerald On Fri, Apr 4, 2014 at 10:39 AM, Mahammad cair...@gmail.com wrote: Hi Gerald.. many thanks for your support.. I revised the the cape design again and I found my mistake.. I was connecting power to pin 7 and 8 as well.. it seams like those pins should stay without any volts applied before the device start and supply them with 5V itself. Thanks.. On Friday, April 4, 2014 2:34:42 PM UTC+2, Gerald wrote: Sounds like you are doing something wrong. Those pins connect to the power jack, so it should power the board. What else can you tell me about your setup? Gerald On Fri, Apr 4, 2014 at 7:27 AM, Mahammad cai...@gmail.com wrote: Hello I am trying to powering up the BBB through the header p9.. but when using connecting the 5V to pins 5 and 6 it is still not turning on automatically. I still need to press its power button. So how to make it turn on by just connecting the power? Best Regards On Wednesday, June 26, 2013 8:52:21 PM UTC+2, Juan C. wrote: You can check out this link with all the expansion header pins. http://circuitco.com/support/index.php?title=Cape_Expansion_Headers On Wednesday, June 26, 2013 1:44:58 PM UTC-5, YT wrote: Thanks for the quick reply. My board is revision A5A. Should I be concerned with the SRM Rev A5.3 or I should be looking at A5.6 which is referring to Production A5C? Because Table 12 is not the same between the two SRM. On Wednesday, June 26, 2013 2:38:41 PM UTC-4, Gerald wrote: It is called P9. The pins are 5 and 6. It is in the System Reference Manual. Table 12 Gerald On Wed, Jun 26, 2013 at 1:30 PM, YT yihta...@gmail.com wrote: Hi all, I've been reading the reference manual of Beaglebone black, and in page 42, it says The 5VDC rail is connected to the expansion header. It is possible to power the board via the expansion headers from an add-on card. Can anyone point out which expansion header the manual is referring to and where is it? And is there any difference than supplying power from the barrel jack (eg. max current allowable)? Thanks a lot. Regards, Yeo -- 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. -- 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/d/optout. -- 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/d/optout. -- 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/d/optout.
[beagleboard] Re: QT5 eglfs problem on embedded linux (TI am355x evm starter kit)
On Thursday, April 3, 2014 12:35:38 AM UTC-6, Morix Dev wrote: I haven't do anything special about SGX drivers, using the stock one provided by TI pre-built images. Do you think that I should recompile somehow SGX drivers? Why? Thanks for the info. I didn't notice you were using the TI EVM and their 3.2 kernel. I though you were using the BBB with one of the newer 3.8 kernels. My understanding is that the SGX drivers don't work with the current BBB kernels. Dennis Cote -- 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/d/optout.
[beagleboard] Compile problem
I am trying to compile some code in the latest debian release. I got the latest source by using -- wget https://raw.github.com/gkaindl/beaglebone-ubuntu-scripts/master/bb-get-rcn-kernel-source.shhttps://www.google.com/url?q=https%3A%2F%2Fraw.github.com%2Fgkaindl%2Fbeaglebone-ubuntu-scripts%2Fmaster%2Fbb-get-rcn-kernel-source.shsa=Dsntz=1usg=AFQjCNGfskw3YeISuBv6xklle5atCCworg chmod +x bb-get-rcn-kernel-source.sh ./bb-get-rcn-kernel-source.sh uname-r on my system returns - 3.8.13-bone43 The compile and install goes without errors but the modules are placed in /lib/modules/3.8.13 and not /lib/modules/3.8.13-bone43 where all of the system modules reside. When I try to start the application it tells me there are no modules. What is wrong? The script does download the kernel and bone43 patches. -- 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/d/optout.
Re: [beagleboard] Re: Here is the BeagleBone Debian (beta) image you want to test
I have the same problem... You could solve it? El dimecres 2 d’abril de 2014 8:09:52 UTC+2, mbba...@gmail.com va escriure: What is the problem with the default kernel? That wifi doesn't work good in general, that it doesn't connect to unsecured networks, that Wicd is buggy and will freeze up the BeagleBone? I went ahead and updated the kernel. I am now able to connect to secured and unsecured networks using the Adafruit dongle. I had limited success with the netgear wna1100 which definitely does NOW work better than the Adafruit dongle. The UWN200 also came in the mail today, but the BeagleBone was unable to detect it. Is it supposed to run out of the box on the newer images, or do I have to implement some sort of fix? The adafruit dongle shows up as wlan0, and the netgear shows up as wlan1. I read that the uwn200 is supposed to show up as ra0, but when I switch wicd accordingly, it still doesn't detect the dongle, and there's no wifi when I run ifconfig. Also, is there any way to log into lxde using the root user? That would save me and my students some typing and other problems (such as opening certain files with leafpad, etc.). Again, thanks for all the work you're putting into this image. You're ironing out a lot of the kinds that my students have been stumbling over. -- 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/d/optout.
Re: [beagleboard] Re: SPI 2 input wires
From: Rafael Fiebig-Bindner r.fiebig.bind...@gmail.com Reply-To: beagleboard@googlegroups.com Date: Friday, April 4, 2014 at 2:42 AM To: beagleboard@googlegroups.com Subject: [beagleboard] Re: SPI 2 input wires Screw the question above, I dug into the issue something more and now I wonder if it is even possible? According to the processor data sheet it uses a shift register, which is filled from one register for write and fills another register for read. Now can I reverse this direction on the write command so it fills both registers? You cannot. You have to use two SPI interfaces if you want to receive simultaneously or you have to use on SPI with two chip selects and then alternate the receiving of each channel. The way SPI works is that it shifts bits out of MOSI and simultaneously shifts bits into MISO. Regards, John -- 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/d/optout. -- 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/d/optout.
Re: [beagleboard] Re: Possible TPS65217C/Beaglebone Black Issue
From: ad...@mxm-upgrade.com Reply-To: beagleboard@googlegroups.com Date: Friday, April 4, 2014 at 2:17 AM To: beagleboard@googlegroups.com Subject: [beagleboard] Re: Possible TPS65217C/Beaglebone Black Issue Just to confirm this. From the TPS datasheet: OFF In OFF mode the PMIC is completely shut down with the exception of a few circuits to monitor the AC, USB, and push-button input. All power rails are turned off and the registers are reset to their default values. The I2C communication interface is turned off. This is the lowest-power mode of operation. To exit OFF mode one of the following wake-up events has to occur: EURO The push button input is pulled low. EURO The USB supply is connected (positive edge). EURO The AC adapter is connected (positive edge). To enter OFF state, set the OFF bit in the STATUS register to OE1¹ and then pull the PWR_EN pin low. Please note that in normal operation OFF state can only be entered from ACTIVE state. Whenever a fault occurs during operation such as thermal shutdown, power-good fail, under voltage lockout, or PWR_EN pin timeout, all power rails are shut-down and the device goes to OFF state. The device will remain in OFF state until the fault has been removed and a new power-up event has occurred. When the brownout occurs, the unit goes in the off state and happily stays there. Apperently, the voltages subject to brownout recovering does not define as a positive edge. If anyone has a pretty solution for this, I'd be interested. Obviously, I can implement some kind of a watchdog that cuts the 5V altogether at some point but is there a SW or other 'easy' solution? Unfortunately no, there is no software solution since the processor has no power. You have to use a power supply monitor/controller with a state machine to deal with this issue. This type of circuit is normally included a small energy reserve (battery or supercaps) so that the OS has time to close open files and prevent file system corruption during power fail issues. Normally, any power supply interruptions initiates an orderly shutdown of the OS. When the processor finally halts, power is removed from the PMIC. When power is available, power is applied to the PMIC and everything powers up normally. There are several corner cases that must be considered, such as power interruption during power up phase or power available during power down phase. A simple state machine takes care of these corner cases. Overall, the circuitry includes several voltage regulators (input buck convertor, output boost convertor), energy balance (supercaps), battery charger (battery), and a state machine (8 bit micro or my preference - GreenPAK). Regards, John On Tuesday, December 17, 2013 1:35:13 PM UTC+1, James Littlefield wrote: As I said in the original post, the bench supply is capable of more than 3A...far more than the BBB takes.I've duplicated the problem on 2 difference bench supplies and with multiple BBBs (ie the problem is not specific to one particular BBB board). J- On Friday, December 13, 2013 10:49:07 AM UTC-5, Kees k wrote: Hey, did you try another power supply? Probably the PS has problem supplying the current and drops voltage? Or there is a current limitation. I tried to reproduce by only connecting P9.5, P9.6 and P9.1 (GND) , but could not. On Tuesday, November 19, 2013 2:00:55 AM UTC+1, James Littlefield wrote: New to BBB but experienced with embedded systems. I'm working on a project using the BBB.Supplying +5V (up to 3A) directly to the pins on P9 from a quality bench supply. I've found that briefly switching the +5V supply OFF and then back on can pretty reliably leave the BBB in an odd state characterized by... a) No LEDs on b) Very little current drawn from supply (10mA or less) c) +5 present on P9.5 and P9.6 d) 0.687V on P9.7 and P9.8 ( should be SYS_5V ). e) P9.9 = 3.57V f) P9.10 = 0V I've found that once the system is in this mode no amount of pressing/holding the momentary BBB pushbuttons will get the system working again.Removing input power, waiting 10 sec or so, then restoring power will get things working again. Has anyone else seen this?It seems sort of like an issue with the TPS65217C chip but I've not found any reported errata on that part. Thanks Jim -- 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/d/optout. -- 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
Re: [beagleboard] std thread multithreading performance very low
From: dmitriy.kostro...@gmail.com
Reply-To: beagleboard@googlegroups.com
Date: Friday, April 4, 2014 at 5:17 AM
To: beagleboard@googlegroups.com
Subject: [beagleboard] std thread multithreading performance very low
Hi, I use ubuntu build from this page http://elinux.org/BeagleBoardUbuntu
http://elinux.org/BeagleBoardUbuntu.
When I create multiple threads with infinite loop(with sleep 10ms) by
std::thread - cpu load is too high.
For example I create 21 thread like this
void test_class::foo()
{
while (true)
{
std::this_thread::sleep_for(std::chrono::milliseconds(10));
}
}
and got cpu load about 40% !!! I'm new in beagle bone, so my questions: It's
normal? What i do wrong?
My guess is that if you increased the sleep time, the cpu load would
decrease significantly. The time to schedule each thread is probably
significant compared to your sleep time, so when you run 21 threads, the
processor is doing nothing more than rescheduling your threads. The cpu load
of 40% sounds about right.
Regards,
John
--
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/d/optout.
--
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/d/optout.
Re: [beagleboard] Re: QT5 eglfs problem on embedded linux (TI am355x evm starter kit)
From: Dennis Cote denn...@harding.ca Reply-To: beagleboard@googlegroups.com Date: Friday, April 4, 2014 at 8:47 AM To: beagleboard@googlegroups.com Cc: morix@gmail.com Subject: [beagleboard] Re: QT5 eglfs problem on embedded linux (TI am355x evm starter kit) On Thursday, April 3, 2014 12:35:38 AM UTC-6, Morix Dev wrote: I haven't do anything special about SGX drivers, using the stock one provided by TI pre-built images. Do you think that I should recompile somehow SGX drivers? Why? Thanks for the info. I didn't notice you were using the TI EVM and their 3.2 kernel. I though you were using the BBB with one of the newer 3.8 kernels. My understanding is that the SGX drivers don't work with the current BBB kernels. I have SGX working with Robert Nelson¹s V3.12 kernel and I believe that SGX support was recently added to his V3.8 kernel. Regards, John Dennis Cote -- 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/d/optout. -- 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/d/optout.
Re: [beagleboard] Where did /sys/bus/iio/devices/iio\:device0/in_voltage[0-3]_raw go in saucy 3.13.X kernels?
As far as I know, the default am33x-boneblack.dtb which is read from kernel during boot does have only 3 pin addresses for analog inputs, you can modify this by referring TRM or other dts files. I do not have my file now sorry, I cannot post here. Sent from my iPad On Apr 5, 2014, at 12:36 AM, John Amidon jami...@narwhalgroup.com wrote: Starting with a brand-new, out of the box BBB, I flashed it with https://rcn-ee.net/deb/flasher/saucy/BBB-eMMC-flasher-ubuntu-13.10-2014-03-27-2gb.img.xz which is of course the 3.8.13-bone40 kernel. The analog inputs were enabled once the # echo cape-bone-iio /sys/devices/bone_capemgr.*/slots command was given. The raw analog inputs were then readable at /sys/bus/iio/devices/iio\:device0/in_voltage[0-7]_raw. However, after reading the inputs over a period of time, I started seeing errors reading the inputs, the Resource temporarily unavailable others have reported. Know the support for iio was updated in later kernels. I decided to update the kernel to see if that made a difference. Using the update script at https://rcn-ee.net/deb/saucy-armhf/v3.13.8-bone8/install-me.sh, I updated to the latest pre-built kernel. Now, I see analog inputs with no additional prodding required (perhaps the magic is now buried in the boot sequence?), but I don't see all the inputs, just 3: /sys/bus/iio/devices/iio\:device0/in_voltage[4-6]_raw. What am I missing? Is there something I need to enable/disable in the /boot/uboot/uEnv.txt? Thanks. -- jda -- 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/d/optout. -- 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/d/optout.
Re: [beagleboard] Re: Possible TPS65217C/Beaglebone Black Issue
Thanks for confirming my original observation! I think John raises some important points regarding power handling...some of which go well beyond the context of my original post.As he suggests a software solution is not an option ...unless you have some other platform to run the software on!For the application about which I originally posted, we are less concerned with power fail warnings, writing system state to nv memory, etc so the only real issue for us is that when power is available we want the Bone to run!Unfortunately, if there is a power disturbance that is enough to trigger the TPS65217C into shutdown you can have perfectly good power for a month and the system will never come back on. I worked around this by doing something like the following 1. Find a watchdog chip that will run off the raw 5V supply available and connect the watchdog ICs input/tickler to some digital signal which tends to be available an an early stage in the boot process.The horizontal/vertical sync lines for an external LCD are available on the P8/P9 headers and usually start toggling pretty soon.You also need to make sure that the watchdog IC can be configured for a fairly long timeout period and that its reset output is also longish (seconds). 2. Wire the RESET output of the watchdog IC to a power switch so that if the watchdog times out it will cut power to the BBB.There are some fairly inexpensive USB host power switch ICs that can handle 2A so these are sometimes appropriate. Another option, if you are stepping down a raw input voltage to 5V for the bone and the dc/dc converter IC has a shutdown input, you can use the watchdog IC to turn off the dc/dc converter. In this case you have to generate an independent 5V supply just for the watchdog IC ...but a simple linear regulator can do that for low cost given the small current required. With this configuration if your TPS65217 gets stuck in the shutdown state the watchdog will eventually time out, cut 5V power, and (hopefully) kick the TPS back into normal operation.One thing to watch for however, is that with the TPS in shutdown mode, there is very little current drawn from the 5V supply so it will take some time for the 5V supply to decay to 0V even with the power source removed.This is why you need a watchdog IC with a long reset output pulse width. Maybe the TPS65217D will have some additional internal logic which makes all this unnecessary! Jim- On Fri, Apr 4, 2014 at 3:58 PM, John Syn john3...@gmail.com wrote: From: ad...@mxm-upgrade.com Reply-To: beagleboard@googlegroups.com Date: Friday, April 4, 2014 at 2:17 AM To: beagleboard@googlegroups.com Subject: [beagleboard] Re: Possible TPS65217C/Beaglebone Black Issue Just to confirm this. From the TPS datasheet: OFF In OFF mode the PMIC is completely shut down with the exception of a few circuits to monitor the AC, USB, and push-button input. All power rails are turned off and the registers are reset to their default values. The I2C communication interface is turned off. This is the lowest-power mode of operation. To exit OFF mode one of the following wake-up events has to occur: * The push button input is pulled low. * The USB supply is connected (positive edge). * The AC adapter is connected (positive edge). To enter OFF state, set the OFF bit in the STATUS register to '1' and thenpull the PWR_EN pin low. Please note that in normal operation OFF state can only be entered from ACTIVE state. Whenever a fault occurs during operation such as thermal shutdown,power -good fail, under voltage lockout, or PWR_EN pin timeout, all power rails are shut-down and the device goes to OFF state. The device will remain in OFF state until the fault has been removed and a new power-up event has occurred. When the brownout occurs, the unit goes in the off state and happily stays there. Apperently, the voltages subject to brownout recovering does not define as a positive edge. If anyone has a pretty solution for this, I'd be interested. Obviously, I can implement some kind of a watchdog that cuts the 5V altogether at some point but is there a SW or other 'easy' solution? Unfortunately no, there is no software solution since the processor has no power. You have to use a power supply monitor/controller with a state machine to deal with this issue. This type of circuit is normally included a small energy reserve (battery or supercaps) so that the OS has time to close open files and prevent file system corruption during power fail issues. Normally, any power supply interruptions initiates an orderly shutdown of the OS. When the processor finally halts, power is removed from the PMIC. When power is available, power is applied to the PMIC and everything powers up normally. There are several corner cases that must be considered, such as power interruption during power up phase or power available during power down phase.
Re: [beagleboard] Re: Possible TPS65217C/Beaglebone Black Issue
As a general comment, whenever people are talking about edge detection, there's an implied timing specification of the sharpness and/or quality of that edge---there's an implied slope and setup/hold times, and your actual V(t) may be such that it is not seen as a valid, recognized positive edge. Specifically, the voltage rise could be too fast or too slow, or the voltage dip is too shallow, or there are ringing/bouncing artefacts that lock out the edge detector. On Fri, Apr 4, 2014 at 5:17 AM, ad...@mxm-upgrade.com wrote: Just to confirm this. From the TPS datasheet: OFF In OFF mode the PMIC is completely shut down with the exception of a few circuits to monitor the AC, USB, and push-button input. All power rails are turned off and the registers are reset to their default values. The I2C communication interface is turned off. This is the lowest-power mode of operation. To exit OFF mode one of the following wake-up events has to occur: * The push button input is pulled low. * The USB supply is connected (positive edge). * The AC adapter is connected (positive edge). To enter OFF state, set the OFF bit in the STATUS register to '1' and then pull the PWR_EN pin low. Please note that in normal operation OFF state can only be entered from ACTIVE state. Whenever a fault occurs during operation such as thermal shutdown, power-good fail, under voltage lockout, or PWR_EN pin timeout, all power rails are shut-down and the device goes to OFF state. The device will remain in OFF state until the fault has been removed and a new power-up event has occurred. When the brownout occurs, the unit goes in the off state and happily stays there. Apperently, the voltages subject to brownout recovering does not define as a positive edge. If anyone has a pretty solution for this, I'd be interested. Obviously, I can implement some kind of a watchdog that cuts the 5V altogether at some point but is there a SW or other 'easy' solution? On Tuesday, December 17, 2013 1:35:13 PM UTC+1, James Littlefield wrote: As I said in the original post, the bench supply is capable of more than 3A...far more than the BBB takes.I've duplicated the problem on 2 difference bench supplies and with multiple BBBs (ie the problem is not specific to one particular BBB board). J- On Friday, December 13, 2013 10:49:07 AM UTC-5, Kees k wrote: Hey, did you try another power supply? Probably the PS has problem supplying the current and drops voltage? Or there is a current limitation. I tried to reproduce by only connecting P9.5, P9.6 and P9.1 (GND) , but could not. On Tuesday, November 19, 2013 2:00:55 AM UTC+1, James Littlefield wrote: New to BBB but experienced with embedded systems. I'm working on a project using the BBB.Supplying +5V (up to 3A) directly to the pins on P9 from a quality bench supply. I've found that briefly switching the +5V supply OFF and then back on can pretty reliably leave the BBB in an odd state characterized by... a) No LEDs on b) Very little current drawn from supply (10mA or less) c) +5 present on P9.5 and P9.6 d) 0.687V on P9.7 and P9.8 ( should be SYS_5V ). e) P9.9 = 3.57V f) P9.10 = 0V I've found that once the system is in this mode no amount of pressing/holding the momentary BBB pushbuttons will get the system working again.Removing input power, waiting 10 sec or so, then restoring power will get things working again. Has anyone else seen this?It seems sort of like an issue with the TPS65217C chip but I've not found any reported errata on that part. Thanks Jim -- 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/d/optout. -- 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/d/optout.
