RE: [beagleboard] Strange behavior of value returned from PRU with RPMSG

[Graham Stott]

Try changing the %n in the print statement to print out a 32 bit value. I think 
you will see that it is an address in the PRU address space.

 

Graham 

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Walter Cromer
Sent: Tuesday, April 20, 2021 10:34 AM
To: BeagleBoard 
Subject: [beagleboard] Strange behavior of value returned from PRU with RPMSG

 

I am using a Beaglebone Black and C to read analog inputs with PRU0 and return 
the data to a host program using RPMSG.

 

Basically, I read the data from FIFO0 fine, strip the step id from it and copy 
it into an element of a character array in the PRU code.  

 



 

Data = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFODATA(0));






if ((Data & 0x000F) == 0)  {  // checking the step id tag for step 0

// if step == 0, strip off the step and put the data in array DetBSample

DetBSample[sampleno] = Data & 0xFFF;

 

memcpy(payload, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 24); // 
this came from TI's sample code, best I can tell it just preloads and end of 
string character in the whole string.

ltoa((long)DetBSample[sampleno], payload);  // put the value in  
DetBSample[sampleno] in the character string payload

// now send the payload to the host


pru_rpmsg_send(, dst, src, payload, 24);   

 

This code compiles and runs fine.

 

On the host side, I do this when I'm kicked by the PRU.  (This is a snippet so 
brackets may not match!)

 

/* Poll until we receive a message from the PRU and then print it */

result = read(pollfds[0].fd, readBuf, MAX_BUFFER_SIZE);

if (result > 0)

{

Volts = atof(readBuf)*ADC_Res;

printf("Message %d received 
from PRU:%s or %x\n", i, readBuf, readBuf);

printf("Volts read: 
%.3f\n",Volts);

 

The output is strange though (snippet below).   The message #, string value of 
readBuf and Volts are all correct. But when I output readBug as hex, it never 
changes.  I thought it might be the address of readBuf but it doesn't appear to 
be.  

 

The voltage matches the input we're providing from a bench power supply and the 
decimal value is correct.  It's just that this hex value doesn't change.

 

Message 97 received from PRU:3742 or 4b50b0

Volts read: 1.644

Message 98: Sent to PRU

Message 98 received from PRU:3744 or 4b50b0

Volts read: 1.645

Message 99: Sent to PRU

Message 99 received from PRU:3743 or 4b50b0

Volts read: 1.645

Received 100 messages, closing /dev/rpmsg_pru30

 

 

-- 
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/784129ee-1cf5-4438-881e-7ac6621e7aben%40googlegroups.com
 
<https://groups.google.com/d/msgid/beagleboard/784129ee-1cf5-4438-881e-7ac6621e7aben%40googlegroups.com?utm_medium=email_source=footer>
 .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/002701d7364e%24a2ff0550%24e8fd0ff0%24%40comcast.net.

RE: [beagleboard] Re: BBB Setting up the Interrupt Vector Table

[Graham Stott]

If the interrupt is a level interrupt, your interrupt handling procedure needs 
to start clearing the interrupt starting at the source of the interrupt 
otherwise the interrupt will trigger again.

 

Graham

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Josh Cole
Sent: Tuesday, March 09, 2021 9:27 AM
To: BeagleBoard 
Subject: Re: [beagleboard] Re: BBB Setting up the Interrupt Vector Table

 

Thank you everyone! I appreciate the responses.

 

After days of trial and error I managed to setup the IVT and configure one of 
the timers to fire an interrupt on overflow. For me, I found this resource 
pretty helpful: 
https://android.googlesource.com/kernel/lk/+/upstream-master/platform/am335x - 
it appears to be the embedded android kernel ported to the beaglebone. They 
have some good interrupt stuff in there, as well as device-specific peripheral 
drivers.

 

I'm struggling now with "de-triggering" an interrupt after it fired. So my 
timer fires one interrupt and then the IRQSTATUS_RAW keeps its value, no matter 
how many ways I try to reset it. So I am only handling it once.

 

I feel I'm close though. Hopefully the resources shared + the anrdoid kernel I 
found will shed some light on how to correctly process an interrupt.

 

Cheers!

 

On Monday, March 8, 2021 at 8:23:10 AM UTC-8 lazarman wrote:

Yes I agree. Make sure to look at startup assembler language file many times 
vectors are in it. Start or start-up. Asm 

Sent from Yahoo Mail on Android 
<https://overview.mail.yahoo.com/mobile/?.src=Android> 

 

On Mon, Mar 8, 2021 at 9:56 AM, Graham Stott

mailto:gbcs...@comcast.net> > wrote:

You could look at the TI starterware code  for examples of setting  up the 
interrupt table and the code at the tables.

 

Graham

 

From: 'Mark Lazarewicz' via BeagleBoard [mailto:beagl...@googlegroups.com] 
Sent: Sunday, March 07, 2021 12:30 PM
To: beagl...@googlegroups.com <mailto:beagl...@googlegroups.com> 
Subject: Re: [beagleboard] Re: BBB Setting up the Interrupt Vector Table

 

Your handler needs the keyword interrupt to save the registers so when the 
vector occurs whatever was running isn't corrupted

 

Besides interrupt vector table don't forget exceptions they need a vector as 
well as in bus error or address error

 

Here's a brief reference you should look for interrupt code to verify and the 
correct arm programming guide

 

 

https://community.arm.com/developer/tools-software/tools/f/armds-forum/13621/need-interrupt-handling-code-for-arm-cortex-a9

 

 

Sent from Yahoo Mail on Android 
<https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
 

 

On Sun, Mar 7, 2021 at 12:01 PM, Josh Cole

mailto:three...@gmail.com> > wrote:

Update! 

 

I've solved my own problem and thought I'd share for any lost soul in the 
future who seeks these answers.

 

If you look at the technical reference manual for the am355x section 26-3 it 
shows an interrupt vector table which exists wildly far away from your 
application entrypoint. Upon closer inspection, I realized some entries are 
listed twice. This is because the interrupt vector table is actually a bunch of 
indirection.

 

If you want to set the IRQ branch address you specify the address at location 
0x4030_CE38

If you want to set the pre-fetch abort address you specify the address at 
location  0x4030_CE2C

 

Example code:

// Set the IRQ handler to the entrypoint of the application + 24 bytes

*(0x4030_CE38 as *mut u32) = 0x402F_0400 + 0x18;

 

I assumed I needed to write an actual branch instruction to those locations. 
Which is where my confusion started. So if you are building a low-level kernel 
and are working with interrupts, just remember that the vector table can be 
updated by simply writing the correct address to your handler based on the 
vector table in the reference manual (not an actual branch instruction).

 

On Friday, March 5, 2021 at 6:12:00 AM UTC-8 Josh Cole wrote:

Hi everyone,

 

I'm working on a low-level kernel for the Beaglebone Black. I've gotten to a 
point in my project where I want to specify an IRQ handler and enable 
interrupts.

 

According to the technical reference manual  
<http://www.sal.wisc.edu/st5000/datasheets/tq-systems/spruh73p.pdf> (section 
26.1.4), there are two primary locations you can load a disk image to. The 
first is what they call "Public ROM" which seems pretty straightforward. You 
load your image to address 0x2 and the interrupt vector table is the first 
thing which gets encountered.

 

The second location you can load an image is "Public RAM" (which I'm using). 
This starts executing at 0x402F0400 and you get 109kb of space for your 
application. The weird part is, the interrupt vector table appears to be 
located super far away from the entrypoint, at location 

RE: [beagleboard] Re: BBB Setting up the Interrupt Vector Table

[Graham Stott]

You could look at the TI starterware code  for examples of setting  up the 
interrupt table and the code at the tables.

 

Graham

 

From: 'Mark Lazarewicz' via BeagleBoard [mailto:beagleboard@googlegroups.com] 
Sent: Sunday, March 07, 2021 12:30 PM
To: beagleboard@googlegroups.com
Subject: Re: [beagleboard] Re: BBB Setting up the Interrupt Vector Table

 

Your handler needs the keyword interrupt to save the registers so when the 
vector occurs whatever was running isn't corrupted

 

Besides interrupt vector table don't forget exceptions they need a vector as 
well as in bus error or address error

 

Here's a brief reference you should look for interrupt code to verify and the 
correct arm programming guide

 

 

https://community.arm.com/developer/tools-software/tools/f/armds-forum/13621/need-interrupt-handling-code-for-arm-cortex-a9

 

 

Sent from Yahoo Mail on Android 
<https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
 

 

On Sun, Mar 7, 2021 at 12:01 PM, Josh Cole

mailto:threeorb...@gmail.com> > wrote:

Update! 

 

I've solved my own problem and thought I'd share for any lost soul in the 
future who seeks these answers.

 

If you look at the technical reference manual for the am355x section 26-3 it 
shows an interrupt vector table which exists wildly far away from your 
application entrypoint. Upon closer inspection, I realized some entries are 
listed twice. This is because the interrupt vector table is actually a bunch of 
indirection.

 

If you want to set the IRQ branch address you specify the address at location 
0x4030_CE38

If you want to set the pre-fetch abort address you specify the address at 
location  0x4030_CE2C

 

Example code:

// Set the IRQ handler to the entrypoint of the application + 24 bytes

*(0x4030_CE38 as *mut u32) = 0x402F_0400 + 0x18;

 

I assumed I needed to write an actual branch instruction to those locations. 
Which is where my confusion started. So if you are building a low-level kernel 
and are working with interrupts, just remember that the vector table can be 
updated by simply writing the correct address to your handler based on the 
vector table in the reference manual (not an actual branch instruction).

 

On Friday, March 5, 2021 at 6:12:00 AM UTC-8 Josh Cole wrote:

Hi everyone,

 

I'm working on a low-level kernel for the Beaglebone Black. I've gotten to a 
point in my project where I want to specify an IRQ handler and enable 
interrupts.

 

According to the technical reference manual  
<http://www.sal.wisc.edu/st5000/datasheets/tq-systems/spruh73p.pdf> (section 
26.1.4), there are two primary locations you can load a disk image to. The 
first is what they call "Public ROM" which seems pretty straightforward. You 
load your image to address 0x2 and the interrupt vector table is the first 
thing which gets encountered.

 

The second location you can load an image is "Public RAM" (which I'm using). 
This starts executing at 0x402F0400 and you get 109kb of space for your 
application. The weird part is, the interrupt vector table appears to be 
located super far away from the entrypoint, at location 0x4030CE00. This is 
more than 109kb away, so it can't be included in the image which gets flashed 
to the device.

 

I am at a loss about how to get an instruction to that particular location in 
memory since my image fundamentally can't be that size. Any guidance on how to 
setup the IVT for Public RAM would be greatly appreciated.

 

Thank you for your time!

-- 
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 

https://groups.google.com/d/msgid/beagleboard/b63bc711-fcda-497b-b4e5-ee35c0081176n%40googlegroups.com
 
<https://groups.google.com/d/msgid/beagleboard/b63bc711-fcda-497b-b4e5-ee35c0081176n%40googlegroups.com?utm_medium=email_source=footer>
 

.

-- 
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1482309015.269358.1615148982352%40mail.yahoo.com
 
<https://groups.google.com/d/msgid/beagleboard/1482309015.269358.1615148982352%40mail.yahoo.com?utm_medium=email_source=footer>
 .

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received

RE: [beagleboard] POCKETBEAGLE: UART Help - Garbage data along with requisite data

[Graham Stott]

Which Pins are you using for UART4 rcv and have you set the PIN mux correctly 
for that PIN?

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Piyush Raj ae19m009
Sent: Monday, March 01, 2021 6:30 PM
To: BeagleBoard 
Subject: [beagleboard] POCKETBEAGLE: UART Help - Garbage data along with 
requisite data

 

I am implementing UART using Pocketbeagle wherein i am trying to send simple 
strings over UART . I have written a code for loopback testing of UART-4 in PB. 
for a logic Low on P2.1  i am sending String "LOW" and "HIGH" for vice versa. 
However i am getting garbage data along with the requisite strings. sometimes 
all the received data is missing or broken. I tried to work at various baud 
rates (600, 9600,115200) but of no help.

Am i doing any basic mistake. need guidance from community. (I worked with AVR 
and Arduino UART in the past and never faced such problem)

 

Further, i also tried to dump the received data in a text file( to rule out 
possibility of terminal baud rate mismatch), but results did not change.

 

My code is below:

 

 

#include

#include

#include 

#include 

#include 

#include //for usleep

#include"GPIO.h"

using namespace exploringBB;

using namespace std;

 

int main()

{

GPIO  outLogicSupply(60); outLogicSupply.setDirection(OUTPUT);  

GPIO  inLogicSupply(59); inLogicSupply.setDirection(INPUT);

 

int file,count;

char transmit[6];

char receive[10];

  int bytes_written,read_code;int count1=1;

 OPENING UART4 ON POCKETBEAGLE /

printf("UART: Transmission Started.\n");

if ((file = open("/dev/ttyO4", O_RDWR | O_NOCTTY | O_NDELAY))<0)

{

  perror("UART: Failed to open the device.\n");

  return -1;

}

else

{

printf("UART: Opened file successfully\n");

}

/

 

   ///SETTING UP UART OPTIONS  ///

  struct termios options;

   tcgetattr(file, );

   options.c_cflag = B9600 | CS8 | CREAD | CLOCAL;

   options.c_iflag = IGNPAR | ICRNL;

   tcflush(file, TCIFLUSH);

   fcntl(STDIN_FILENO, F_SETFL, O_NONBLOCK);  // make reads non-blocking

   tcsetattr(file, TCSANOW, );

  

   cout << "The value of the input is: "<< inLogicSupply.getValue() << endl;

 

 

   while(1)

{

  

if(inLogicSupply.getValue()==1)

   

{

strcpy(transmit,"HIGH\n");

 outLogicSupply.setValue(HIGH);



}

else



{

strcpy(transmit,"LOW\n");

 outLogicSupply.setValue(LOW);

}



bytes_written = write(file, ,6);

sleep(1);

read_code= read(file,receive,10);

if(bytes_written>0  && read_code>0  ) 

{

receiveFile .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/99530b73-a474-410b-8583-4d0327d32d35n%40googlegroups.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.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/000201d70f2a%24edd15100%24c973f300%24%40comcast.net.

RE: [beagleboard] StarterWare_BBB_support.tar.gz

[Graham Stott]

You could try this:

 

https://github.com/embest-tech/AM335X_StarterWare_02_00_01_01

 

Graham

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Abdallah Rashed
Sent: Tuesday, February 09, 2021 7:30 AM
To: beagleboard@googlegroups.com
Subject: [beagleboard] StarterWare_BBB_support.tar.gz

 

Hello 

from where can I get StarterWare_BBB_support.tar.gz patch file to support TI 
bare metal application  to 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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CADA%3DDiK4Gme5mBcp9Dhi_Nt%3DAN1HE4cJCn%2Bu9sOTcZ1cOWLETQ%40mail.gmail.com
 
<https://groups.google.com/d/msgid/beagleboard/CADA%3DDiK4Gme5mBcp9Dhi_Nt%3DAN1HE4cJCn%2Bu9sOTcZ1cOWLETQ%40mail.gmail.com?utm_medium=email_source=footer>
 .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/000f01d6ff26%248c56d7b0%24a5048710%24%40comcast.net.

RE: [beagleboard] Booting Beaglebone Black with SDK RTOS

[Graham Stott]

Ok,  I missed that in your earlier posting. 

 

I believe that the image you are using cannot be used on a Beaglebone Black. 
The image is for a TI evaluation module (EVM). You need to build the RTOS for 
the Beaglebone.

 

Graham

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Karthik Eswar
Sent: Saturday, January 16, 2021 6:39 PM
To: beagleboard@googlegroups.com
Subject: Re: [beagleboard] Booting Beaglebone Black with SDK RTOS

 

I used the images that were present in the sdk rtos installed directory by 
default

 

On Sun, 17 Jan, 2021, 4:09 am Graham Stott, mailto:gbcsto...@comcast.net> > wrote:

So It looks like the I2C test that you are running has an issue. Can you try 
something simple. For example, the hello world test.

 

And no you do not need a JTAG to debug. You should be able to use printf.

 

Graham

 

From: beagleboard@googlegroups.com <mailto:beagleboard@googlegroups.com>  
[mailto:beagleboard@googlegroups.com <mailto:beagleboard@googlegroups.com> ] On 
Behalf Of Karthik Eswar
Sent: Friday, January 15, 2021 10:02 PM
To: BeagleBoard mailto:beagleboard@googlegroups.com> >
Subject: [beagleboard] Booting Beaglebone Black with SDK RTOS

 

I tried booting Beaglebone Black with pre-built sdcard.img provided in the path

 

C:\ti\processor_sdk_rtos_am335x_6_03_00_106\prebuilt-sdcards\evmAM335x\sd_card_img.

 

I connected the board using USB-TTL to view the booting procedure, but it shows:

 

StarterWare Boot Loader

BOARDInit status [0x0]

 SoC   : [AM335X]

 Core  : [A8]

 Board Detected: [BEAGLEBONEBLACK]

 Base Board Revision   : [UNKNOWN]

 Daughter Card Revision: [UNKNOWN]

Copying application image from MMC/SD card to RAM

Jumping to StarterWare Application...

 

 I2C Test: 400Kbps: Data Mismatch

 

 I2C Test: 100Kbps: Data Mismatch

 

 Some tests have failed.

 

Kindly help me with this

-- 
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4bf271c3-7de7-46f7-9959-48078009e2ean%40googlegroups.com
 
<https://groups.google.com/d/msgid/beagleboard/4bf271c3-7de7-46f7-9959-48078009e2ean%40googlegroups.com?utm_medium=email_source=footer>
 .

-- 
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/001801d6ec58%24706961c0%24513c2540%24%40comcast.net
 
<https://groups.google.com/d/msgid/beagleboard/001801d6ec58%24706961c0%24513c2540%24%40comcast.net?utm_medium=email_source=footer>
 .

-- 
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CABwUBJhMpB3R1sR07bSgPuzH261d%2BN1718-6aX56ZVq%3D5jYDgQ%40mail.gmail.com
 
<https://groups.google.com/d/msgid/beagleboard/CABwUBJhMpB3R1sR07bSgPuzH261d%2BN1718-6aX56ZVq%3D5jYDgQ%40mail.gmail.com?utm_medium=email_source=footer>
 .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/001c01d6ec83%2417b44790%24471cd6b0%24%40comcast.net.

RE: [beagleboard] Booting Beaglebone Black with SDK RTOS

[Graham Stott]

So It looks like the I2C test that you are running has an issue. Can you try 
something simple. For example, the hello world test.

 

And no you do not need a JTAG to debug. You should be able to use printf.

 

Graham

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Karthik Eswar
Sent: Friday, January 15, 2021 10:02 PM
To: BeagleBoard 
Subject: [beagleboard] Booting Beaglebone Black with SDK RTOS

 

I tried booting Beaglebone Black with pre-built sdcard.img provided in the path

 

C:\ti\processor_sdk_rtos_am335x_6_03_00_106\prebuilt-sdcards\evmAM335x\sd_card_img.

 

I connected the board using USB-TTL to view the booting procedure, but it shows:

 

StarterWare Boot Loader

BOARDInit status [0x0]

 SoC   : [AM335X]

 Core  : [A8]

 Board Detected: [BEAGLEBONEBLACK]

 Base Board Revision   : [UNKNOWN]

 Daughter Card Revision: [UNKNOWN]

Copying application image from MMC/SD card to RAM

Jumping to StarterWare Application...

 

 I2C Test: 400Kbps: Data Mismatch

 

 I2C Test: 100Kbps: Data Mismatch

 

 Some tests have failed.

 

Kindly help me with this

-- 
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4bf271c3-7de7-46f7-9959-48078009e2ean%40googlegroups.com
 
<https://groups.google.com/d/msgid/beagleboard/4bf271c3-7de7-46f7-9959-48078009e2ean%40googlegroups.com?utm_medium=email_source=footer>
 .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/001801d6ec58%24706961c0%24513c2540%24%40comcast.net.

RE: [beagleboard] Saving content from TI Wiki

[Graham Stott]

Am I correct in assuming that we are talking about documentation? Also the 
older forums.  I presume that all software (compilers, SDKs, etc) will still be 
available. 

 

I also started making a list. I will be interested to see your list(s)!

 

Graham

 

 

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Jason Kridner
Sent: Sunday, October 11, 2020 2:08 PM
To: Beagle Board 
Cc: Bill Traynor 
Subject: Re: [beagleboard] Saving content from TI Wiki

 

I think TI would be supportive in giving us copies of relevant content. I 
barely got started copying content over to eLinux.org--that seems like the best 
host to me.

 

If you look at my latest contribution history 
(https://elinux.org/Special:Contributions/Jkridner), you can see a few pages I 
started to copy over to the Beagleboard space on elinux.org <http://elinux.org> 
.

 

You can also see the assets didn't get moved over by me copying and pasting the 
text, obviously. I tried for a few minutes to think of a way to automate and 
didn't arrive at anything.

 

Remind me the next few days to provide the list I got on potential content. 
Then, others can add to that list if we missed anything. Mine is based on a 
spreadsheet I got from TI.

 

If anyone has good suggestions on automating the move, please let me know.

 

 

On Sat, Oct 10, 2020 at 2:13 PM din...@gmail.com <mailto:din...@gmail.com>  
mailto:dinu...@gmail.com> > wrote:

On Saturday, October 10, 2020 at 12:35:36 AM UTC+3 RobertCNelson wrote:

On Fri, Oct 9, 2020 at 4:01 PM din...@gmail.com <mailto:din...@gmail.com>  
mailto:din...@gmail.com> > wrote: 
> 
> Dear Beagleboard.org overseers, 
> 
> The TI Processors Wiki is being shutdown. I think valuable information would 
> be lost that cannot be found in TRMs or Datasheets. For example, the 
> following opcodes information was crucial while porting the GNU assembler for 
> PRU: 
> https://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit 
> 
> Are you willing to transfer that and similar content to beagleboard.org 
> <http://beagleboard.org>  ? Wikimedia page sources can be mostly 
> automatically translated to MarkDown or HTML. So content could be served as a 
> static page, with no need to host dynamic Wiki. 


I don't think we could get access to that.. 

 

Wikimedia page source is still available: 
https://processors.wiki.ti.com/index.php?title=Programmable_Realtime_Unit 
<https://processors.wiki.ti.com/index.php?title=Programmable_Realtime_Unit=edit>
 =edit  . EOL is scheduled for December.

 


http://web.archive.org/web/20190916141936/http://processors.wiki.ti.com:80/index.php/Programmable_Realtime_Unit
 
<http://web.archive.org/web/20190916141936/http:/processors.wiki.ti.com:80/index.php/Programmable_Realtime_Unit>
  

Regards, 

-- 
Robert Nelson 
https://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.com 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0cf3f8f1-bcec-459d-ac02-a8b81773f118n%40googlegroups.com
 
<https://groups.google.com/d/msgid/beagleboard/0cf3f8f1-bcec-459d-ac02-a8b81773f118n%40googlegroups.com?utm_medium=email_source=footer>
 .



-- 

BeagleBoard.org Foundation is a US-based 501(c)3 non-profit providing education 
and collaboration around open source hardware and software

 

Use https://beagleboard.org/about/jkridner to schedule a meeting

 

-- 
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAK8RMs1zFgWoeouFEJuXa59F3WM%2BND1srYhABMbRcN%3DyrdftRw%40mail.gmail.com
 
<https://groups.google.com/d/msgid/beagleboard/CAK8RMs1zFgWoeouFEJuXa59F3WM%2BND1srYhABMbRcN%3DyrdftRw%40mail.gmail.com?utm_medium=email_source=footer>
 .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/001b01d6a018%242b72ee60%248258cb20%24%40comcast.net.

[beagleboard] Re: Install Ubuntu using SD card and Windows

[Graham Haddock]

Have you tried plugging ia serial cable into the local serial port?
That should work as long as you still know the password.
No network links involved.

---Graham

==

On Saturday, September 19, 2020 at 6:30:17 AM UTC-5 pietb...@gmail.com 
wrote:

> Hi
>
> I'm a Linux blockhead.
>
> I just got a BeagleBone Black.
>
> I'm working with it from a Windows10 computer using Putty and WinSCP.
>
> In trying to set a static eth0 IP, (successful) and getting it to use 
> 8.8.8.8 as DNS, I managed to lock myself out of it completely. (Long story, 
> involving adding and deleting things in files, adjusting write permissions 
> in folders, removing connman and so forth).
>
> So now I cannot log in to the BBB with any profile. Not it's 
> default 192.168.7.1 through USB, or anything else which worked previously. 
> (I had deleted the ethernet static IP previously anyway)..
>
> I get:
> Network error: Connection refused
>
> I did not make a backup of whatever it had on it's eMMC beforehand.
>
> So:
> Putty does not work with any IP address
> WinSCP does not work with any IP address
> The Browser interface does not work with any IP address
>
> I can ping 192.168.7.1
> With the BBB plugged into a USB port, I have access to the "BeagleBone 
> Getting Started" drive in Windows File Explorer.
>
> So naturally I'm trying to get the thing working again. So would this work?
>
> I buy some sort of "USB to microSD" device. Something like this:
>
>
> <https://media.takealot.com/covers_images/71f4c8bba6e04ef8869d73e26b8427bb/s-pdpxl.file>
>
> I download some Ubuntu image from somewhere onto my Windows laptop. (I 
> decided that I might as well go to UBUNTU rather than the Debian it has, 
> while I'm at it).
>
> I write this image out to the microSD through USB.
>
> I stick the microSD into the BBB and push some button to get it booting 
> from the microSD.
>
> So once I get it working again, I can transfer the UBUNTU image from the 
> microSD to the eMMC.
>
>
> Please help!
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/838e8c70-9da6-4345-9344-31fbc5afe6a0n%40googlegroups.com.

Re: [beagleboard] PocketBeagle USB-C

[Graham Haddock]

Another choice:
Adafruit USB C Breakout Board - Downstream Connection PRODUCT ID: 4090
Digi-Key Part Number   1528-2873-ND  

Instructions at
https://www.adafruit.com/product/4090 

It already has the two resistors on it, that Robert referred to. 

--- Graham

On Monday, August 17, 2020 at 8:43:21 AM UTC-5 RobertCNelson wrote:

> On Mon, Aug 17, 2020 at 8:25 AM  wrote:
> >
> > Hi All
> > I'm starting to delve into this
> > can someone please advise how can i connect USB-C Breakout board to 
> PocketBeagle
>
> Type-C has two more pins.. CC1 and CC2 which help determine
> orientation. Whereas the PocketBeagle is only USB2.0..
>
> https://www.sparkfun.com/products/15100
>
> Connect each CC* pin to gnd with their own 5.1k resistor
>
> Regards,
>
> -- 
> Robert Nelson
> https://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.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7305f081-bab6-472a-9675-0cbff906d447n%40googlegroups.com.

RE: [beagleboard] Re: I2C driver for a PCA9685 servo controller board for s90 servos

[Graham Stott]

I did  a quick review of the set up part of the code you posted. The code is 
not complete. It is missing some clocks setup.

 

You should download the TI AM335x Technical Reference manual. I have version 
spruh73q. Look at the picture on page 1563. You will see that the L4_per is 
connected to the L3S unit. Now look at the picture on page 1565. You will see 
the I2C2 is on the L4 peripheral bus (L4_per). So you need to enable the clocks 
for both the L3s and the L4 unit to be able to use I2C2.

 

I did not look at any of the other code, but I think the value for the pin mux 
should be 0x33. That turns on the pull up.

 

There is a lot of great information in the Reference manual, so happy reading 
and coding.

 

Graham

 

 

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of marcbo...@gmail.com
Sent: Saturday, August 15, 2020 5:27 PM
To: BeagleBoard 
Subject: [beagleboard] Re: I2C driver for a PCA9685 servo controller board for 
s90 servos

 

You are right the code that is missing is

 

 

void i2c_init(void){


On Saturday, August 8, 2020 at 12:57:15 PM UTC-7, M wrote:

Can anyone provide a C program that can be run in CCS that would program an I2C 
controller on the BBB board to generate the desired clock frequency signal and 
the required data signals on the I2C bus.

 

 

Part 1. Program the device to generate signals to turn LED15 to full ON. Should 
be measurable voltage from the number 15 signal pin on the servo board.

 

Part 2. Develop commands you send to PCA9685 to intialize it for the  correct 
frequency for your servo, set up a timer on the BBB to control delays, and 
intialize the BBB User LEDs.

-- 
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d0cbb043-6e61-4bb4-b93b-55dde349123fo%40googlegroups.com
 
<https://groups.google.com/d/msgid/beagleboard/d0cbb043-6e61-4bb4-b93b-55dde349123fo%40googlegroups.com?utm_medium=email_source=footer>
 .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/002c01d6741d%24b9396bb0%242bac4310%24%40comcast.net.

RE: [beagleboard] Re: I2C driver for a PCA9685 servo controller board for s90 servos

[Graham Stott]

The code you copied below seems to be incomplete.  After the routine 
“set_slave_addr” and before the comment “//P9 Connector settings”, I believe 
there is missing code.  I therefore cannot tell  if your setup code is complete.

 

Graham

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of marcbo...@gmail.com
Sent: Saturday, August 15, 2020 2:35 PM
To: BeagleBoard 
Subject: [beagleboard] Re: I2C driver for a PCA9685 servo controller board for 
s90 servos

 

So I have been working on this on my own time, I am a potential CE student. 
This was an assignment for someone who gave it to me along with caped BBB. I am 
running barebones using CCS and a TI XDS100v2 USB Debug Probe/CortxA8 sim. They 
wrote this program as an LCD driver using the I2C1 bus from the BBB.

I am trying to use this code to send a signal to the PWM PCA9685 LED15 pin to 
full ON. I am trying to configure the pins (19/20) on the BBB to use the I2C2 
in Mode3  on the P9 connector  The datasheet is here 
https://cdn-shop.adafruit.com/datasheets/PCA9685.pdf

 

Here is the code so far: It will run through the cases and go to the endless 
loop, but am not getting a signal on the pin 15 of the PCA9685. I am trying to 
just send two bytes at a time and I think this is what is wrong with the code, 
but I have been debugging.

 

// Define Indirect Addressing Macro for Registers

 

#define HWREG(x) (*((volatile unsigned int *)(x)))

 

// Common Defines

#define TRUE1

#define FALSE   0

#define DELAY_COUNT 10

 

// Base Module Defines

#define CTRLMOD_BASE0x44E1

#define CM_PER_BASE 0x44E0

#define I2C2_BASE   0x4819C000

// Control Module Defines

#define CONF_I2C2_SCL   0x97C

#define CONF_I2C2_SDA   0x978

#define MODE3   0x3B

 

// Peripheral Control Module Defines

#define CM_PER_I2C2_CLKCTRL 0x44

#define CLK_ENABLE  0x2

 

// DRM Register Offset Defines

#define I2C_2_SUSPEND_CTRL  0x230

 

// Register Address Offset Defines

#define I2C_SA  0xAC

#define I2C_CNT 0x98

#define I2C_DATA0x9C

#define I2C_IRQSTATUS_RAW   0x24

#define I2C_CON 0xA4

#define I2C_PSC 0xB0

#define I2C_SCLL0xB4

#define I2C_SCLH0xB8

#define I2C_BUFSTAT 0xC0

#define I2C_IRQENABLE_SET   0x2C

 

// I2C Register Values

#define _12MHZ_CLK  0x03

#define _tLOW_  0x08

#define _tHIGH_ 0x0A

#define I2C2_ENABLE 0x8600

#define IRQ_DISABLED0x

 

 

// Mask Defines

#define DCOUNT_VAL  0x

#define XRDY_RDY0x0010

#define XRDY_BIT0x0010

#define RRDY_BIT0x0008

#define RRDY_RDY0x0008

#define BF_BIT  0x1000

#define BUS_IS_FREE 0

#define DATA_VAL0xFF

#define BUFSTAT_VAL 0x003F

 

//I2C Communication Defines

#define SLAVE_ADDR  0x40

#define NUM_OF_DBYTES   10

#define START_COND  0x0001

#define STOP_COND   0x0002

#define MASTER_TX_MODE  0x600

#define NAME_BYTE_LENGTH13

 

// General registers

#define PCA9685 0x80

// I2C address for PCA9865 with all inputs at zero

#define Reset   0x01// Reset the device

#define MODE1   0x00// 0x00 location for Mode1 register 
address

#define MODE2   0x01// 0x01 location for Mode2 register 
address

#define PRE_SCALE   0xFE// Prescaler address

#define P_S_VALUE   0x79// PWM frequency value

 

// MODE1 bits PCA9685

#define PCA96_INIT  0x11

#define LED15_ADD   0x43

 

 

// Variables

unsigned int x;

unsigned int y;

volatile unsigned int USR_STACK[100];

volatile unsigned int IRQ_STACK[100];



void wait(void){

while(1){

// Endless loop

   };

   }

 

void delay(unsigned long int y){

while(y>0){

y--;

}

}




int is_bus_free(void){

x = HWREG(I2C2_BASE + I2C_IRQSTATUS_RAW);   //Read 
mask 0x1000 from I2C_IRQSTATUS_RAW (I2C Status Raw  Register) offset 0x24 
to check bus status.

x = (x & BF_BIT);   //Mask.

if(x == BUS_IS_FREE) return 1;

else return 0;

}




int is_i2c_write_ready(void){

x = HWREG(I2C2_BASE + I2C_IRQSTA

RE: [beagleboard] Need help connecting USB TTL to PocketBeagle

[Graham Stott]

I do not use any of the other pins. Voltage to the board comes from the USB 
side.

 

Graham

 

From: Leesah Cage [mailto:leesahc...@gmail.com] 
Sent: Tuesday, August 11, 2020 2:59 PM
To: beagleboard@googlegroups.com
Subject: Re: [beagleboard] Need help connecting USB TTL to PocketBeagle

 

Thanks so much Graham, I am ordering that exact board, do you plug the CTS, VCC 
and DRS into anything or you DON’T use those at all?

 

Thanks so much for your help, I was pulling my hair out trying to find the 
right board.





On Aug 11, 2020, at 5:22 PM, Graham Stott mailto:gbcsto...@comcast.net> > wrote:

 

OSEPP FTDI USB to Serial Basic Breakout Board (3.3V/5V

 

-- 
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/E69D95B1-763A-4DCC-BE10-B0FBF9C73C8F%40gmail.com
 
<https://groups.google.com/d/msgid/beagleboard/E69D95B1-763A-4DCC-BE10-B0FBF9C73C8F%40gmail.com?utm_medium=email_source=footer>
 .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/001c01d67036%24b54ff770%241fefe650%24%40comcast.net.

RE: [beagleboard] Need help connecting USB TTL to PocketBeagle

[Graham Stott]

Leech,

 

First of all that should have been P1 PIN 14 (not 15). Sorry for that mistake.

 

I use  the following board.

 

OSEPP FTDI USB to Serial Basic Breakout Board (3.3V/5V). I set the jumper to 
3.3 volts and connect TX, RX and GND from the Pocket Beagle. I use putty on the 
laptop with a setting of: Baud – 115200; Data bits – 8; stop bits 1; parity – 
none.

 

Do an online search for “FTDI USB to Serial Basic Breakout Board“. You do need 
one that does 3.3 volts.

 

Graham

 

From: Leesah Cage [mailto:leesahc...@gmail.com] 
Sent: Tuesday, August 11, 2020 9:54 AM
To: beagleboard@googlegroups.com
Subject: Re: [beagleboard] Need help connecting USB TTL to PocketBeagle

 

Do you have a link to the adapters that you have used that work with the pocket 
beagle?





On Aug 11, 2020, at 11:44 AM, Graham Stott mailto:gbcsto...@comcast.net> > wrote:

 

First of all I have not used this particular adapter. All the similar adapters 
I have used get their power from the USB connection and have a jumper to select 
between 5v and 3.3 volts for the RX and TX interface.  Looking at the picture 
of the board, I cannot see a jumper. As the Pocket Beagle is 3.3 volts only, I 
suggest you connect the Pocket Beagle 3.3 volts ( P1 pin 15) to the 3.3 pin on 
the board. I would not connect the 5.0 volts.

 

Graham

 

 

 

From: Rayleshia Cage [mailto:sa...@ladycage.com] 
Sent: Tuesday, August 11, 2020 7:07 AM
To: beagleboard@googlegroups.com <mailto:beagleboard@googlegroups.com> 
Subject: [beagleboard] Need help connecting USB TTL to PocketBeagle

 

Hello,

I have been searching online all weekend to no avail to find out exactly how I 
can connect a PocketBeagle to this USB to TTL adapter if it is possible can 
anyone help me?  The layouts I have seen have the TX,RX, GND on the adapter 
connected to the PocketBeagle RX,TX,GND but when I plugged the usb into my 
laptop nothing happened. Does anyone know if the 3v and 5v pins on the adapter 
need to be plugged in and how do they connect to the PocketBeagle(which pins 
(P1p14?). If this is not the right adapter please advise which on will work on 
the PocketBeagle.

 

 
<http://amazon.com/HiLetgo-CP2102-Converter-Adapter-Downloader/dp/B00LODGRV8/ref=sr_1_4?crid=1W895AJVJXMO7=1=usb+ttl+adapter=1597154301=electronics=usb+ttl%2Celectronics%2C161=1-4>
 
amazon.com/HiLetgo-CP2102-Converter-Adapter-Downloader/dp/B00LODGRV8/ref=sr_1_4?crid=1W895AJVJXMO7=1=usb+ttl+adapter=1597154301=electronics=usb+ttl%2Celectronics%2C161=1-4

 

Thank you and I apologize for my ignorance.

 

-- 
For more options, visit  <http://beagleboard.org/discuss> 
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  <mailto:beagleboard+unsubscr...@googlegroups.com> 
beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit  
<https://groups.google.com/d/msgid/beagleboard/B49D5F5B-4F94-4231-8492-8CA24A0DFE2C%40ladycage.com?utm_medium=email_source=footer>
 
https://groups.google.com/d/msgid/beagleboard/B49D5F5B-4F94-4231-8492-8CA24A0DFE2C%40ladycage.com.

 

-- 
For more options, visit  <http://beagleboard.org/discuss> 
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  <mailto:beagleboard+unsubscr...@googlegroups.com> 
beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit  
<https://groups.google.com/d/msgid/beagleboard/003601d66ff6%245632b510%2402981f30%24%40comcast.net?utm_medium=email_source=footer>
 
https://groups.google.com/d/msgid/beagleboard/003601d66ff6%245632b510%2402981f30%24%40comcast.net.

 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/97E438FA-8122-4A45-8C49-087D729A5830%40gmail.com
 
<https://groups.google.com/d/msgid/beagleboard/97E438FA-8122-4A45-8C49-087D729A5830%40gmail.com?utm_medium=email_source=footer>
 .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/006001d67025%2480902700%2481b07500%24%40comcast.net.

RE: [beagleboard] Need help connecting USB TTL to PocketBeagle

[Graham Stott]

First of all I have not used this particular adapter. All the similar adapters 
I have used get their power from the USB connection and have a jumper to select 
between 5v and 3.3 volts for the RX and TX interface.  Looking at the picture 
of the board, I cannot see a jumper. As the Pocket Beagle is 3.3 volts only, I 
suggest you connect the Pocket Beagle 3.3 volts ( P1 pin 15) to the 3.3 pin on 
the board. I would not connect the 5.0 volts.

 

Graham

 

 

 

From: Rayleshia Cage [mailto:sa...@ladycage.com] 
Sent: Tuesday, August 11, 2020 7:07 AM
To: beagleboard@googlegroups.com
Subject: [beagleboard] Need help connecting USB TTL to PocketBeagle

 

Hello,

I have been searching online all weekend to no avail to find out exactly how I 
can connect a PocketBeagle to this USB to TTL adapter if it is possible can 
anyone help me?  The layouts I have seen have the TX,RX, GND on the adapter 
connected to the PocketBeagle RX,TX,GND but when I plugged the usb into my 
laptop nothing happened. Does anyone know if the 3v and 5v pins on the adapter 
need to be plugged in and how do they connect to the PocketBeagle(which pins 
(P1p14?). If this is not the right adapter please advise which on will work on 
the PocketBeagle.

 

amazon.com/HiLetgo-CP2102-Converter-Adapter-Downloader/dp/B00LODGRV8/ref=sr_1_4?crid=1W895AJVJXMO7
 
<http://amazon.com/HiLetgo-CP2102-Converter-Adapter-Downloader/dp/B00LODGRV8/ref=sr_1_4?crid=1W895AJVJXMO7=1=usb+ttl+adapter=1597154301=electronics=usb+ttl%2Celectronics%2C161=1-4>
 
=1=usb+ttl+adapter=1597154301=electronics=usb+ttl%2Celectronics%2C161=1-4

 

Thank you and I apologize for my ignorance.

 

-- 
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/B49D5F5B-4F94-4231-8492-8CA24A0DFE2C%40ladycage.com
 
<https://groups.google.com/d/msgid/beagleboard/B49D5F5B-4F94-4231-8492-8CA24A0DFE2C%40ladycage.com?utm_medium=email_source=footer>
 .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/003601d66ff6%245632b510%2402981f30%24%40comcast.net.

RE: [beagleboard] Re: I2C driver for a PCA9685 servo controller board for s90 servos

[Graham Stott]

If (as Dennis asked) you are asking about this program for a bare-board (no OS) 
configuration, then I suggest you look at TI's starterware. It has routines for 
I2C and GPIOs that you can use from the C program to provide the functionality 
you are asking for. You can use CCS for the development. There are videos 
online for "getting started" with starterware and CCS.

Graham

P.S Dennis - FYI, I have a Beaglebone white and a PocketBeagle and I only run 
starterware on them. I do read this forum often.



-Original Message-
From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Dennis Lee Bieber
Sent: Sunday, August 09, 2020 11:08 AM
To: Beagleboard 
Subject: [beagleboard] Re: I2C driver for a PCA9685 servo controller board for 
s90 servos

On Wed, 5 Aug 2020 18:36:12 -0700 (PDT), in gmane.comp.hardware.beagleboard.user
marcbob34-re5jqeeqqe8avxtiumw...@public.gmane.org wrote:

>Can anyone provide a C program that can be run in CCS that would 
>program an I2C controller on the BBB board to generate the desired 
>clock frequency signal and the required data signals on the I2C bus.
>
>
>Part 1. Program the device to generate signals to turn LED15 to full ON. 
>Should be measurable voltage from the number 15 signal pin on the servo 
>board.
>
>Part 2. Develop commands you send to PCA9685 to intialize it for the 
>correct frequency for your servo, set up a timer on the BBB to control 
>delays, and intialize the BBB User LEDs.

The phrasing of this sounds very much like it is some sort of homework 
assignment.

Doing someone else's homework is frowned upon in many forums. The 
mention of CCS also complicates matters in that CCS supports bare-board 
development (using TI's SDK, I believe) and maybe Linux development.

If running under Linux, there are native compilers which run on the 
BBB, though without an IDE (especially if one hasn't installed X-Window 
system). Also one can set up a cross-development environment (easiest to be 
running in a desktop Linux -- set up Debian in Oracle VirtualBox if running on 
a Windows system... Instructions for cross-development, including configuring 
Eclipse, are in Chapter 7 of Molloy's Exploring Beaglebone 2nd Ed [or use his 
Exploring Raspberry-Pi -- chapter 7 is practically identical).

So first: Are you talking about a bare-board (no OS) configuration or 
an application to run under Linux? I don't recall anyone on the forum that 
regularly works with bare-board -- there is just so much that has to be set up 
just to start a program running.

Second: Show us YOUR code and explain what doesn't seem to be working 
with it. And don't submit the equivalent of

#include 
void main(argc, *argv)
{
/* need help here */
}

We can help correct your attempts, but won't write the code for you.
Providing a link to the documentation for your peripheral board would also have 
been useful.

Heh -- I'd probably start with the out-of-stock Adafruit board, and use 
Python via the Adafruit_Blinka compatibility library to use their CircuitPython 
PCA9685 module.


--
Dennis L Bieber

--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4dd0jfd9hajh7649m43sun2j6t02ti9a1p%404ax.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.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/000501d66eb3%24a5aa96b0%24f0ffc410%24%40comcast.net.

RE: [beagleboard] Re: Project based off the Pocket Beagle - Boot Configuration Help

[Graham Stott]

-Original Message-
From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Samuel Park
Sent: Saturday, August 08, 2020 3:04 PM
To: BeagleBoard 
Subject: RE: [beagleboard] Re: Project based off the Pocket Beagle - Boot 
Configuration Help

Ah I see thanks for the reply. However the problem I have is that I removed all 
the external pins including pins for power. Is there a way to set up a serial 
connection via the USB 2.0 interface?
 
[Graham Stott] Yes, except that it would require a software driver which makes 
the USB a virtual UART. So that does not help you at all.

I presume you do not have access to any of the OSD335x pads. You may need your 
experience friend to redo the board and bring out the UART0 TX and RX to pads 
that you could solder on some wires to connect to the 
FTDI FT232 USB to UART Converter.

I am not sure what else to suggest.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b52ea67a-32dd-4eb6-9004-3caeb490274co%40googlegroups.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.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/000301d66ddf%24d287ad50%24779707f0%24%40comcast.net.

RE: [beagleboard] Re: Project based off the Pocket Beagle - Boot Configuration Help

[Graham Stott]

I strongly agree with Jim that the way for you to make progress is to connect 
up a serial cable. A FTDI FT232 USB to UART Converter  is one easy way to do 
this. Only three wires (TX, RX and GND) from the pocket Beagle.

 

Once you  have the serial output working, you could also try to boot something 
more simple off the SD CARD. You could try booting a simple app using TI 
starterware.

 

Graham

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Jim F
Sent: Friday, August 07, 2020 3:38 PM
To: beagleboard@googlegroups.com
Subject: Re: [beagleboard] Re: Project based off the Pocket Beagle - Boot 
Configuration Help

 

It's basically impossible to diagnose further without a serial cable like I 
described above. But you can keep feeling blindly and might get lucky. I have 
no idea what the led indicates, but it changed something.

 

Good luck! 

 

On Fri, Aug 7, 2020, 5:43 PM Samuel Park mailto:samuelpark0...@gmail.com> > wrote:

Ok so I followed the guide and made some progress. I hardcoded the device ID in 
u-boot so now when I boot all the user LEDs turn on momentarily but then turn 
off after one second. After they initially turn on they just turn off. Before 
hardcoding it, none of them turned on except the power LED. Does this mean that 
it is trying to boot but failed at some point? Also, one more thing I noticed 
is that when I plugged in the real Pocket-Beagle without a SD card Windows 
still recognized and allocated a COM port. However, when I plug in my version 
of the Pocket Beagle without the SD card, Windows doesn't recognize it. Could 
this be the issue?

On Friday, August 7, 2020 at 1:08:17 PM UTC-4, Samuel Park wrote:

Hello, I am currently working on a project based on the pocket beagle. For my 
project, I had an experienced friend design and fabricate a custom board based 
on the pocket beagle to suit my purpose using the schematics and files on 
Github, nearly everything is identical except for the following changes: 
Removed all GPIO pins (unnecessary space), and replaced the microUSB connector 
with a male USB 2.0 connector(so that the board could be directly connected to 
a computer without a cable. Everything else was untouched and I used the exact 
same parts as the Pocket Beagle. I am trying to boot it with the latest Pocket 
Beagle Debian image however unable to do so because of the hardware change(I'm 
assuming). This is my first time working with something like this (I'm a 
software guy) so I apologize if I have a lack of knowledge about some aspects 
with regards to hardware. What do I have to do to be able to boot the Pocket 
Beagle's Debian image on it? Originally I thought that because the hardware 
change was so minimal it should be able to boot the pocket beagle's images. 
However, I realized that there is probably gonna be problems with regards to 
hardware id and such. Thanks, and I would appreciate any help.

-- 
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d890c1c0-012d-440b-b614-d4a59e9c7573o%40googlegroups.com
 
<https://groups.google.com/d/msgid/beagleboard/d890c1c0-012d-440b-b614-d4a59e9c7573o%40googlegroups.com?utm_medium=email_source=footer>
 .

-- 
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAGS%2B2h8LkQs2sdcM3cGFsTy%3Dy0bdPQSMrhDS0o%2B50ZXV2XFLKQ%40mail.gmail.com
 
<https://groups.google.com/d/msgid/beagleboard/CAGS%2B2h8LkQs2sdcM3cGFsTy%3Dy0bdPQSMrhDS0o%2B50ZXV2XFLKQ%40mail.gmail.com?utm_medium=email_source=footer>
 .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/01d66d2d%24a332ce20%24e9986a60%24%40comcast.net.

[beagleboard] Re: BB Blue repair

[Graham Haddock]

3.3 Volts is generated inside the OSD3358 by a TI TPS65217C PMIC die   
PMIC stands for Power Management IC
You can read the TI data sheet on the TPS65217C
But the OSD3358 is a multi-chip module, so not too much you can do, other 
than replace the entire OSD3358, if damaged.
And that would require BGA (Ball Grid Array) rework capability.
--- Graham

==

On Saturday, August 1, 2020 at 5:54:02 PM UTC-5 Jeff Albrecht wrote:

> On Saturday, August 1, 2020 at 2:45:33 PM UTC-7 Jeff Albrecht wrote:
>
>> On Thursday, July 30, 2020 at 6:49:03 PM UTC-7 Jeff Albrecht wrote:
>>
>>>
>>> I found @jadon Jason Kridner github beaglbone-blue repository 
>> <https://github.com/jadonk/beaglebone-blue> with Eagle files. Then found 
>> a fork that is probably more authorities as it seems to have several newer 
>> changes, and well Beagleboard :-). beagleboard / beaglebone-blue 
>> <https://github.com/beagleboard/beaglebone-blue> 
>>
>>
> How is 3.3V created?
>
> I have some experience with KiCad and DipTrace however very little 
> experience with Eagle.
>
> I figured out how to highlight the 3.3V net, is there any kind of show 
> origin command? 
>
> I've exported the parts list and the Netlist. In the parts list there is 
> 5VREG and 6VREG I searched on just '3.3' finding only one part L3 3.3 
> uH.What generates the 3.3 vdc? What is the origin of the 3.3 VDC?
>
>  - Jeff
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/dfee2f1f-948b-466f-ba64-e2b7532031cfn%40googlegroups.com.

[beagleboard] Re: Pocket Beagle does not boot.

[graham]

I would start by having 3-D X-Ray of the solder balls under the main 
processor chip, to look for shorts, solder bridges and open ball 
connections.

Simple vertical X-ray will not always tell you what you need to know.

--- Graham

==

On Thursday, July 16, 2020 at 4:10:53 AM UTC-5, Wapeul wrote:
>
> We made the board with the open source of Pocket Beagle.
> https://github.com/beagleboard/pocketbeagle
>
> We made a total of five.
> Only one of them works, and four do not.
> I don't know the cause.
> All pin maps have the same voltage.
> The voltage of EMU0 (CDN of SD card connector) is 3.3V for normal board 
> and 0V for abnormal board.
>
>
>
> How to solve it?
> What do we need to check?
>
> Best regards
> CH Cho
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/fa7087c3-1af9-4815-be00-f71301589e95o%40googlegroups.com.

Re: [beagleboard] micro - sd card

[graham]

I agree with Stuart.

Windows has a limit of 32 GB using the FAT file system, but LINUX does not.
The limit for Windows is something that Microsoft put into Windows to 
encourage users to migrate to NTFS. 
The FAT32 file system on LINUX is good for 2 TeraBytes (or more), with an 
individual file size limit of 4 GB.

So as long as you are not trying to use Windows, there is no problem going 
somewhat above 32 GB.

--- Graham

==

On Wednesday, July 8, 2020 at 5:22:28 AM UTC-5, Stuart Longland wrote:
>
> On 7/7/20 12:50 am, jonnymo wrote: 
> > If you use a 64Gb or greater card, then you'll need to format it as an 
> > exFat drive. 
>
> Why? The AM3358 SoC doesn't understand exFAT… nor does U-Boot at last 
> check. 
> -- 
> Stuart Longland (aka Redhatter, VK4MSL) 
>
> I haven't lost my mind... 
>   ...it's backed up on a tape somewhere. 
>
> Help fund COVID-19 research: 
> https://stuartl.longlandclan.id.au/blog/2020/04/20/who-covid19/ 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3ddf129f-59ee-4462-b8f6-4fd8c41959cao%40googlegroups.com.

[beagleboard] Re: micro - sd card

[Graham Haddock]

The answers is that the BeagleBone can address the entire 16GB micro-SD 
card.
I have used cards up to 128 GB in size.
BUT
if you installed the OS image on the card for either direct use, or for 
writing to the EMMC, then the partition size has been set to 4 GB, and you 
can not see the rest of the card.
To restore access to the entire card, do the following incantation:

cd /opt/scripts/tools/
git pull
sudo ./grow_partition.sh
sudo reboot

On the next reboot, [df -h] should show the full microSD card size.

--- Graham
On Monday, July 6, 2020 at 10:54:45 AM UTC-5 KenUnix wrote:

> I have a BBB running Debian 10.3 on a 32GB SD-Card.
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/38ed4280-f7ad-4095-ab7d-78487116c216n%40googlegroups.com.

[beagleboard] Re: Ethernet over USB adapter

[graham]

The USB connector (USB-0) on the Pocket Beagle board is configured as a 
peripheral, only.
USB-1, is configured as a "Host" and will control many USB to Ethernet 
adaptors, but USB-1 is not pinned out to a USB connector, just the header 
pins.
You will need to provide some kind of USB connector to header pin 
connection, to do what you are trying to do.

--- Graham

==

On Wednesday, June 24, 2020 at 11:26:26 AM UTC-5, Szoshi wrote:
>
> Hello,
>
> I am trying to connect a PB in our network over a USB to Ethernet adapter. 
> I assumed that modifying the interfaces file with a static IP and rebooting 
> the PB will make it appear in the arp -a list but I cannot see the MAC 
> address of my network card, neither can I ping the static IP. 
>
> Is there something fundamentally wrong that I might be doing here? Can 
> someone nudge me in the right direction?
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a85dba34-fc76-49c1-8597-f7d3eafcc455o%40googlegroups.com.

[beagleboard] Re: B.B.B. turn off automatically

[graham]

Could be old software. Some earlier versions of Debian did that.
What version software are you using?

Could be a weak power supply.
Is your power supply good enough to power the peak currents for the 
BeagleBone at all times?

Are you using a PocketBeagle, and not a BeagleBone?
The PocketBeagles do that, if powered from the external power input.

===



On Monday, June 15, 2020 at 9:04:59 AM UTC-5, saeidi...@gmail.com wrote:
>
> Hi
> My BeagleBone turn off automatically after 5 or 6 hours, whats the problem?
> Do you have any idea?
> Thanks
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6b900d01-ccde-40b3-a785-8fbfac55ee08o%40googlegroups.com.

RE: [beagleboard] Re: PocketBeagle 5 volt and 3.3 volts output pins issue.

[Graham Stott]

Jeff,

 

Thanks for the explanation. It helped a lot.

 

Graham

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Jeff Pollard
Sent: Monday, May 25, 2020 9:35 AM
To: BeagleBoard 
Subject: [beagleboard] Re: PocketBeagle 5 volt and 3.3 volts output pins issue.

 

 

Hi,

 

  There are diodes inside MOS microcontrollers I/O that go from the I/O pin to 
the V+ power rail.  Look at the diagram for a single mosfet transistor.  Some 
diagrams will show the diode, while others don't, but there is a diode that 
points from the Source (your microcontroller I/O pin) to the the Drain (the V+ 
of the chip).  What you are seeing is the backfeed from the external serial 
port TX pin going through the diode from the I/O pin (source)  to the V+ 
(drain).  It typically isn't going to be much current, but on some low power 
controllers it is often enough to actually run the device.  Back before USB, 
some types of mouses that were input through the PC serial port actually used 
the PC's serial TX line (and other output control lines of the serial port) to 
power the mouse logic circuitry, with no requirement for an separate/external 
power source for the mouse).

 

  The important thing is that the amount of current from the external TX line 
is relatively, so not much current is going to flow through the input pin's 
diode to V+.  The problem happens when you have a lot of current that could 
flow through that input, through the diode to the V+ of the microcontroller. 
The diode was not specifically meant to handle the current load of driving the 
entire chip (and any off chip devices that may also b attached to the V+ bus 
the controller is on).

 

Jeff

 


On Sunday, May 24, 2020 at 10:08:08 PM UTC-7, Graham Stott wrote:

Configuration:

 

PocketBeagle (PB) with an I2C connection to a MPU6050 breakout board. Power to 
the MPU6050 board is 3.3 volts from the PB. 

 

The PB is connected to a CurieNano using uart TX and RX. This is serial port 4. 
The two boards have their own power supplies. There is a common ground wire 
between the two boards.

 

This configuration works well and I can send messages between the two boards. 
The PB has no problem "talking" to the MPU6050.

 

I had the power to the PB disconnected and was just using the CurieNano. I was 
uploading a script.

 

I noticed that the power LED on the MPU6050 board was on (not very bright). I 
measured the 3.3 volts line going into the board. It measured 1.7 volts. I also 
measured the 5 volts output pin on the PB. It measured 1.8 volts. As there was 
no power to the PB and the only other connection was the serial port, I removed 
the two wires. The LED went off and the voltages on the PB went to zero. Put 
the cable back on and voltages come back. I measured the TX and RX line from/to 
the CurieNano. The TX was 3.0 volts and the RX was 0.08. Removing the I2C cable 
had no effect.

 

Questions:

 

1: Had anyone else seen this behavour? How is a voltage on a serial port on a 
PB with no power showing up (as a lower voltage) on the 5.0 volt and 3.3 volt 
output pins!!

 

2: Is this an issue I need to be concerned about. Could it damage the boards?

 

3: Is this just a design artifact of the OSD3358 when it is powered off the 
voltage on the RX pin is reflect via some substrate to the voltage output pins?

 

4: Am I missing something?

 

I have look for any shorts and found none. And anyway the voltage output pads 
on the IC are nowhere near the serial port 4 pads.

 

Graham

 

 

-- 
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/28a0b7d2-3295-41ca-bfcc-3ebd9a2a19a0%40googlegroups.com
 
<https://groups.google.com/d/msgid/beagleboard/28a0b7d2-3295-41ca-bfcc-3ebd9a2a19a0%40googlegroups.com?utm_medium=email_source=footer>
 .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/001701d63315%249fd5ff60%24df81fe20%24%40comcast.net.

RE: [beagleboard] Pocketbeagle 5v and 3.3v output issue

[Graham Stott]

Jim,

 

Thanks for the explanation. I think the solution for me is to power both boards 
from the same power source so that they are always both on or both off.

 

One minor problem I have is that when I am downloading a script to the 
CurieNano, it is powered from the USB connection that is used as the download 
connection. I think I will fix that by making a USB cable that does not have 
the +5 volt connection. That will mean if I am downloading a script I will need 
to use the actual power supply and therefore both boards will be on.

 

Thanks again.

 

Graham

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Jim F
Sent: Monday, May 25, 2020 4:51 PM
To: beagleboard@googlegroups.com
Subject: Re: [beagleboard] Pocketbeagle 5v and 3.3v output issue

 

This is pretty common behavior. TTL 232 pins have a limited drive capability 
and may be sufficient to power or partially power connected loads such as your 
cutie board. Your 3v measurement on the TX line is evidence that your doing 
that. You are powering the system up using the ESD diodes inside the chip. 

 

According to the OSD3358 documentation, is not safe to go the other way. You 
can't power the OSD in this way safely. I know nothing about the currie board 
so can't say anything about it. 

 

Typically it's safe to do this kind of thing for at least short periods. ESD 
diodes are designed for high voltage and very short transients. Most of the ESD 
structures I've seen were pretty huge and could tolerate a fair amount of 
power, but again, you'd want to check with the data sheet of your product. 

 

Jim

On Mon, May 25, 2020, 4:51 PM mailto:gbcsto...@comcast.net> > wrote:

Configuration:

 

pocketbeagle (PB) with serial port 4 (TX and RX) connected to uart on a Curie 
nano board.  PB I2C1 connected to a MPU6050 breakout board. PD 3.5 volt output 
(P2 PIn 13) supplies power to MPU6050 board.

 

This configuration works as I can transfer data between the PB and the Curie 
Nano via the serial port.

 

I had power off on the Pocketbeagle and was updating a script on the Curie Nano 
board. The Curie Nano  was powered via the USB connection to my laptop.

 

I noticed that the power LED on the MPU6050 board was on although it was not 
very bright. I measured the 3.3 volt input to the MPU6050, it showed 1.7 Volts. 
I also looked at the 5 volt output from the PB, it was 1.8 volts. As the only 
device that actually had power was the Curie and the only connection between 
the two boards was the serial port, I unplugged the serial port wires from the 
header. The voltages on the PB board power output pins went to zero. Putting 
the serial wires back brought the voltages back. I measured the voltages on the 
TX and RX wires. The TX was 3.0 volts and the RX was 0.08 volts. I beleve this 
is as expected as the TX has a Pull up and the RX has a Pull down.

 

I checked the boards for shorts and did not find any. I in fact did not expect 
to find any as the boards run fine when both are powered on. When the PB is 
powered on, the output voltages are at their correct level. 

 

Questions:  

 

1: Has anyone else seen this sort of behavour on te power output pins?

 

2: Is it really an issue or is it just how the OSD335x is designed.

 

3: Should I be concern about this killing my board?

-- 
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/bdd2f503-43c5-461d-8a44-0a8213e38470%40googlegroups.com
 
<https://groups.google.com/d/msgid/beagleboard/bdd2f503-43c5-461d-8a44-0a8213e38470%40googlegroups.com?utm_medium=email_source=footer>
 .

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to a topic in the Google 
Groups "BeagleBoard" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/beagleboard/S2Hg7YyaNNg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
beagleboard+unsubscr...@googlegroups.com 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAGS%2B2h-d3%3DKNYk-AjbfRyg6aAXT-6BzOZNmATXRWTmxfsOecTw%40mail.gmail.com
 
<https://groups.google.com/d/msgid/beagleboard/CAGS%2B2h-d3%3DKNYk-AjbfRyg6aAXT-6BzOZNmATXRWTmxfsOecTw%40mail.gmail.com?utm_medium=email_source=footer>
 .

-- 
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 rece

RE: [beagleboard] PocketBeagle 5 volt and 3.3 volts output pins issue.

[Graham Stott]

Jim,

 

Thanks for the great reply.  I will change my setup so that both boards are 
power from the same power supply.

 

Graham 

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Jim F
Sent: Monday, May 25, 2020 6:25 AM
To: beagleboard@googlegroups.com
Subject: Re: [beagleboard] PocketBeagle 5 volt and 3.3 volts output pins issue.

 

What you are describing is typical behavior for electronics and is something 
you need to pay attention to. According to the OSD3358 vendor, if power is not 
applied to the chip, voltage should not be applied to any of its pins. You 
should either design a circuit to prevent this, or design your system to ensure 
that if one board has power, both do.

 

Jim 

 

On Mon, May 25, 2020, 1:08 AM Graham Stott mailto:gbcsto...@comcast.net> > wrote:

Configuration:

 

PocketBeagle (PB) with an I2C connection to a MPU6050 breakout board. Power to 
the MPU6050 board is 3.3 volts from the PB. 

 

The PB is connected to a CurieNano using uart TX and RX. This is serial port 4. 
The two boards have their own power supplies. There is a common ground wire 
between the two boards.

 

This configuration works well and I can send messages between the two boards. 
The PB has no problem "talking" to the MPU6050.

 

I had the power to the PB disconnected and was just using the CurieNano. I was 
uploading a script.

 

I noticed that the power LED on the MPU6050 board was on (not very bright). I 
measured the 3.3 volts line going into the board. It measured 1.7 volts. I also 
measured the 5 volts output pin on the PB. It measured 1.8 volts. As there was 
no power to the PB and the only other connection was the serial port, I removed 
the two wires. The LED went off and the voltages on the PB went to zero. Put 
the cable back on and voltages come back. I measured the TX and RX line from/to 
the CurieNano. The TX was 3.0 volts and the RX was 0.08. Removing the I2C cable 
had no effect.

 

Questions:

 

1: Had anyone else seen this behavour? How is a voltage on a serial port on a 
PB with no power showing up (as a lower voltage) on the 5.0 volt and 3.3 volt 
output pins!!

 

2: Is this an issue I need to be concerned about. Could it damage the boards?

 

3: Is this just a design artifact of the OSD3358 when it is powered off the 
voltage on the RX pin is reflect via some substrate to the voltage output pins?

 

4: Am I missing something?

 

I have look for any shorts and found none. And anyway the voltage output pads 
on the IC are nowhere near the serial port 4 pads.

 

Graham

 

 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9eab48a6-867b-473a-b913-872bc88a4022%40googlegroups.com
 
<https://groups.google.com/d/msgid/beagleboard/9eab48a6-867b-473a-b913-872bc88a4022%40googlegroups.com?utm_medium=email_source=footer>
 .

-- 
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAGS%2B2h_AmY5_P3hmY0qd2SwtFyzqJMHOM3twa6M7eWRE5BTSOA%40mail.gmail.com
 
<https://groups.google.com/d/msgid/beagleboard/CAGS%2B2h_AmY5_P3hmY0qd2SwtFyzqJMHOM3twa6M7eWRE5BTSOA%40mail.gmail.com?utm_medium=email_source=footer>
 .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/000801d632a3%24651d37c0%242f57a740%24%40comcast.net.

[beagleboard] PocketBeagle 5 volt and 3.3 volts output pins issue.

[Graham Stott]

Configuration:

PocketBeagle (PB) with an I2C connection to a MPU6050 breakout board. Power 
to the MPU6050 board is 3.3 volts from the PB. 

The PB is connected to a CurieNano using uart TX and RX. This is serial 
port 4. The two boards have their own power supplies. There is a common 
ground wire between the two boards.

This configuration works well and I can send messages between the two 
boards. The PB has no problem "talking" to the MPU6050.

I had the power to the PB disconnected and was just using the CurieNano. I 
was uploading a script.

I noticed that the power LED on the MPU6050 board was on (not very bright). 
I measured the 3.3 volts line going into the board. It measured 1.7 volts. 
I also measured the 5 volts output pin on the PB. It measured 1.8 volts. As 
there was no power to the PB and the only other connection was the serial 
port, I removed the two wires. The LED went off and the voltages on the PB 
went to zero. Put the cable back on and voltages come back. I measured the 
TX and RX line from/to the CurieNano. The TX was 3.0 volts and the RX was 
0.08. Removing the I2C cable had no effect.

Questions:

1: Had anyone else seen this behavour? How is a voltage on a serial port on 
a PB with no power showing up (as a lower voltage) on the 5.0 volt and 3.3 
volt output pins!!

2: Is this an issue I need to be concerned about. Could it damage the 
boards?

3: Is this just a design artifact of the OSD3358 when it is powered off the 
voltage on the RX pin is reflect via some substrate to the voltage output 
pins?

4: Am I missing something?

I have look for any shorts and found none. And anyway the voltage output 
pads on the IC are nowhere near the serial port 4 pads.

Graham


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9eab48a6-867b-473a-b913-872bc88a4022%40googlegroups.com.

[beagleboard] Re: Install on emmc or keep on USB?

[graham]

Your microSD card is 64 GB in size. 
You can access it all if you follow the instructions to expand the file 
system.
The eMMC is 4 GB in size.
If you need less than 4 GB, then you can use the eMMC.
If you do a lot of writes, then the 64 GB card will last much longer, since 
the write leveling algorithms have more memory to work with.
If you are just using the BBB for learning and experimentation, then you 
will never use it enough to worry about wearing anything out.
With the uSD card, you could have several different cards, with different 
programs or operating systems on them, and easily switch back and forth.
So, as usual, the answer is "it depends on what you want to do, and what 
you care about."



On Saturday, May 2, 2020 at 11:08:10 PM UTC-5, mahendr...@gmail.com wrote:
>
> Im setting up an beaglebone black i have had for sometime.
> I've downloaded the latest image and flashed it to my SD card(Samsung Evo 
> Select 64Gb).  As im following the instruction on this page: 
> https://beagleboard.org/getting-started,  i have come to part where it 
> states:
>
>  "If using BeagleBone Black, BeagleBone Blue, BeagleBone AI or other 
> board with on-board eMMC flash and you desire to write the image to your 
> on-board eMMC, you'll need to follow the instructions at 
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flashing_eMMC;
>
> My question is, are there any benefits of writing th image to the eMMC vs 
> running it of my SD?
>
> Thanks
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d303635b-9baa-4a15-b19e-ef3acc80e929%40googlegroups.com.

[beagleboard] Re: Online training update

[graham]

Any thoughts as to when this might occur?

--- Graham



On Thursday, March 19, 2020 at 2:40:46 PM UTC-5, Jason Kridner wrote:
>
> https://beagleboard.org/blog/2020-03-18-online-training-update
>
> As mentioned in my New Year’s resolution 
> <https://beagleboard.org/blog/2020-01-05-jasons-new-years-resolutions>, 
> I’m going to launch some online training for embedded Linux development.
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f8069f12-abd5-4dd6-88e7-68bec70f9047%40googlegroups.com.

[beagleboard] Re: opening partitions with uSD boot

[graham]

If you run on a uSD card, be aware that the file system as downloaded will 
be restricted to the size of the intended eMMC, but you can expand the file 
system to the full size of the card, with the encantation:

cd /opt/scripts/tools/
git pull
sudo ./grow_partition.sh
sudo reboot


On Monday, March 16, 2020 at 12:39:04 AM UTC-5, ddch...@gmail.com wrote:
>
> i have a 2gig version BBB.  i finally figured out how to flash the dhamn 
> thing.  first i downloaded the latest version of debian 4gig uSD bootable.  
> It worked, but when i used the df -h command to see how much storage space 
> i had to work with, i was only allocated the 4 gigs on a 16gig uSD card.  
> because of this i switched to the 2gig emmc version of debian so that i use 
> my uSD for storage.  i dont want to do this.  i would rather have the 
> latest version of debian using the uSD to boot, but still get all the use 
> out of my uSD card.  my raspberry pi works this way.  i am able to boot 
> Raspian from the uSD and use the remaining space on the sd card for 
> storage.  how do i do this with my 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6c605777-c0f3-4123-b074-f18ca76b6aa4%40googlegroups.com.

Re: [beagleboard] Re: operating system on eMMc or on Sdcard

[Graham]

Ken:

I have never used Cloud9, so I don't know for sure.

I know the console version does support USB, Ethernet, commandctl and USB.
It likely supports the WiFi RTL...
I would assume you could add Cloud9 if you knew the "encantation."

Pretty much anything that does not require a modification to the kernel can
be added later.

It is easy enough to work with, so I would recommend you go set up a copy
to work on a uSD card,
or the eMMC, if you must, and start experimenting with it.

A serial cable that allows you to directly access the CPU command line is
useful.

I typically start with a console version, talk to it with SSH over Ethernet
immediately, and add whatever I need, typically Python, and a bunch of
Python and IO dependencies.

If you run on a uSD card, be aware that the file system as downloaded will
be restricted to the size of the associated eMMC, but you can expand the
file system to the full size of the card, with the encantation:

cd /opt/scripts/tools/
git pull
sudo ./grow_partition.sh
sudo reboot

You would think that the eMMC would run faster than a uSD card, but I have
never been able to measure a difference in program execution speed.

--- Graham

==

On Sun, Mar 8, 2020 at 3:44 PM KenUnix  wrote:

> Graham,
>
> I know the Iot version supports WiFi RTL81888EUS via connmanctl, USB &
> Ethernet & Browser to Cloud9.
> Does the "console" version support these? Or, for example can Cloud9 be
> installed later?
>
> Thanks
>
>>
>>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC_N71r%2B6h9oa%3D-XxLa-iZiZa%3DCsBfYpuZyvx06i_1-Z8knFwQ%40mail.gmail.com.

[beagleboard] Re: What happens when sensor connected to beagle bone black

[graham]

Sanjeevi:
I would prefer to keep this a public email communication, on this board, so 
that others may learn, also.
--- Graham

--

Hello sir,
I am Sanjeevi and I'm currently pursuing by bachelors degree. I have 
several doubts in using sensors with beaglebone black. Can you give your 
contact number.

Regards, 
SANJEEVI S. 

-

On Friday, January 24, 2020 at 1:46:09 PM UTC-6, Graham Haddock wrote:
>
> It depends where you connect it.
>
> Do not use any of the "boot pins" if you can avoid them.
>
> Read the System Reference Manual
>
>
> https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual#671-boot-configuration-design
>
>
> https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual#83-pin-usage-consideration
>
> If you do try to use any of the boot pins, follow the instructions about 
> not connecting to them until after the SYS_RESET line goes high.
>
> --- Graham
>
> ==
>
>
>
>
> On Friday, January 24, 2020 at 12:09:19 PM UTC-6, sanjeevi suresh wrote:
>>
>> When I connect a sensor to the board, and once I restart the board, 
>> whether the sensor input will affect the board? 
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d2a7a404-0a27-44f9-a0ec-2c5fd811f035%40googlegroups.com.

[beagleboard] Re: What happens when sensor connected to beagle bone black

[graham]

It depends where you connect it.

Do not use any of the "boot pins" if you can avoid them.

Read the System Reference Manual

https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual#671-boot-configuration-design

https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual#83-pin-usage-consideration

If you do try to use any of the boot pins, follow the instructions about 
not connecting to them until after the SYS_RESET line goes high.

--- Graham

==




On Friday, January 24, 2020 at 12:09:19 PM UTC-6, sanjeevi suresh wrote:
>
> When I connect a sensor to the board, and once I restart the board, 
> whether the sensor input will affect the board? 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a6bb39b4-69d2-450e-89f4-4be7a5844718%40googlegroups.com.

[beagleboard] Re: Pocket Beagle

[graham]

Anything in the range of 4 GB to 32 GB will normally work fine.
Since it is the primary long term memory for the unit, I would buy a 
quality brand.
I have never had a problem with a Samsung card.
Some users have had problems with "no name" memory cards.

--- Graham

==

On Monday, December 23, 2019 at 7:30:04 AM UTC-6, Arthur Jelsma wrote:
>
> I am very new to the Pocket Beagle. What size and type of SD Card works 
> well with this board?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/55abfc77-cc8f-4667-bf9d-fda4be726950%40googlegroups.com.

Re: [beagleboard] Damaged eMMC, does not boot from SD-Card automagically

[graham]

It might not be an eMMC failure.
Could just be an old bootloader.
Did you update the bootpoader in the eMMC?

https://elinux.org/EBC_Exercise_07_Updating_an_Old_U-Boot#Fixing_the_Problem.2C_Blow_Away_Old_Boot_Loader

--- Graham

==

On Monday, November 25, 2019 at 11:38:32 PM UTC-6, Jim F wrote:
>
> Should be easy to do. Change the boot configuration so that you don't try 
> to boot from mmc1.
>
> I think if it's a black, it should be r68 out, r93 in. Look up that 
> platform manual to see the boot options. Chip is Am3358.
>
> Here a handy chunk of schematic to help with that. 
> https://e2e.ti.com/support/processors/f/791/t/661109?AM3358-SYSBOOT-configuration
>
> J
>
> On Mon, Nov 25, 2019, 10:16 PM Johan Henselmans  > wrote:
>
>>
>> I have a BeagleBone Wireless with a damaged eMMC card.
>>
>> I got mmcutils from 
>> https://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git, and 
>> mmc extcsd read /dev/mmcblk1
>> gives me this for the lifetime estimation:
>> eMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x0b
>> eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x08
>> Not good, should be something like 0x01 (less that 10 percent), according 
>> to
>> https://www.cnx-software.com/2019/08/16/wear-estimation-emmc-flash-memory/
>>
>> Also, looking at the devices I do not see a mmcbl1p1.
>> root@beaglebone:~# lsblk
>> NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
>> mmcblk0  179:00 14.9G  0 disk 
>> └─mmcblk0p1  179:10  3.5G  0 part /
>> mmcblk1  179:80  3.6G  0 disk 
>> mmcblk1boot0 179:16   02M  1 disk 
>> mmcblk1boot1 179:24   02M  1 disk 
>> mmcblk1rpmb  179:32   0  512K  0 disk 
>>
>> I am trying to boot the beaglebone from SD-card for the moment, until i 
>> get another one, but it will only boot when i use press the power and the 
>> boot button next to the sd-card.
>>
>> I tried to get rid of the boot flag on /dev/mmcblk1, as per instructions 
>> on
>> https://www.erdahl.io/2016/12/beaglebone-black-booting-from-sd-by.html
>> but I get errors getting to the eMMC: 
>> fdisk: cannot open /dev/mmcblk1: Input/output error
>>
>> Is there any way I can disable the eMMC somehow, so that it does not 
>> interfere with the booting of the sd-card and automatically boots the 
>> sd-card?
>>
>> Kind Regards,
>> Johan Henselmans
>>
>> -- 
>> 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 beagl...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/42459d9f-02f0-494c-b0d7-f2778098dae0%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/42459d9f-02f0-494c-b0d7-f2778098dae0%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/736929b6-6e3a-46f5-9e92-e387a0e5ed8d%40googlegroups.com.

Re: [beagleboard] Storing and updating global variables for use between power cycles

[graham]

Or, another simple way to get around eMMC wearout is to run from the 
microSD card, rather than the eMMC.
Buy an oversize, quality, microSD card, such as a Samsung, with a good 
internal wear leveling mechanism.
It is getting hard to find quality ones smaller than 32 GB these days.
Even though you are repetitively writing to the same "address location", 
the wear leveling mechanism is moving it around internally, every time you 
write, and remapping.
So, a 32 GB card should last about eight times longer than the 4 GB eMMC.
Go bigger if you are still worried.
--- Graham

==


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cebb0516-e955-4101-9a14-b3bba385ecfd%40googlegroups.com.

[beagleboard] Re: BeagleBoneBlack (BBB) revC freezes after ~50 hours

[graham]

Since you have a custom power supply, I would look there first.

Needs to be 5.0V plus or minus 0.25 Volts, with no spikes or transients 
that would ever go above 5.5V or below 4.5 Volts.

The BBB's on board PMC is very serious about protecting the BBB.

--- Graham

==

On Monday, November 18, 2019 at 10:11:06 AM UTC-6, Graham Haddock wrote:
>
> There were some similar issues a few years ago that were resolved.
> If you are running three or four year old software, you might have the 
> disease.
> If you are running recent recommended release version of Debian, then no 
> reports of issues.
> Make sure you have a clean, reliable power source.
>
> --- Graham
>
> ==
>
> On Monday, November 18, 2019 at 8:23:07 AM UTC-6, Ilia Lotosh wrote:
>>
>> Hi!
>>
>> I have a BeagleBoneBlack rev C. powered via cape pins (the cape is a 
>> custom board which takes 12v power and converts it to 5v to power the 
>> beaglebone). It consistently boots up ok (never experienced an ethernet PHY 
>> issues that others report).
>> The board runs a simple python script that exposes a TCP server and 
>> allows sampling GPIO pins.
>>
>> Everything works fine for hours, until after ~50 hours (not consistent, 
>> it takes between 40 and 50 hours to reproduce) the board freezes - stops 
>> responding via network, LEDs stop blinking. After a repower the board gets 
>> back to normal for another ~40 hours. During these tests the board sits in 
>> a closed box.
>>
>> When the cape is connected to another power supply and sits on my desk, 
>> there is no problem whatsoever - it keeps running for at least a week 
>> without issues.
>>
>> Did anyone encounter a similar issue? Or has any leads on how to 
>> investigate this?
>>
>> Thanks!
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/02a9806b-bfb6-44e7-8008-4abaea69ef8c%40googlegroups.com.

[beagleboard] Re: BeagleBoneBlack (BBB) revC freezes after ~50 hours

[graham]

There were some similar issues a few years ago that were resolved.
If you are running three or four year old software, you might have the 
disease.
If you are running recent recommended release version of Debian, then no 
reports of issues.
Make sure you have a clean, reliable power source.

--- Graham

==

On Monday, November 18, 2019 at 8:23:07 AM UTC-6, Ilia Lotosh wrote:
>
> Hi!
>
> I have a BeagleBoneBlack rev C. powered via cape pins (the cape is a 
> custom board which takes 12v power and converts it to 5v to power the 
> beaglebone). It consistently boots up ok (never experienced an ethernet PHY 
> issues that others report).
> The board runs a simple python script that exposes a TCP server and allows 
> sampling GPIO pins.
>
> Everything works fine for hours, until after ~50 hours (not consistent, it 
> takes between 40 and 50 hours to reproduce) the board freezes - stops 
> responding via network, LEDs stop blinking. After a repower the board gets 
> back to normal for another ~40 hours. During these tests the board sits in 
> a closed box.
>
> When the cape is connected to another power supply and sits on my desk, 
> there is no problem whatsoever - it keeps running for at least a week 
> without issues.
>
> Did anyone encounter a similar issue? Or has any leads on how to 
> investigate this?
>
> Thanks!
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8a17b81f-93f1-4cc8-b763-57dc550f240a%40googlegroups.com.

[beagleboard] Re: Storing and updating global variables for use between power cycles

[graham]

Hi Brian:

It is the number of writes, not the reads that I was concerned about.
You used the phrase "send a streaming update to it as the motor moves" in 
your initial email.
If you are continuously doing writes to the eMMC, then that is a long term 
concern.
If this is just a short term demonstrator, then no problem.
If this is a real product, then there are anecdotal reports of users 
killing the BeagleBone's eMMC after a few years of logging.

For a real good example, (of eMMC wearout, not a BeagleBone issue) read:
https://insideevs.com/news/376037/tesla-mcu-emmc-memory-issue/
https://www.businessinsider.com/older-teslas-reportedly-having-issues-charging-screen-not-working-memory-2019-10


If you need a small, almost unlimited write memory that remembers with the 
power off,
try something like an FRAM.

Example of a small development board:
https://www.adafruit.com/product/1897
Spec sheet says good for a trillion write cycles.

Beware buying a used Tesla. :-)
--- Graham

==

On Monday, November 18, 2019 at 8:23:55 AM UTC-6, bryan@gmail.com wrote:
>
> Something that can be stored and called upon at boot time to be used in a 
> main python function

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b88b3ba1-27a7-4043-9c23-788b21d7c48f%40googlegroups.com.

[beagleboard] Re: Colorizing ls, .bashrc

[graham]

I kept poking at it, and the answer is that both the ".bashrc" and the 
".profile" files are 
missing from the home debian directory in the August 9.9 release.
If you want the optional colorizing functionality back on the 9.9 release, 
you have to
manually add a valid ".bashrc" and a valid ".profile" file to the debian 
home directory.
--- Graham

==

On Sunday, November 17, 2019 at 7:33:49 PM UTC-6, Graham Haddock wrote:
>
> I just updated a BeagleBone Black from the October 2018 9.5 IoT release to 
> the August, 2019 9.9 IoT release.
>
> ls is no longer colorized, and there is no ".bashrc" file in the debian 
> home, where the option is normally turned on/off.
>
> If I install a ".bashrc" file there, it does not seem to be used.
>
> So, what has changed?
>
> A little Googling did not reveal anything.
>
> Is there somewhere else where the dir and ls options are supposed to be 
> set?
>
> --- Graham
>
> ==
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e88f28c1-2f31-4056-bef1-0cdb6f31421d%40googlegroups.com.

[beagleboard] Colorizing ls, .bashrc

[graham]

I just updated a BeagleBone Black from the October 2018 9.5 IoT release to 
the August, 2019 9.9 IoT release.

ls is no longer colorized, and there is no ".bashrc" file in the debian 
home, where the option is normally turned on/off.

If I install a ".bashrc" file there, it does not seem to be used.

So, what has changed?

A little Googling did not reveal anything.

Is there somewhere else where the dir and ls options are supposed to be set?

--- Graham

==

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/85d29765-2181-4e85-8438-bc8098853862%40googlegroups.com.

[beagleboard] Re: Storing and updating global variables for use between power cycles

[graham]

Also note that the eMMC is a device whose life is limited by the number of 
writes. 
If this is something that is intended to operate for multiple years, then 
you will need 
to limit the number of writes to the eMMC to the minimum necessary.
If you really need a lot of realtime write updates, you might want to 
consider something 
like a small FRAM memory peripheral for the motor/control position memory, 
rather
than the eMMC.  FRAMs, since they are magnetic RAMs, retain the memory 
without
power, with almost unlimited write cycle life.

--


On Friday, November 15, 2019 at 3:35:39 PM UTC-6, bRitch022 wrote:
>
> I am in need of a global variable(s) to store encoder data on a few motors 
> that I have attached to my beaglebone. In the event of a power down, I need 
> to be able to recall the last encoder position (since it is not absolute) 
> of a particular motor. I would like to find a few free memory bocks on the 
> eMMC and send a streaming update to it as the motor moves. 
>
> Any suggestions?
>
> Thank you!
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/060fe443-874b-4076-99df-17855412de15%40googlegroups.com.

Re: [beagleboard] Re: Pocket Beagle power question

[Graham Haddock]

>>> Does anyone have any input as to why the PocketBeagle design fails and
>>> why the BBBW works ?

Robert Nelson is really the right person to answer that.

>From what I understand, during boot, uBoot examines the configuration
EEPROM and decides which files/modules to load. Even though the hardware
is identical, it could load different modules, if the configuration
EEPROM is different. So, one load has the bug, the other doesn't.

Or, you are actually running different revision levels of silicon, and
one has a bug.


>>> Also if Tying VIN_USB to VIN_AC works, would the problem go away if a
>>> battery was connected to VIN_BAT ?

I have never tried that, but definitely worth a try.  It is a third
separate isolated power input. I assume with different management software.


>>> Any thoughts would be appreciated.
Beagleboard.org needs to decide if this is a serious enough problem that it
is worthy of being fixed.  So far, they have decided that we don't know
what
we are doing, and are inducing a spurious problem; or that it is not serious
enough a problem to spend the time fixing. I personally think it prevents
the PocketBeagle from being used for any serious application.

On Fri, Aug 16, 2019 at 12:35 AM Dave  wrote:

> As I have noted in a previous post, I am seeing this problem on a board
> with a design derived from the pocketBeagle.
> Based on the information here we have managed a workaround -  tying
> VIN_USB to VIN_AC, and as a consequence have several boards that have been
> runing for over 48hours, when we could not reach 18hrs before and often had
> resets every 30min.
>
> I have run the same software with nearly the same devicetree and the same
> linux(5.1.18) on a BBBW without any failures.
>
> I have compared the schematic of the BBBW which also uses that OSD335X SOC
> with that of my board and the pocketBeagle and  can not see a meaningful
> difference in the input power design.
>
> Does anyone have any input as to why the PcketBeagle design fails and why
> the BBBW works ?
>
> Also if Tying VIN_USB to VIN_AC works, would the problem go away if a
> battery was connected to VIN_BAT ?
>
> Any thoughts would be appreciated.
>
> Though atleast we have a workarround now.
>
> Thank you.
>
>
>
>
>
>
>
>
>
>
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/FwmkeG4itT0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/dadd11c2-3887-4c87-8d02-0048fd10dd92%40googlegroups.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.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CANN_KV5ySrb2ZCHv74Se1GjYDisQG15B_y46UPASRDNaX1W_xg%40mail.gmail.com.

[beagleboard] Re: Question about I2C Bus Recovery

[graham]

The method you refer to is not part of the "I2C Standard", but more a side 
effect of how I2C works,
so it is a "hack" to try to un-hang a bus, but no guarantee of success.
It is not implemented as an API call in Linux that I know of.
You might be able to trick the I2C hardware peripheral into doing this, by 
sending multiple repeated stops or bus resets, which are part of the API.

As the article you referenced says, the only sure way to send the 9 clock 
pulses is to de-initialize the I2C hardware peripheral, convert the two I2C 
pins temporarily back to GPIO pins and bit bang the pins to do what you 
want in software.

This might be difficult in Linux, since the kernel is very protective of 
any hardware peripherals and IO pins that have been assigned to it.

If you are getting a bus hang one out of 50,000 transactions, then there is 
something wrong with your bus implementation.
It should not do that.
Your time might be better spent reviewing your bus implementation: pull up 
values, bus capacitance, wire lengths, terminations, layout architecture, 
ground references, and noise environment.

Put a scope on the I2C lines and look at your signal integrity.

Slow down the I2C clock and see if the symptoms change.

--- Graham

==



On Tuesday, August 13, 2019 at 11:14:47 AM UTC-5, harriso...@gmail.com 
wrote:
>
> Hello all,
>
> I have a quick question about the I2C bus on the Beaglebone Black. 
>
> I have built a system with a number of I2C slaves, but sometimes (rarely, 
> once in 50,000 communications or less) they seem to hang and hold the bus 
> in a fixed state. The I2C standard in theory has a fix for this (toggling 
> the CLK 9 times 
> <https://bits4device.wordpress.com/2017/07/28/i2c-bus-recovery/>), which 
> forces the slave to release the bus.
>
> Is this fix implemented for the Beaglebone Black? I figured it might be 
> only in recent Linux kernels, and hence I am upgrading my system to Debian 
> 10/Linux 4.19 (previously it was the default Debian 8). However, I saw on a 
> Raspberry Pi forum (here 
> <https://www.raspberrypi.org/forums/viewtopic.php?t=231779>) that bus 
> recovery functionality might be chip-specific, and so I worry that this may 
> functionality may not exist for the AM335X. If not, how might I go about 
> implementing it?
>
> Thank you in advance for any assistance.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e8906b86-d495-45de-9799-c2c4cdff4d1d%40googlegroups.com.

Re: [beagleboard] Pocket Beagle power question

[Graham Haddock]

Jason:

The PocketBeagle will do this, when powered from a serious Lab-bench power
supply running into P1-Pin-1, with added capacitance on the pin, without
added capacitance on the pin, without any other accessory or cape drawing
power from the PocketBeagle.  I reported this in November 2017, and there
have been three or four other reports by other users since then.  It makes
the PocketBeagle unusable for any serious application, where it is not
powered from the microUSB connector.

--- Graham

==

On Mon, Aug 12, 2019 at 9:34 AM Pablo Rodriguez 
wrote:

> Hi,
> The past year i have to power 3 pocketbeagle from Vusb because of the
> random reset when connecting to Vin. This was the only thing that worked
> for me. Did a lot of testing adding capacitance and non work.
>
>
>
> El lun., 12 ago. 2019 a las 10:52, Jason Kridner (<
> jkrid...@beagleboard.org>) escribió:
>
>> On Sat, Aug 10, 2019 at 9:50 PM Graham Haddock 
>> wrote:
>>
>>> What I would do is some minor surgery on the PocketBeagle, disconnecting
>>> the +5V lead coming in the microUSB connector.
>>> The easiest way to do this would be to remove FB1 (ferrite bead in
>>> series with USB +5).
>>> Easy with "hot tweezers", or a pair of small soldering irons.
>>> To restore the Pocketbeagle to factory configuration, solder FB1 back in.
>>>
>>>
>> Whatever instability problems you are seeing, I don't see this addressing
>> it. The PMIC is designed to dynamically switch between the P1.1 ("AC power"
>> in PMIC terms, which always bothers me because it is never AC, but instead
>> DC assumed to come from an AC-powered wall-supply). If somehow there's not
>> enough capacitance to make the switch cleanly, I'd suspect you are doing
>> something rather odd with the *load* you are putting on it. What else do
>> you have connected?
>>
>> Anyway, I put both "AC" (P1.1) and "USB" (P1.7) on the headers on purpose
>> and the full expectation is that if you are putting a power supply in (and
>> it isn't a battery), you'll use P1.1. If it is battery, I also give you
>> that option at P2.14 (BAT).
>>
>>
>>> Short P1-Pin-1 and P1-Pin-7 together, and power the Beagle from whatever
>>> you are going to power it with at +5V.
>>> No issues with instability.
>>>
>>
>> OK, now you are just asking for trouble. There's no justification for
>> doing that.
>>
>> If the design isn't working as intended, then, let's talk about that and
>> details, such as what you are seeing on a scope and P2.13 (VOUT), which is
>> the output of the power mux on the PMIC, also referred to as SYS_5V on
>> BeagleBones. Ultimately, this is used to provide the power to the
>> regulators for the other subsystems. Perhaps your problem is drawing too
>> much current from it?
>>
>> It can be argued I put too many power options on the header, but I tried
>> to keep it flexible for people embedding it onto something. You have a lot
>> of flexibility and I don't see any need to encourage people to alter the
>> board.
>>
>> --
>> https://beagleboard.org/about - a 501c3 non-profit educating around open
>> hardware computing
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPnR-AOUOp%3DPouR%3DBs%3D%3DFn_NKqTOJM%3DprURJFToD%3DQGaXw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPnR-AOUOp%3DPouR%3DBs%3D%3DFn_NKqTOJM%3DprURJFToD%3DQGaXw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/FwmkeG4itT0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAEObdD2roPt_KjXtQJj15GSrmbndBCB2KzBkvXvCAfBoT3q-SQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/beagleboard/CAEObdD2roPt_KjXtQJj15GSrmbndBCB2KzBkvXvCAfBoT3q-SQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CANN_KV5g6B0%3DpWahVUQmEFcHbVpscBq95ARvYZOJSDi5OQg2oQ%40mail.gmail.com.

Re: [beagleboard] Pocket Beagle power question

[graham]

Dave:

I have never seen any clues in the logs.
It just randomly spontaneously reboots about once a day.
I suspect that running it from the USB Port-0 power input (P1-Pin-7) does 
not have the problem.
Running it from Vin (P1-Pin-1) does have the problem.
Running it from both in parallel does not have the problem, since the 
P1-Pin-7 always seems to work.

The only other clue I can offer is that back in 2015, the BeagleBone Black 
had a problem with identical
symptoms, that was fixed by Robert Nelson.  He never said what he did to 
fix, but I am pretty sure he had
to dig into the kernel.

See thread:
"BBB intermittently rebooting."  Started 7/17/2015.

--- Graham

==

On Monday, August 12, 2019 at 3:49:47 AM UTC-5, Dave wrote:
>
> Is there more information on this problem ?
>
> I am working on an OSD335x board that is similar to a PB or a BBBW - it 
> has eMMC. 
>
> I am experiencing random crashing often taking as long as 18 hours, but 
> sometimes as frequently as 30 min. 
> But the problem does not occur on a BBBW with almost identical 
> hardware/software.  
>
> I am looking for clues. 
>
> I will try powering from USB and the standard +5 input concurrently. 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/dd851261-45b7-4c41-aaf7-219d41c09388%40googlegroups.com.

Re: [beagleboard] Pocket Beagle power question

[Graham Haddock]

What I would do is some minor surgery on the PocketBeagle, disconnecting
the +5V lead coming in the microUSB connector.
The easiest way to do this would be to remove FB1 (ferrite bead in series
with USB +5).
Easy with "hot tweezers", or a pair of small soldering irons.
To restore the Pocketbeagle to factory configuration, solder FB1 back in.

Short P1-Pin-1 and P1-Pin-7 together, and power the Beagle from whatever
you are going to power it with at +5V.
No issues with instability.

Now you can plug in USB for programming and anything else you want/need to
do, at any time. It just won't take power through the USB cable any more.

--- Graham

==


On Sat, Aug 10, 2019 at 12:18 AM Jim F  wrote:

> Ahhh. I've had some of this pain. I did actually raise xmodem from the
> dead, but had enough problems that I just got a secondary USB port working
> and put a wifi dingle on it. Anyway what you want to do, sounds like it
> will work.
>
> On Fri, Aug 9, 2019, 9:07 PM Robert Heller  wrote:
>
>> At Fri, 9 Aug 2019 17:01:28 -0400 beagleboard@googlegroups.com wrote:
>>
>> >
>> >
>> > Robert,
>> >
>> > If you have a look at the Pocketbeagle schematic, you can see what
>> happens
>> > with the USB connector, which comes in on page 2. Power on that pin
>> goes to
>> > VIN.USB, which goes straight to (page 3) the Octavo OSD3358 VIN_USB
>> pins.
>> >
>> > You can look at the Octavo datasheet [1] - it's for the OSD335x_SM -
>> they
>> > tell you almost nothing. The only partly useful thing they tell you is
>> "The
>> > OSD335x-SM may be powered by any combination of the following input
>> power
>> > supplies. Please refer to the TPS65217C datasheet for details." The
>> > smartest thing to do would be to map the pins to the chips they are
>> > connected to using Octavo's tool [2] and the TI datasheets. I'm certain
>> > there's no isolation, but there is a switch to enable one or the other
>> > inputs (perhaps you had a looser definition of isolation in mind).
>> Figure
>> > 11 on page 27 of the TPS65217C datasheet [3] should show you what that
>> > looks like. These are configured by the PPATH register in [3], which I
>> am
>> > not precisely certain how it is configured in the first place, but you
>> > should be able to modify it on I2C0 (I think).
>> >
>> > All that said, it looks to me like it's fine to do. But I feel like I've
>> > done this and had some weird results, I just can't remember exactly what
>> > they were. I think the results included unplanned reverse power flow
>> (USB
>> > charging other things connected to the same VIN power supply), the
>> device
>> > not shutting down exactly as I expected, and similar behavior. I don't
>> > think we smoked anything, though, so there's that. Worth looking through
>> > that data sheet a little to make sure you're happy first.
>>
>> OK.  The reason I want to know is that I have an expansion board that
>> supplies
>> power (and does other things).  It does have a serial console header, so
>> I can
>> connect a TTL serial<=> USB cable for debugging, but unless I really want
>> to
>> raise XModem (from the dead?) there isn't any way to do something like
>> download a fresh executable program ("cross" built on a RPi).  I just
>> wondered
>> if it is "safest" to just unplug the Pocket Beagle from the expansion
>> board
>> and tether it to my laptop and use the Tcp/Ip over USB to do the "large"
>> transfers of things like exe files, etc.  This is what I have been doing
>> and
>> was wondering if I really have to do it that way or if I can plug in the
>> USB
>> while the Pocket Beagle is still being powered by the expansion board.
>>
>> >
>> > I would be quite interested to know precisely where PPATH is configured,
>> > beyond its default settings. It may be in the uboot source which is not
>> [I
>> > think] in the BB distributions. That stuff isn't bad to look at, and I
>> was
>> > going to, but for the life of me I can't remember where I built that
>> and I
>> > can't find it right now. Robert also has a few scripts in
>> /opt/scripts/boot
>> > which configure a LOT of things, I've only scratched the surface trying
>> to
>> > understand them.
>> >
>> > [0] -
>> >
>> https://github.com/beagleboard/pocketbeagle/blob/master/PocketBeagle_sch.pdf
>> > [1] - https://octavosystems.com/docs/osd335x-sm-datasheet/
>> > [2] -

Re: [beagleboard] Re: Pocket Beagle power question

[Graham Haddock]

As I said, P1-Pin-1 and the microUSB connector power are two different
inputs to two different power supplies.  Having power on both of them is
not a problem, and in fact, will prevent the problem of instability I was
concerned about.

So, no problem powering both.

The concern with the random crashes is just that, it could take three days,
or could happen in the first hour.
I would power the unit from both pins, if it is doing something at all
important.

Of course, my crashing experience is from 18 months ago, and there have
been a lot of software releases since then.

I would encourage you to run some endurance tests on your board, before
putting it in service.

--- Graham

==

On Fri, Aug 9, 2019 at 8:34 PM Robert Heller  wrote:

> At Fri, 9 Aug 2019 16:23:26 -0700 (PDT) beagleboard@googlegroups.com
> wrote:
>
> >
> >
> >
> > Robert:
> >
> > It has been a while, almost a year since I did any testing with the
> > PocketBeagle.
> > But I don't think anything has changed relative to my comments below.
> > Maybe someone can correct me if I am wrong, and some things have been
> fixed.
> >
> > P1-Pin-1 is Vin, and is equivalent to the Barrel Jack input on the
> > Beaglebone Black, it
> > is a separate power supply input, and is isolated from the microUSB
> > connector power.
> >
> > P1-Pin-7 is hardwired to the +5 pin on the microUSB connector, USB Port
> 0.
> > It is not clear from the schematic, but is visible if you view the PCB
> > board plots.
> > Or check it with an Ohmmeter.
> >
> > I found that the PocketBeagle, when powered exclusively by P1-Pin-1
> would
> > randomly
> > crash about once every 24 hours of operation, without any apparent
> reason,
> > or
> > any clue in the logs. I hope that this has been fixed, but I have seen
> > other reports
> > since I initially reported it, and nothing since that reported a fix.
>
> Well, I am not expecting an application that would run 24/7.  I am working
> on
> model RR control circuits.  It does not sound like this should be an
> immediate
> problem.
>
>
> >
> > The only workaround I found was to power P1-Pin-1 and P1-Pin-7 in
> parallel,
> > in which case
> > it does not crash, but now there is no isolation between USB +5V and
> your
> > independent
> > PB power supply, and, as you are concerned about, all kinds of
> cross-feed
> > and back
> > powering can occur.
>
> That does not sound like a really good idea.
>
> Question: if the board was powered from P1-Pin-1 *and* the USB will there
> be
> problems?  Right now, that is my main concern.  Jacking in the USB (for
> file
> transfer mostly, since I can use the serial console for debugging) while
> the
> board is being powered via P1-Pin-1 is something I'd like to be able to
> do,
> but don't want to fry anything.
>
> >
> > I suggest you read the email thread "PocketBeagles are Unstable" started
> > 11/24/2017
>
> Will have a look.
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CANN_KV4OqWQ05koKPk8-bLAG7yYocYVJoN7vw_NvJNuer_7JGQ%40mail.gmail.com.

[beagleboard] Re: Pocket Beagle power question

[graham]

Robert:

It has been a while, almost a year since I did any testing with the 
PocketBeagle.
But I don't think anything has changed relative to my comments below.
Maybe someone can correct me if I am wrong, and some things have been fixed.

P1-Pin-1 is Vin, and is equivalent to the Barrel Jack input on the 
Beaglebone Black, it
is a separate power supply input, and is isolated from the microUSB 
connector power.

P1-Pin-7 is hardwired to the +5 pin on the microUSB connector, USB Port 0.
It is not clear from the schematic, but is visible if you view the PCB 
board plots.
Or check it with an Ohmmeter.

I found that the PocketBeagle, when powered exclusively by P1-Pin-1 would 
randomly
crash about once every 24 hours of operation, without any apparent reason, 
or
any clue in the logs. I hope that this has been fixed, but I have seen 
other reports
since I initially reported it, and nothing since that reported a fix.

The only workaround I found was to power P1-Pin-1 and P1-Pin-7 in parallel, 
in which case
it does not crash, but now there is no isolation between USB +5V and your 
independent
PB power supply, and, as you are concerned about, all kinds of cross-feed 
and back
powering can occur.

I suggest you read the email thread "PocketBeagles are Unstable" started 
11/24/2017

--- Graham

==


On Friday, August 9, 2019 at 2:33:15 PM UTC-5, Robert Heller wrote:
>
> If I am applying a 5V power supply to the Vin pin (P1-1) of a Pocket 
> Beagle 
> (say from an expansion board that includes a power supply), is it safe to 
> also 
> plug in a [powered] micro-USB cable? That is, does the Pocket Beagle have 
> a 
> power protection / isolation circuit? 
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1d2acd4a-1503-4d9b-8dd7-c375006884e7%40googlegroups.com.

Re: [beagleboard] Re: ENC28J60 Click on PocketBeagle

[Graham]

The programming of the MAC address in the EEPROM is not an issue, once you
are set up for it.
There are some other Ethernet connection options that you can turn on/off
at the same time.
But the program remembers what you want, and even auto-increments the MAC
address for you if you are programming in sequence within a block
assignment.
The program also does a functional exercise of all kinds of Ethernet
options, anything you have enabled, so it also constitutes a reasonable
final test for Ethernet.
Only takes 20 seconds or so.
I think you will need to pin out the USB-2 (port 1) lines, so that you can
get at them with a USB cable from the programming PC.
If the PocketBeagle plugs into your carrier board, you could build a dummy
USB connection board that temporarily replaced the PocketBeagle for
Ethernet programming.
--- Graham

==

On Mon, Aug 5, 2019 at 8:48 PM evilwulfie  wrote:

> assemble on 2 sides is no issue
> populate one side, reflow solder, populate the other side, reflow solder
> the surface tension will keep the parts on the other side IF the solder
> even melts
>
> On 8/5/2019 5:57 PM, Steven Keller wrote:
>
>
> Graham,
> Thanks so much!  That should be enough to get me started.  I wanted to
> avoid parts on the bottom of the board as it makes assembly more
> difficult.  Board size isn't too much of a problem.  The extra EEPROM
> programming step is a bit of pain but not impossible.
>
> Thanks again!
>
> On Monday, August 5, 2019 at 6:30:13 PM UTC-5, Graham wrote:
>>
>> Steven:
>> The primary reason for parts on both sides of the boards is just space
>> constraint.
>> With an extra half square inch of space, everything could be on one side.
>> I do like to keep the transient suppressor as close to the RJ-45
>> connector as possible.
>> You would still need a four layer board to do the power distribution
>> cleanly.
>>
>> In this design, the MAC address can not be assigned by the Linux driver.
>> It takes a Windows app, from the Microchip website, that needs to access
>> the LAN9500A
>> chip from both sides to program it. That is, it needs to access both the
>> USB-2 connection to the
>> LAN9500A, and have the Ethernet connection from the LAN9500A on the same
>> sub-net as the PC running the programming app. Even though the MAC
>> address is
>> held in an EEPROM, I don't think there would be any way for the user to
>> change it
>> without reproducing the programming connections.
>>
>> I am not aware that Microchip sells preprogrammed EEPROMS with the MAC
>> addresses,
>> normally you get blank EEPROMS and you supply and program the MAC
>> address.
>> Although for extra money, you can get either Microchip or some of the
>> distributors to program
>> memory parts.
>>
>> I have heard that Microchip will sell a small number of MAC addresses as
>> a courtesy,
>> but I have not done that. The normal process is to buy a block of MAC
>> assignments
>> from the IEEE which is the global coordinator.  If you buy a large enough
>> block, you get
>> your own OUI.
>>
>> --- Graham
>>
>> ==
>>
>> On Mon, Aug 5, 2019 at 3:21 PM Steven Keller  wrote:
>>
>>> Graham,
>>> If you don't mind could you answer a few questions?
>>> You have parts on both sides of the board.  Is this primarily because of
>>> the size constraint or to keep traces short as possible?
>>> Is it possible for the driver software to load the MAC address of the
>>> Beagle Bone into the LAN9500A?  It does not appear that the preprogrammed
>>> MAC address EEPROMs from Microchip work with these USB-to-Ethernet chips.
>>>
>>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/86df597a-f542-4f96-b82e-35982fa3db38%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/86df597a-f542-4f96-b82e-35982fa3db38%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/GGhpOK-i5-4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+u

Re: [beagleboard] Re: ENC28J60 Click on PocketBeagle

[Graham]

Steven:
The primary reason for parts on both sides of the boards is just space
constraint.
With an extra half square inch of space, everything could be on one side.
I do like to keep the transient suppressor as close to the RJ-45
connector as possible.
You would still need a four layer board to do the power distribution
cleanly.

In this design, the MAC address can not be assigned by the Linux driver.
It takes a Windows app, from the Microchip website, that needs to access
the LAN9500A
chip from both sides to program it. That is, it needs to access both the
USB-2 connection to the
LAN9500A, and have the Ethernet connection from the LAN9500A on the same
sub-net as the PC running the programming app. Even though the MAC address
is
held in an EEPROM, I don't think there would be any way for the user to
change it
without reproducing the programming connections.

I am not aware that Microchip sells preprogrammed EEPROMS with the MAC
addresses,
normally you get blank EEPROMS and you supply and program the MAC address.
Although for extra money, you can get either Microchip or some of the
distributors to program
memory parts.

I have heard that Microchip will sell a small number of MAC addresses as a
courtesy,
but I have not done that. The normal process is to buy a block of MAC
assignments
from the IEEE which is the global coordinator.  If you buy a large enough
block, you get
your own OUI.

--- Graham

==

On Mon, Aug 5, 2019 at 3:21 PM Steven Keller 
wrote:

> Graham,
> If you don't mind could you answer a few questions?
> You have parts on both sides of the board.  Is this primarily because of
> the size constraint or to keep traces short as possible?
> Is it possible for the driver software to load the MAC address of the
> Beagle Bone into the LAN9500A?  It does not appear that the preprogrammed
> MAC address EEPROMs from Microchip work with these USB-to-Ethernet chips.
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC_N71qynDOqbJaee0j9oW1KcUE0P%3Ds5%3DxY_VB5%2Bg0T6xk-rrg%40mail.gmail.com.

Re: [beagleboard] Re: ENC28J60 Click on PocketBeagle

[graham]

https://github.com/phrogger/PocketBeagle_Ethernet_Cape

https://oshpark.com/shared_projects/GOEnFXdS




[image: PB_LAN9500A.jpg]

--- Graham



On Saturday, August 3, 2019 at 9:11:50 PM UTC-5, Jason Kridner wrote:
>
>
> Do you have a pointer to the design files?
>  
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/527532c1-6c1e-4fb1-b5a0-955793c3b171%40googlegroups.com.

Re: [beagleboard] Re: ENC28J60 Click on PocketBeagle

[graham]

I have a working design for an Ethernet Cape for a Pocketbeagle.
It is basically the reference design for a Microchip LAN9500A implemented 
as a four layer PCB cape for the Pocketbeagle.
It talks USB-2 to the PocketBeagle, and 10/100 Ethernet to the outside 
world.
The driver is already in the Beagle software distributions, so the Beagle 
grabs it as part of the normal boot process, and it shows up as eth0.
It has the optional EEPROM that can be programmed to permanently hold a MAC 
address assignment.
I don't plan to do anything with it, so if someone wants to use it, you are 
welcome to it, but you will need to build and program them yourself.
--- Graham

On Saturday, August 3, 2019 at 7:55:13 AM UTC-5, Jason Kridner wrote:
>
>
> On Aug 2, 2019, at 10:50 PM, Steven Keller  > wrote:
>
> Okay.  Are there any other options for adding Ethernet on a carrier board 
> short of using the Octavo chip directly?
>
>
> USB to Ethernet chips. 
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/79ac2c61-38d6-44b1-be1b-e763a204935b%40googlegroups.com.

[beagleboard] Re: Ethernet module in beagle bone black

[graham]

Google for the terms Sockets, Networking, C :

https://en.wikibooks.org/wiki/C_Programming/Networking_in_UNIX

https://www.geeksforgeeks.org/socket-programming-cc/

https://www.cs.rpi.edu/~moorthy/Courses/os98/Pgms/socket.html

https://www.csd.uoc.gr/~hy556/material/tutorials/cs556-3rd-tutorial.pdf

--- Graham

On Tuesday, July 23, 2019 at 11:14:21 PM UTC-5, Megha Bhirade wrote:
>
> Hi,
>
> I am using beagle bone black board in Linux ubuntu 16.04LTS, i need to 
> work on Ethernet .
>
> requirement is like enabling Ethernet  between the Board and PC and i need 
> to send the data from PC and need to receive the data on beagle bone black 
> using Ethernet communication and once data collected that data i need to 
> pass to the other PC using Uart..
>
> Uart enabling and transmitting the data i understood...
>
> please tell me how to configure Ethernet and C program to receive the data 
> from Ethernet
>
> please suggest me any related link for this
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9b556b2f-7f3d-4449-bc3f-152440f7a212%40googlegroups.com.

Re: [beagleboard] C programing of Uart peripheral in beaglebone black (Linux)

[graham]

Linux has a universal UART driver built in called 'termios'
Depending on what you are trying to do, this might work for you.

https://en.wikibooks.org/wiki/Serial_Programming/termios

http://tldp.org/HOWTO/Serial-Programming-HOWTO/x115.html

--- Graham

==

On Thursday, July 18, 2019 at 7:54:38 AM UTC-5, Gwen Stouthuysen wrote:
>
> Check out Derek Molloy.
> http://derekmolloy.ie/beaglebone/
>
> I use his approach to drive uart communication 
>
> Gwen 
>
> Op do 18 jul. 2019 12:46 schreef Megha Bhirade  >:
>
>> Hi,
>>
>> I am using Beagle bone black board in Linux Ubuntu, i am new to BBB, i 
>> tried to check the programing of UART peripheral in the BBB..
>>
>> Exact C - programs i am not able to  found. like simple c program to 
>> initialize the UART with baud rate and other information and writing some 
>> data using buffer and i should see the data printing on to the mini com..
>>
>> please help me...
>>
>> --
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6502e49e-bb51-45c3-997f-36e470890d67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Shouldn't be this difficult. upload file

[graham]

jerry:

If your main computer is Linux, then you can cp across computers with a 
common network connection,

But if your main computer is Windows, for small to medium amounts of data 
...
I find an easy way is to cd to where you want to create the file.
then 
nano test.txt
then copy the contents of the source file in a windows text editor into the 
copy buffer
then paste it into nano inside of putty.
Control-X to exit, Yes to save

In the reverse direction, cat the text file you want to export, copy in 
putty and paste into a suitable file inside of windows.

For larger amounts of data/files, you could put on a uSD card with a FAT 
file system and mount it in either a Windows computer or a Linux, moving 
the uSD card back and forth.
Or put the files/data on a USB stick formatted with FAT file system, then 
move the USB stick back and forth.

--- Graham

==





On Monday, July 8, 2019 at 6:58:00 PM UTC-5, jerry...@gmail.com wrote:
>
>
> Connected to BBB using tty  specifically putty
>
> logged and ls -a give me directory infor.
>
> Trying to upload a file "test.txt" to the BBB from my local computer
>
> Tried all these. nothing works.  What stupid mistake am I making?
>
> Putty is running in the directory that "test.txt" resides.
> the directory testing exists in the root on the BBB.  I see it with ls -a
> I can cd to it and find no files in it. As it should be.
>
> I try unsuccessfully to upload a file to it.  What am I doing wrong?
>
> root@beaglebone:~/testing# cp test.txt test.txt
>
> cp: cannot stat 'test.txt': No such file or directory
>
>
> root@beaglebone:~/testing# cp C:\Users\Administrator\Desktop\test.txt 
> /root/testing/test.txt
>
> -bash: AdministratorDesktoptest.txt: command not found
> cp: missing destination file operand after 'C:Users'
> Try 'cp --help' for more information.
>
>
> root@beaglebone:~/testing# cp 
> 192.168.13.104:\Users\Administrator\Desktop\test.txt 
> /root/testing/test.txt
>
> cp: cannot stat '192.168.13.104:UsersAdministratorDesktoptest.txt': No 
> such file or directory
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/fe961adf-ded1-48a0-87ae-d5de1cdd1792%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone ADC

[graham]

Well, if both engines are running at the same power, then pitch.
Add an engine failure, so one at max power, the other one a "drag".
She is going to pitch, roll and yaw, all at the same time. 
Now, it is time for both the pilot and the programmer to earn their salary.

--- Graham

==

On Friday, July 5, 2019 at 10:22:21 PM UTC-5, Venkatesh Vadde wrote:
>
> I should have said of the pitch kind or roll kind of torque. Reports 
> seemed to say it nosedived, so sounds like the pitch kind. And if there was 
> a little bit of both, that is an even more complex aerodynamic stability 
> issue. 
>
>
>>> e 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3a4d4a21-5900-4139-a025-16e146039047%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: How to use peripherals of beagle bone black board

[graham]

I suggest you purchase:
Exploring BeagleBone: Tools and Techniques for Building with Embedded 
Linux, 2nd Edition
by Derek Molloy 
https://www.amazon.com/gp/product/B07MMVV65W/
Make sure you purchase the new "Second Edition", not the first.

Derek's website, with videos on many topics about Linux and Beaglebone 
programming
http://www.derekmolloy.ie/

His YouTube Channel:
https://www.youtube.com/channel/UCf_sAmhBw7Tj7-2ujmLFoQg

---
Also:

BeagleBone Cookbook: Software and Hardware Problems and Solutions 1st 
Edition
by Mark A. Yoder (Author), Jason Kridner  (Author)
https://www.amazon.com/BeagleBone-Cookbook-Software-Hardware-Solutions-ebook/dp/B00VN0DTTK

---

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4a6643c6-0f7a-4a75-b39b-feff84ffd11c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: problem with writting os image on micro SD

[Graham Haddock]

Does Etcher install the image and verify without errors?

Did you try Dennis' suggestion to hold down the boot-select button while
plugging in the USB/power cable?

--- Graham

==

On Fri, Jun 28, 2019 at 11:29 AM  wrote:

> i tried but i'm faild again. i could write any os image for example
> rasbian on uSD successfully, but i couldn't write debian for BBB.
>
> On Friday, June 28, 2019 at 6:30:37 AM UTC+4:30, Dennis Lee Bieber wrote:
>>
>> On Thu, 27 Jun 2019 14:24:10 -0700 (PDT),
>> z.mome...@gmail.com declaimed the
>> following:
>>
>> >Thank you very much for your answer! I tried to connect to BBB via putty
>> >and SSH,before. now can you tell me about connection to BBB via any
>> other
>> >way with using uSD? how can i do that? now, i write os image on uSD such
>> as
>> >you said and seems it did successful, but i gave same error "you need to
>> >format ...", now i want to eject it and plug it on BBB and connect to
>> board
>> >via other way, if it is possible. tell me about it, please.
>> >
>>
>> You connect to the BBB the same way -- the only difference is if
>> the
>> board boots using the image in the eMMC or boots using the image on the
>> SD
>> card. Recent cards (those with eMMC flashed in the last three years or
>> so)
>> should automatically boot from the SD card, otherwise you have to hold
>> down
>> the boot select button /while/ plugging in the power cable.
>>
>>
>> --
>> Wulfraed Dennis Lee Bieber AF6VN
>> wlf...@ix.netcom.com
>> http://wlfraed.microdiversity.freeddns.org/
>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/PmssrWbNcgY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/8d14aab2-3d1d-478e-9d46-73273db98966%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/8d14aab2-3d1d-478e-9d46-73273db98966%40googlegroups.com?utm_medium=email_source=footer>
> .
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CANN_KV6YgR%2BVmQ_N85g1_8pLTpt1U0OVFMeN9Bif7BFFERfx3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: problem with writting os image on micro SD

[graham]

The file as you download it is compressed in ".xz" format.
What are you using to un-compress the file to an ".img" file?

I recommend you use Etcher to install the image on the uSD card.
I don't think "Win32Diskimager" is recommended for BeagleBoards any longer.
Etcher will automatically verify the image as written is correct and 
complete, including the Linux file system.
You don't need to format it.  And for sure, do not format it after you 
write the image to the card with Etcher. That will erase the card.

Just eject it and put it in the BBB after you image it.
Make sure the card is fully seated, and not sitting sticking out on the 
eject spring.

Are you sure the BBB is good?

Do you have a good power supply running the BBB?
The high current peaks during booting require at least a 1 Amp supply, 
preferably a 1.5 Amp supply.
Too weak a power supply will cause it to hang during booting.

How old is the version of software in the Flash memory on board the BBB?
Will it boot from the on-board memory, without a uSD card installed?

--- Graham

==

On Wednesday, June 26, 2019 at 7:48:04 PM UTC-5, z.mome...@gmail.com wrote:
>
> Thanks for your answer! I'm trying to install an image on the uSD and i 
> want to run from that uSD card. i downloaded "Debian 9.5 2018-10-07 4GB SD 
> LXQT" and i tried to write that on uSD with "Win32DiskImager". I formated 
> my SD with "SD card formatter" such as  Dennis Lee Bieber said but it 
> failed  and i tried with a new SD this process, but it's failed again.I 
> don't know what to do,really!! please help me!
>
> On Wednesday, June 26, 2019 at 11:43:00 PM UTC+4:30, gra...@flex-radio.com 
> wrote:
>>
>> The message "You need to format the disk in drive E: before you can use 
>> it" means that Windows can not read the file system on the uSD card.
>> Well, Windows can not read Linux file systems, so this is OK, and you 
>> should ignore the message.
>>
>> The ".img" file and Etcher will install a Linux file system on the card.
>>
>> Are you trying to install an image on the uSD card, so that you run from 
>> the uSD card?
>> Or, are you trying to install a flasher on the uSD card so that the uSD 
>> card will install the image in the Flash memory on the BBB?
>>
>> Make sure you are using the correct image file to do what you are trying 
>> to do.
>>
>> Is Etcher providing any errors?  If so, what does it say?
>> If Etcher does not report any errors, do not reformat the card like 
>> Windows says, and just put the Etcher programmed card in the BBB and run it.
>>
>> --- Graham
>>
>> ==
>>
>> On Wednesday, June 26, 2019 at 7:53:43 AM UTC-5, z.mome...@gmail.com 
>> wrote:
>>>
>>> Hello, i have a beaglebone black board. i want to use "Debian 9.5 
>>> 2018-10-07 4GB SD LXQT" os image for it, i downloaded it from 
>>> http://beagleboard.org/latest-images/ 
>>> <http://www.google.com/url?q=http%3A%2F%2Fbeagleboard.org%2Flatest-images%2F=D=1=AFQjCNFoQN49dLQsMdU09qzUc4Nq9v3C9Q>
>>>  and 
>>> i try to write it on micro SD with "balena etcher" but it cann't write 
>>> correctly, i repeat this process over and over and i deal with "You need to 
>>> format the disk in drive E: before you can use it" any time.
>>> 14 daya ago, i did this process successfully, but my micro SD damaged 
>>> and i have to change it, after that i have above problem.
>>> i did this process with other os images, too but i had this problem, 
>>> again. 
>>> please help me! give me a solution!
>>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ef4788aa-65ca-4b77-8e55-2e1f0a3ff007%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: problem with writting os image on micro SD

[graham]

The message "You need to format the disk in drive E: before you can use it" 
means that Windows can not read the file system on the uSD card.
Well, Windows can not read Linux file systems, so this is OK, and you 
should ignore the message.

The ".img" file and Etcher will install a Linux file system on the card.

Are you trying to install an image on the uSD card, so that you run from 
the uSD card?
Or, are you trying to install a flasher on the uSD card so that the uSD 
card will install the image in the Flash memory on the BBB?

Make sure you are using the correct image file to do what you are trying to 
do.

Is Etcher providing any errors?  If so, what does it say?
If Etcher does not report any errors, do not reformat the card like Windows 
says, and just put the Etcher programmed card in the BBB and run it.

--- Graham

==

On Wednesday, June 26, 2019 at 7:53:43 AM UTC-5, z.mome...@gmail.com wrote:
>
> Hello, i have a beaglebone black board. i want to use "Debian 9.5 
> 2018-10-07 4GB SD LXQT" os image for it, i downloaded it from 
> http://beagleboard.org/latest-images/ and i try to write it on micro SD 
> with "balena etcher" but it cann't write correctly, i repeat this process 
> over and over and i deal with "You need to format the disk in drive E: 
> before you can use it" any time.
> 14 daya ago, i did this process successfully, but my micro SD damaged and 
> i have to change it, after that i have above problem.
> i did this process with other os images, too but i had this problem, 
> again. 
> please help me! give me a solution!
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/45d269a1-0be0-439d-8f4a-408babf41ced%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Delay between SPI CS and clock

[graham]

Dennis:
Be careful.  Many/most SPI slave devices use the rising edge of the CS 
line, following the write activity, to load the data and make it active.
So, you load it serially, but it is not transferred into the active control 
or output registers, until CS goes high, making it all take effect 
simultaneously.
CS is typically required, even with a single SPI slave on a bus, depending 
on how the specific SPI slave works.
--- Graham


On Monday, June 17, 2019 at 2:27:26 PM UTC-5, Dennis Lee Bieber wrote:
>
>
>
> A circuit with a single target could, in theory, have the CS line tied 
> permanently using a pull-up/pull-down resistor (since you state a falling 
> edge, I'd guess pull-down to ground would be the permanent mode). 
>
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/638422de-f63b-411c-a930-28cf743428f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BeagleBone Blue: Hack to boot when DC power is restored to DC Jack?

[graham]

Louis:

There are multiple families of a type of IC known as a Power-On reset IC, 
or supervisory reset IC

They wait for a Voltage to appear above a threshold, and remain stable for 
some period, then send a reset output for a predetermined time.

If you go to the On Semi site, and search on "Power On Reset", you will get 
hits about ten different ICs.
Check out the MAX809 as an example

TI has a selector page, see
http://www.ti.com/power-management/supervisor-reset-ic/overview.html

If you go to the On Semi site, and search on "Power On Reset", you will get 
hits about ten different ICs.
Check out the MAX809 as an example

They are generally cheap and small, and many require no support or glue 
parts other than a bypass cap, if their default Voltages and times work for 
you.

--- Graham,


>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/781fe102-9b81-4bf3-935c-49d8ee836449%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Powering beaglebone black via P9 header pins

[graham]

With everything disconnected, and a simple USB cable for power acts the 
same, points in the direction of an over current shutdown due to shorted IO 
on the BBB CPU.  

If you can RMA it and get another, I would try that.

You need to examine your application and make sure that all I/O pins are 
operated within Voltage and current limits, and the inductive "kick" from 
your stepper motor is not getting back, somehow, into the BBB I/O.

--- Graham

==

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3e9c1661-22b7-43bd-ba74-8206297b59a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Powering beaglebone black via P9 header pins

[graham]

The single blink means that the Power Management Chip is going into self 
protect.

You need to put a scope on the output of your regulator and see what is 
going on.
5.3 V will not fry the BBB.
It would run fine from a 5.3 V supply that never went above 5.5V
But it will respond the way you describe to short transients that go above 
5.5 or below 4.5.
There is also a rise time spec on the start up Voltage rise.

Or, it could mean that something else did fry the board, such as a blown 
I/O pin, which is causing an over current protect on the part of the power 
management chip.

The single blink does not tell you what is wrong, just that something is 
wrong, and the power management chip is still alive and doing its job.

--- Graham

==


On Wednesday, April 24, 2019 at 3:31:04 PM UTC-5, robpar...@gmail.com wrote:
>
> Hi There,
>
> I have been working on a project using a beaglebone black which I am 
> trying to power with a 3-cell LiPo battery. To do this, I have connected 
> the output of a hobbywing ubec 5V-3A voltage regulator to pins P9_5 and 6. 
> This seemed to work well for a while, but just now the BBB abruptly turned 
> off and will not turn back on. I have tried disconnecting everything from 
> the BBB and connecting it to my PC with the USB cable. This results in a 
> quick, faint flash of the PWR led followed by nothing. Pressing the power 
> button with the USB cable plugged in yields the same behavior. I just 
> tested the voltage regulator output and my voltmeter reads 5.3 V. My 
> understanding is that the BBB requires a well regulated 5 +- 0.25 V power 
> input. So technically my power supply is 50 mV above the limit. Is it 
> possible that I have fried the board by doing this? Is there any way to 
> recover it without buying a whole new BBB? Thanks in advance for your help!
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/81160246-a5a0-4885-9d85-3b8fcae57630%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Pin 8_44 boot interference

[graham]

No. 

The boot pin sensing is fundamental to how the processor works.
It can not boot without that function.
The proper question to ask is how do I prevent my I-O from disturbing the 
boot process.
The solution is probably something like adding transmission gates that does 
not connect your I-O until System_Reset goes high.

--- Graham

==

On Wednesday, April 10, 2019 at 8:48:04 AM UTC-5, alanmt...@icloud.com 
wrote:
>
>
> Hi All...
>
> I use pin 8_44 for digital input to the PRU.  For those new to this issue, 
> that is one of several pins that can change the boot behavior of the BBB, 
> but the bottom line is that it should not be connected on startup.  I 
> didn't know that when I started my project, but it wouldn't have made a 
> difference in my selection since input/output to the PRUs is fundamental to 
> what I need to do and I would use any PRU pin I can get access to.
>
> Currently, I have to disconnect the BBB every time I reboot the 
> Beaglebone.  This was not a problem at first, but now I use the device 
> remotely quite a lot, and sometimes I have to reboot the entire PC that is 
> local to the Beaglebone.  I've tried rearranging the circuitry, but because 
> I use a protection diode to allow >3.3V as a digital input, I have been 
> unable to find a balance between high enough impedance to prevent boot 
> issues and low enough to consistently recognize the digital inputs I need 
> to measure.
>
> Is there a simple way to disable the feature that looks for boot options 
> on this pin (and any others)?
>
> Thanks so much,
>
> Alan
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c2648207-2100-4d5c-a0f4-9d09dc7a8fd6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Pin 8_44 boot interference

[Graham]

The CPU requires that function to boot.

The question you should be asking is how do you design your circuit, so 
that it does not interfere with the boot process.

Probably would require something like a transmission gate that does not 
connect your circuit to the pin until the System_Reset line goes high.

--- Graham

==

On Wednesday, April 10, 2019 at 8:48:04 AM UTC-5, alanmt...@icloud.com 
wrote:
>
>
> Hi All...
>
> I use pin 8_44 for digital input to the PRU.  For those new to this issue, 
> that is one of several pins that can change the boot behavior of the BBB, 
> but the bottom line is that it should not be connected on startup.  I 
> didn't know that when I started my project, but it wouldn't have made a 
> difference in my selection since input/output to the PRUs is fundamental to 
> what I need to do and I would use any PRU pin I can get access to.
>
> Currently, I have to disconnect the BBB every time I reboot the 
> Beaglebone.  This was not a problem at first, but now I use the device 
> remotely quite a lot, and sometimes I have to reboot the entire PC that is 
> local to the Beaglebone.  I've tried rearranging the circuitry, but because 
> I use a protection diode to allow >3.3V as a digital input, I have been 
> unable to find a balance between high enough impedance to prevent boot 
> issues and low enough to consistently recognize the digital inputs I need 
> to measure.
>
> Is there a simple way to disable the feature that looks for boot options 
> on this pin (and any others)?
>
> Thanks so much,
>
> Alan
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ee1c84b8-265e-49dc-a09b-6c44992a0317%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: [EXTERNAL] Re: Industrial Beagle Bone Black damages SD cards.

[Graham]

 

> I happened to run across this series of articles yesterday.
>
If you are wearing out the cards, due to frequent writes driven by logging, 
here is a way to reduce the write transactions.
Although written for a similar sounding problems on a Raspberry Pi, the 
underlying solution was written for generic Debian.


https://mcuoneclipse.com/2019/04/01/log2ram-extending-sd-card-lifetime-for-raspberry-pi-lorawan-gateway/

https://github.com/azlux/log2ram

A transient /var/log:
https://debian-administration.org/article/661/A_transient_/var/log

==

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/562f1c62-d8c3-4f3c-a8dd-3228eba1eab1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: gig ethernet

[graham]

Is that a POE switch? Or a POE port being used on the switch.
That could make bad things happen.
I run all my Beagles on a Cisco Gb managed switch without problems.
Of course they negotiate back to 100 Mb.
--- Graham

== 

On Wednesday, March 20, 2019 at 4:04:15 PM UTC-5, Wulf Man wrote:
>
> Has anybody had any issues connecting a beaglebone to a gig switch ? 
> We plugged a unit into a trendnet 4 port gig switch and the beaglebone 
> does a reboot over and over. I traced it to R137 connecting ethernet port 
> pins 5 and 4 to VDD_PHYA which is the beaglebone VDD_3V3B through an 
> inductor 
> shorting out the supply. 
>
> It seems to me that the switch should not do this. 
> Unfortunately the unit is 2000 miles away. 
>
> any thoughts ? 
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c745c365-52f4-4511-83ba-95b05bd8a6ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: How to use GPIO as spi chipselect.

[graham]

You can not have the SPI hardware manage one of the SPI chip select lines, 
and you bit-bang the other.
Either you let the SPI hardware manage both of them, which you can not do 
in this case, because of assignment conflict, or you must bit-bang both of 
the CS lines.
So, set it up as a single generic SPI driver, and pick any two GPIO pins 
for chip-select lines.
One of them could be the same pin as CS0, just configured as a GPIO pin.
You will need to write a little wrapper for the SPI call, that drops the 
appropriate CS line, before you write to the SPI hardware.
You will need to raise the appropriate CS line when the SPI hardware is 
done sending.
DO NOT send your last data to the SPI hardware and immediately raise the CS 
line.
The SPI hardware is a parallel to serial device, and will still be sending 
data for some time after the data is written to it to send.
--- Graham

==

On Saturday, March 16, 2019 at 11:18:57 PM UTC-5, Dave wrote:
>
> I am working on a board that is derived from a Pocket Beagle. 
>
> It has two max81355 SPI Thermocouples on SPI0. 
>
> The first uses spi0_cs0 as a chip select. 
>
> spi0_cs1 is used for mmc.cd so that can not be used for the second. 
>
> The hardware designer used spio_d1(MOSI) set as a GPIO for the 2nd chip 
> select. 
>
> I have no clue how to set the device tree entry for that.
>
> This is what I have - which I do not think can work.  
>
> fragment@1 {
> target = <_pinmux>;
> __overlay__ {
> pb_spi0_pins: pinmux_pb_spi0_pins {
> pinctrl-single,pins = <
> /* SPI0_SCLK STATUS:WORKS ??? */  
> AM33XX_IOPAD(0x0950, PIN_OUTPUT_PULLUP | INPUT_EN | MUX_MODE0 )  /* A13 
> P1.08  SPI0_SCLK 0x150 GPIO2 GPIO0_2 SCLK */
> /* SPI0_DO STATUS:WORKS ??? */  
> AM33XX_IOPAD(0x0954, PIN_OUTPUT_PULLUP | INPUT_EN | MUX_MODE0 )  /* B13 
> P1.10  SPI0_D0   0x154 GPIO3 GPIO0_3 MISO */
> /* SPI0_D1 STATUS:UNKNOWN */  
> AM33XX_IOPAD(0x0958, PIN_OUTPUT_PULLUP | INPUT_EN | MUX_MODE7 ) /* B14 
> P1.12  SPI0_D1   0x158 GPIO4 GPIO0_4 TC1 */
> /* SPI0_CS0 STATUS:WORKS ??? */  
> AM33XX_IOPAD(0x095c, PIN_OUTPUT_PULLUP | INPUT_EN | MUX_MODE0 ) /* A14 
> P1.06  SPI0_CS   0x15c GPIO5 GPIO0_5 TC0 */
> >;
> };
> };
> };
> fragment@2 {
> target = <>;
> __overlay__ {
> #address-cells = <1>;
> #size-cells = <0>;
>
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <_spi0_pins>;
> ti,pio-mode; /* disable dma when used as an overlay, dma gets stuck at 160 
> bits... */
>
> channel@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "spidev";
> reg = <0>;
> spi-max-frequency = <430>;
> spi-cpha;
> };
>
> channel@1 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "spidev";
> reg = <1>;
> spi-max-frequency = <430>;
> };
> };
> };
>
>
>
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ce3cba45-0bf3-48fe-9fc7-ff2c0d41f61f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Beaglebone AI

[Graham]

https://beagleboard.org/ai

Hmm.

--- Graham

==

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d625e6d8-c1a7-4509-9c86-2c1c2ba011a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: operating system on eMMc or on Sdcard

[Graham]

If you want the "console version" corresponding to the "official release"
version (Debian 9.5 10-7-2018), you can look here:

https://debian.beagleboard.org/images/rcn-ee.net/rootfs/bb.org/testing/2018-10-07/stretch-console/

I don't know how official is it, but it works fine.

--- Graham



On Fri, Mar 1, 2019 at 8:31 AM Robert Nelson 
wrote:

> On Fri, Mar 1, 2019 at 3:03 AM Chris Green  wrote:
> >
> > Graham  wrote:
> > > There are three versions of the release package.
> > > The lxqt version is slightly less than 4 GB total, and should only be
> used
> > > if you want everything, including the video drivers.
> > > the IoT Version removes the video drivers and associated packages, but
> > > leaves everything else, and is about 2 GB
> > > The "console" version is the smallest, is Debian plus console and
> minimum
> > > BBB packages, and is only about 1 GB, but then you can add in only
> what you
> > > need.
> > >
> > However it seems to me that it's often difficult to find the
> > current/latest console version.  It's what I use for preference
> > because I run my BBBs headless and access using ssh.  Just about all
> > the software I need is in the base system (Python) and scripts I write
> > myself.  Since I have a couple of 2Gb BBBs the console version is
> > *very* useful!
> >
> > The standard download sources often seem to have only LXQT and IOT
> > versions.
>
> Alternative un-offical images are listed here:
>
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/era_9yNBk_M/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYiuns%3DgtqFZaxYz8Any9ZFkY_ftJU8tSi4vh1xW%3DTxYiQ%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC_N71oEV%3Db6SK_0mBdTp%2BAv0M%3DUKAOALCTWbUt%3DT3zr%3DqhN0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

RE: [beagleboard] BBB: bare metal programming in C - what is need on the SD card?

[Graham Stott]

Ok, no problem.

 

I am actually using a combination of Ti starterware and FreeRTOS and I am using 
a number of FreeRTOS device drivers.

 

Graham 

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of psk.kd.whitfi...@gmail.com
Sent: Thursday, February 28, 2019 9:07 AM
To: BeagleBoard 
Subject: Re: [beagleboard] BBB: bare metal programming in C - what is need on 
the SD card?

 

No I don't release my code to the public. Starterware has SD examples but they 
don't work well. You could make improvements to it to make it work better.

On Tuesday, February 26, 2019 at 8:37:32 AM UTC-8, Graham Stott wrote:

Have you release any of your code for other to use? I would be interested in 
the SD driver.

 

Graham

 

From: beagl...@googlegroups.com   
[mailto:beagl...@googlegroups.com  ] On Behalf Of 
psk.kd.w...@gmail.com  
Sent: Tuesday, February 26, 2019 1:49 AM
To: BeagleBoard  >
Subject: Re: [beagleboard] BBB: bare metal programming in C - what is need on 
the SD card?

 

Bare-metal is always going to out-perform linux and even an RTOS if done right. 
For beaglebone aka AM335x, start with Starterware. Over the past 3.5 years of 
working with beaglebone, I've developed a bare metal bootloader that enumerates 
eMMC over USB allowing you to drag and drop your MLO and app file directly. I 
have also written SD, USB device, usb host...etc drivers from scratch and 
benchmark this against similar functionality using linux (latest Debian) and my 
projects always get at least 2x the performance. For real-time stuff, linux 
just doesn't suffice even when using PRUs. For instance, USB MSC with linux 
only gets ~8 MB/s for moving large files, I get ~18MB/s on average. Boot time 
is also insanely fast when done right with bare metal projects. I boot in 
~2.2mS right now. I want to see Linux do that. However, like everyone is 
saying, its only worth bare-metal programming the beaglebone if you have the 
patience and time to do these projects. Otherwise, save frustration and use 
linux and get something working in hours instead of months.

 

To boot 

On Tuesday, June 7, 2016 at 3:03:45 PM UTC-7, john3909 wrote:

One thing to be aware of is the CortexA8 doesn’t perform very well if you don’t 
have Data and Instructions Cache enabled and you also have to have the MMU 
configured and enabled. For example, toggling a GPIO in Starterware with no 
Cache or MMU enabled, I get about 120KHz but if I enable both Cache and MMU, I 
get just over 12MHz. 

 

Regards,

John

 

 

 

 

On Jun 6, 2016, at 11:48 PM, 'dd' via BeagleBoard mailto:beagl...@googlegroups.com> > wrote:

 

hi reinhardt.  i know what u r going thru.  i got a minimal standalone bare 
metal system up.  see www.baremetal.tech <http://www.baremetal.tech> 
or github.com/ddlawrence <http://github.com/ddlawrence> 

u made good progress, i hope u haven't lost interest.  i did it without ti 
tools whatsoever, so we have a fresh start.  
get involved, i need help!  we can subdue this beast and make the bbb into a 
hotrod.  
hack on...dd


On Thursday, October 23, 2014 at 2:00:51 PM UTC+3, reinhar...@gmail.com 
<http://gmail.com>  wrote:

Hello,

thanks to the people who want to be helpful, but I really have to tell you that 
it is not easy to start (bare-metal programming) 
with BBB.
Here are some of the troubles I ran into:

1.) Simple bare-metal from SD-card:
I installed the patch for starterware, when it was available for download again,
formatted a SD-card as descriped and put the new MLO file (which should work 
for BBB now) and the app file on it.
Inserted the SD-card into the BBB's slot and booted by holding down the boot 
button while powering.
Nothing happens: No LEDs, no communication on the serial port.

2.) PRU programming:
I do understand that the main core is not intended for real-time programming,
so I try to do it on one of the PRUs, but XDS100v2 does not even connect to a 
PRU:
"The project ... is not compatible with any CPU in the target configuration."

3.) Emulation problems:
XDS100v2:
"Error connecting to the target: (Error -1266 @ 0x0)".
Now one must figure out that he has to press Cancel (!) and wait about 8 
seconds -->
all of a sudden the emulator has got connection to the board and can execute 
the code.

4.) Documentation:
I spent 2 weeks on reading articles and documentations and most of the time I 
was a permanent
reader on forums. Often you find people who have exactly the same problems, but 
no solutions are
provided or the solution proposed did not work in my case.
I use CCS6 but what you find on the internet is for earlier versions, e.g., if 
you want to go through a tutorial
step-by-step, you are soon stuck, as you can't find the settings in CCS6, which 
are shown for CCS5...

Are there people around, who are successfully doing bare-metal programming in C?





Am Dienstag, 21. Oktober 2014 18:40:00 UTC+2 schrieb Jason Kridner:

 

[beagleboard] Re: operating system on eMMc or on Sdcard

[Graham]

Very close.

The Os itself is not what takes up all the space. The Os itself is less 
than 1 GB.
Everything else is application software, and languages.
There are three versions of the release package.
The lxqt version is slightly less than 4 GB total, and should only be used 
if you want everything, including the video drivers.
the IoT Version removes the video drivers and associated packages, but 
leaves everything else, and is about 2 GB
The "console" version is the smallest, is Debian plus console and minimum 
BBB packages, and is only about 1 GB, but then you can add in only what you 
need.

The space in the uSD card, and the EMMC have to be mounted separately, so 
not be used as single memory space, but both are accessible from either Os 
on SD or EMMC.



--- 

On Thursday, February 28, 2019 at 11:04:18 AM UTC-6, Henry van Gestel wrote:
>
> Hai,
>
> I understand that you can either install Os (example debian) onto eMMC 
> through the SDcard and boot from the eMMC 
>
> *OR*
>
> boot from the Sdcard
>
> In choise 1 
> If the loaded Os is very big, you don't have hardly any space left on eMMC 
> to load additional software.
>
> choise2
> Then you have to use the SDcard to boot from which is by example 16 Gb, 
> then you have enough space left.
> *in this last case the eMMC is not used.*
>
> Am I right or do I understand it wrong.
>
> In my opinion there is no way to extend the eMMC with sdcard memory to 
> increase this space.
>
> rgds
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cb1503fd-9c68-46c6-996d-5c5e867bd065%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [beagleboard] BBB: bare metal programming in C - what is need on the SD card?

[Graham Stott]

Have you release any of your code for other to use? I would be interested in 
the SD driver.

 

Graham

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of psk.kd.whitfi...@gmail.com
Sent: Tuesday, February 26, 2019 1:49 AM
To: BeagleBoard 
Subject: Re: [beagleboard] BBB: bare metal programming in C - what is need on 
the SD card?

 

Bare-metal is always going to out-perform linux and even an RTOS if done right. 
For beaglebone aka AM335x, start with Starterware. Over the past 3.5 years of 
working with beaglebone, I've developed a bare metal bootloader that enumerates 
eMMC over USB allowing you to drag and drop your MLO and app file directly. I 
have also written SD, USB device, usb host...etc drivers from scratch and 
benchmark this against similar functionality using linux (latest Debian) and my 
projects always get at least 2x the performance. For real-time stuff, linux 
just doesn't suffice even when using PRUs. For instance, USB MSC with linux 
only gets ~8 MB/s for moving large files, I get ~18MB/s on average. Boot time 
is also insanely fast when done right with bare metal projects. I boot in 
~2.2mS right now. I want to see Linux do that. However, like everyone is 
saying, its only worth bare-metal programming the beaglebone if you have the 
patience and time to do these projects. Otherwise, save frustration and use 
linux and get something working in hours instead of months.

 

To boot 

On Tuesday, June 7, 2016 at 3:03:45 PM UTC-7, john3909 wrote:

One thing to be aware of is the CortexA8 doesn’t perform very well if you don’t 
have Data and Instructions Cache enabled and you also have to have the MMU 
configured and enabled. For example, toggling a GPIO in Starterware with no 
Cache or MMU enabled, I get about 120KHz but if I enable both Cache and MMU, I 
get just over 12MHz. 

 

Regards,

John

 

 

 

 

On Jun 6, 2016, at 11:48 PM, 'dd' via BeagleBoard  > wrote:

 

hi reinhardt.  i know what u r going thru.  i got a minimal standalone bare 
metal system up.  see www.baremetal.tech <http://www.baremetal.tech> 
or github.com/ddlawrence <http://github.com/ddlawrence> 

u made good progress, i hope u haven't lost interest.  i did it without ti 
tools whatsoever, so we have a fresh start.  
get involved, i need help!  we can subdue this beast and make the bbb into a 
hotrod.  
hack on...dd


On Thursday, October 23, 2014 at 2:00:51 PM UTC+3, reinhar...@gmail.com 
<http://gmail.com>  wrote:

Hello,

thanks to the people who want to be helpful, but I really have to tell you that 
it is not easy to start (bare-metal programming) 
with BBB.
Here are some of the troubles I ran into:

1.) Simple bare-metal from SD-card:
I installed the patch for starterware, when it was available for download again,
formatted a SD-card as descriped and put the new MLO file (which should work 
for BBB now) and the app file on it.
Inserted the SD-card into the BBB's slot and booted by holding down the boot 
button while powering.
Nothing happens: No LEDs, no communication on the serial port.

2.) PRU programming:
I do understand that the main core is not intended for real-time programming,
so I try to do it on one of the PRUs, but XDS100v2 does not even connect to a 
PRU:
"The project ... is not compatible with any CPU in the target configuration."

3.) Emulation problems:
XDS100v2:
"Error connecting to the target: (Error -1266 @ 0x0)".
Now one must figure out that he has to press Cancel (!) and wait about 8 
seconds -->
all of a sudden the emulator has got connection to the board and can execute 
the code.

4.) Documentation:
I spent 2 weeks on reading articles and documentations and most of the time I 
was a permanent
reader on forums. Often you find people who have exactly the same problems, but 
no solutions are
provided or the solution proposed did not work in my case.
I use CCS6 but what you find on the internet is for earlier versions, e.g., if 
you want to go through a tutorial
step-by-step, you are soon stuck, as you can't find the settings in CCS6, which 
are shown for CCS5...

Are there people around, who are successfully doing bare-metal programming in C?





Am Dienstag, 21. Oktober 2014 18:40:00 UTC+2 schrieb Jason Kridner:

 

 

On Mon, Oct 20, 2014 at 9:23 AM, mailto:reinhar...@gmail.com> > wrote:

Hello,

after nearly 2 weeks of struggling my first LED blinking works under the 
following constitution:
-) Beaglebone black, Element14, rev.C
-) no OS --> holding "boot" button, when powering
-) Code Composure Studio v6
-) Starterware (without BBB patch:
http://software-dl.ti.com/dsps/dsps_public_sw/am_bu/starterware/latest/index_FDS.html
 (DOES NOT WORK AT THE MOMENT)
-) XDS100v2 emulator

1.) 
The maximum frequency for toggling the pin is 1.6 MHz,
but I need maximum speed. 
In my understanding there is still a speed decrease as the system is running in 
emulation mode.
Correct?

 

I don't

Re: [beagleboard] Flashing a BBB with debian

[graham]

Run it from the plug in card?
Plug in the size you need.
Expand the installed image to make the whole card available to you.
--- Graham

==

On Saturday, February 23, 2019 at 2:22:13 PM UTC-6, aa...@cnccraft.co.uk 
wrote:
>
> Yes you were right. I now finally have a debian jessie system on my device 
> (crumbs that was difficult), but I would like a gui.  I have tried to 
> install ldxe core, but it tells me I don't have room.  Is there a 
> solution\/ I would like a a graphical interface.
> Thanks for all your replies
>
> On Friday, 22 February 2019 14:54:37 UTC, RobertCNelson wrote:
>>
>> On Fri, Feb 22, 2019 at 3:32 AM  wrote: 
>> > 
>> > 
>> > 
>> > On Thursday, 21 February 2019 21:42:53 UTC, RobertCNelson wrote: 
>> >> 
>> >> On Thu, Feb 21, 2019 at 3:38 PM  wrote: 
>> >> > 
>> >> > I am finding it impossible to flash an old BBB with debian.  I 
>> download images from the beagle website copy it to a disk with Etcher, edit 
>> the the uEnv.txt file with  'sudo nano '/media/aaron/rootfs/boot/uEnv.txt' 
>> press the little power button and plug in a power lead, but I get no 
>> flashing lightsnothing. 
>> >> > I have sucessfuly flashed and used Angstrom, but it seems a bit 
>> limited. 
>> >> > Also, I am trying to use syncloud but with absolutely no success. 
>> >> > Can somebody pleas tell me where I am going wrong 
>> >> 
>> >> Since you flashed an old version of Angstrom, you better follow the 
>> > 
>> > 
>> > 
>> > 
>> > I have tried that many many times and I get no lights flashing at all. 
>> If I power up without pressing the boot button I get 3 blue led's on 
>> constant... no flashing 
>> >> 
>> >> offical directions: 
>> >> 
>> >> 1: Using your thumb nail, push and hold the boot button down. 
>> >> 2: Plug in 5Volt DC jack 
>> >> 3: Wait till 4 led's turn on 
>> >> 4: Lift thumb nail.. 
>>
>> Okay, if the above 4 step procedure doesn't work, sadly that leaves a 
>> couple options. 
>>
>> You actually didn't follow that procedure 
>> The image is corrupt. 
>>
>> So try it again after reflashing the microSD. 
>>
>> If it still doesn't work, grab a serial cable: 
>>
>> https://elinux.org/Beagleboard:BeagleBone_Black_Serial 
>>
>> and get me the serial boot log for debugging.. 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> https://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.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d650656d-4c72-4434-ac43-5b36205687d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: On BBB - How to use I2C-1 ? It exists but maybe needs pins setup ? BBB Rev C & Debian 9

[graham]

I2C-1 is used for internal power management and on board EEPROM access 
purposes.
Unless you have a specific need, I suggest you use I2C-2 for external 
control purposes.
It is already pinned-out by default on P9-17 and P9-18
--- Graham

==

On Monday, February 18, 2019 at 1:22:57 PM UTC-6, bruce...@yahoo.com wrote:
>
> On Beaglebone Black (BBB) - How to use I2C-1 ? It exists but maybe needs 
> pins setup ? BBB Rev C & Debian 9.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/bb3f0287-ad99-4ccb-9481-965cca177611%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [beagleboard] Powering Beaglebone Blue off a 4s battery 14.8V

[Graham Stott]

The battery at the link you provided has a TX60 connector for the power leads.  
I do not know where you are located but you could order the following from 
Pololu and make a cable that splits the power with a pair (red and black) going 
to a new TX60 connector which mates with your drone motors and the other pair 
(Red and black) going to the DC barrel Plug. The center pin is the positive 
(Red).

 

DC Barrel Plug – part 2448 - https://www.pololu.com/product/2448

XT60 Connector – part 2158 or 2175 - https://www.pololu.com/product/2175

 

Graham

 

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Adrian Godwin
Sent: Wednesday, February 13, 2019 12:34 PM
To: beagleboard@googlegroups.com
Subject: Re: [beagleboard] Powering Beaglebone Blue off a 4s battery 14.8V

 

The charge balance connectors are typically JST PH connectors on a 0.1" pitch 
(though might be 2mm  - it think that's JST XH). They bring out the two ends of 
the battery pack (the same as the high current connector) and every junction 
between cells. So the 2s charger on the BBBlue has 2+1 pins and the 4s 
connector on your battery has  2+3 pins. 

The outer pins, if connected to the BBBlue, will provide 14.8 - 16.8V and this 
might be OK to power the BB although it will not be able to charge it correctly 
using the charge balance wiring. I'm not entirely certain that it will be OK - 
the DC jack is rated to 18V but the charge connector is only expected to supply 
8.4V to the pack and may not tolerate the 4s pack. 

Since you aren't able to charge it that I would think it would be safer to use 
the DC jack as Graham says, though you will need to fix the connector in as 
they won't stand much vibration and it's likely to fall out during flight.

You will need a wiring harness to connect the heavy current output from the 
lipo pack to the motor controllers. You may be able to buy this ready made and 
add a wire to supply power to the BBBlue (it might already have a controller 
power connection, or the speed controllers might have a 5V output for it). If 
you make it up from individual connectors, the part for the battery pack is 
called a TX60 (or the larger TX80)  and is easily available from ebay or 
quadcopter supply sources. The same connector is probably used on the motor 
controllers, or they might be fitted with one of the other standards. Quite 
often they have no connectors fitted as there are a number of different options 
alongside TX60.



 

On Wed, Feb 13, 2019 at 8:09 PM mailto:timmcgi...@gmail.com> > wrote:

I am a bit unsure on how to connect the 4s battery to the dc jack. It is using 
the battery connector found on this jack 
https://www.unmannedtechshop.co.uk/product/tattu-1800mah-14-8v-45c-4s1p-lipo-battery-pack/.
 Is there some component I can by which I can solder on the end of the battery 
leads to go to a dc jack I can connect to the beaglebone blue?

On Wednesday, 13 February 2019 02:05:29 UTC, Graham Stott wrote:

Are you expecting to also charge the battery using the Beaglebone Blue?  If 
not, why not connect the battery to the DC jack input?

 

Graham

 

From: beagl...@googlegroups.com <mailto:beagl...@googlegroups.com>  
[mailto:beagl...@googlegroups.com] On Behalf Of timmc...@gmail.com 
<mailto:timmc...@gmail.com> 
Sent: Tuesday, February 12, 2019 12:48 PM
To: BeagleBoard mailto:beagl...@googlegroups.com> >
Subject: [beagleboard] Powering Beaglebone Blue off a 4s battery 14.8V

 

I am planning to use a Beaglebone Blue in a drone that I am building. The drone 
motors need a 4s battery which runs at 14.8V however the connector for a 
battery on the Beaglebone Blue seems to only support a 2s battery which 
operates at 7.4V. How would you recommend running the Beaglebone Blue off a 4s 
battery? If needed we are able to solder components together.

-- 
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 <mailto:beagleboard...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b06db982-88de-4218-bd5a-3450bab249ca%40googlegroups.com
 
<https://groups.google.com/d/msgid/beagleboard/b06db982-88de-4218-bd5a-3450bab249ca%40googlegroups.com?utm_medium=email_source=footer>
 .
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/

[beagleboard] Re: How can I free-up the addresses 0x54-57 on I2C bus 2 on my Beaglebone Black ?

[Graham]

Search for the following two discussion topics on this forum:

BBB without reserved I2C addresses  (Apr 17 2017)

Set up Cape's EEPROM i2c-2 BeagleBoneBlack Rev-C

--- Graham



On Wednesday, February 13, 2019 at 6:51:41 AM UTC-6, bruce...@yahoo.com 
wrote:
>
> How can I free-up the addresses 0x54-57 on I2C bus 2 on my Beaglebone 
> Black ?  I can only access the lower half addr 0x50-53; the upper ones 
> 0x54-57 show 'UU' when using i2cdetect.  I need them for addressing the 
> entire contents of a 24C16 I2C EEPROM.  Or if not possible then how else 
> can I control I2C at the range 0x50-57 ?  Another bus ?  bud 12 doesn't 
> seem to work.  Perhaps a bit-banged bus ?  Bought board last year and have 
> recent Debian distro on it.  
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/65b4e212-a0c0-421d-b501-933581117fac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [beagleboard] Powering Beaglebone Blue off a 4s battery 14.8V

[Graham Stott]

Are you expecting to also charge the battery using the Beaglebone Blue?  If 
not, why not connect the battery to the DC jack input?

 

Graham

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of timmcgi...@gmail.com
Sent: Tuesday, February 12, 2019 12:48 PM
To: BeagleBoard 
Subject: [beagleboard] Powering Beaglebone Blue off a 4s battery 14.8V

 

I am planning to use a Beaglebone Blue in a drone that I am building. The drone 
motors need a 4s battery which runs at 14.8V however the connector for a 
battery on the Beaglebone Blue seems to only support a 2s battery which 
operates at 7.4V. How would you recommend running the Beaglebone Blue off a 4s 
battery? If needed we are able to solder components together.

-- 
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b06db982-88de-4218-bd5a-3450bab249ca%40googlegroups.com
 
<https://groups.google.com/d/msgid/beagleboard/b06db982-88de-4218-bd5a-3450bab249ca%40googlegroups.com?utm_medium=email_source=footer>
 .
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/006f01d4c340%2491dadcf0%24b59096d0%24%40comcast.net.
For more options, visit https://groups.google.com/d/optout.

RE: [beagleboard] PB LCD

[Graham Stott]

Dave,

 

I presume by PB you mean Pocketbeagle.

 

Assuming the above and looking at the .dts file, I do not think this will work. 
I could easily be wrong, but the way I read the .dts file, you are trying to 
use the LCD output pins from the am335x (mode 0). On the Pocketbeagle those 
pins do not go to any connector output pins (P1 or p2).  You said a PB derived 
board, so maybe on that board the LCD pins do go to the output pins but I 
cannot tell without seeing a copy of that board’s schematic.

 

Graham

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Dave
Sent: Sunday, February 10, 2019 1:21 AM
To: BeagleBoard 
Subject: [beagleboard] PB LCD

 

I am trying to get an LCD - the same one as the 4.3" CAPE working on a PB 
derived board. 

Everything is hooked up the same. 

I have copied  BB-CAPE-DISP-CT4-00A0.dts

and changed the pins to match PB

It is loading but no display, no backlight. 

-- 
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 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3ff8ede7-1970-4701-8e1d-e7e04c13a6f7%40googlegroups.com
 
<https://groups.google.com/d/msgid/beagleboard/3ff8ede7-1970-4701-8e1d-e7e04c13a6f7%40googlegroups.com?utm_medium=email_source=footer>
 .
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/002601d4c16e%24fc269fa0%24f473dee0%24%40comcast.net.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Question regarding Custom Board based on BeagleBone Blac

[graham]

I think the answers to 1, 2, and 3 have all been asked and answered before 
on this email reflector.
A little bit of searching for appropriate keywords  will get you the 
answers to those.


For number 4, you are confusing survival (non-operating) with operating 
conditions.
Read the footnotes to the "Absolute Maximum Ratings" chart. they are 
important.

If you go outside of the "Recommended Operating Conditions" chart supply 
voltages of 4.3 to 5.8 Volts, the TPS65217C goes into an emergency shutdown 
to protect itself and the CPU.
So if you want to run from 10 to 15 Volts power, you will need an external 
buck-converter or other step down power supply ahead of the TPS65217 to 
feed it 5 Volts.

--- Graham

==

On Thursday, January 31, 2019 at 12:32:55 PM UTC-6, 
omair...@saikosystems.com wrote:
>
>
> Hello Everyone,
>
> I tried to post this yesterday and got a brief "Your discussion has been 
> posted" message, but then later could not find the post, so sorry if it 
> gets double posted.
>
> I'm looking into creating a custom board for a client based on the 
> BeagleBoard Black and had a few questions. I will be creating the hardware 
> design and the client will handle all the software requirements. Almost the 
> whole BBB will get replicated, with the exception of the HDMI and perhaps 
> the Ethernet (both of which are not used in their application). Some of 
> these questions are geared towards software, but I want to make sure that 
> all the bases are covered and I can point the clients down the correct path 
> in bringing up the new board. Any feedback from those who have endeavored 
> on this path before is greatly appreciated.
>
>
>1. I understand the BeagleBoards come pre-programmed with a Linux 
>kernel and U-Boot, however, new chips we purchase from the factory will be 
>black. What is the method for first programming of the blank chips? Can it 
>be done via the USB Client port or MicroSD?
>
>2. I understand there's an EEPROM on board that contains board 
>identification information, which is used by the Kernel and U-Boot to 
> setup 
>and boot the board correctly. What areas need to be modified to bring up a 
>board that does not contain the EEPROM, or contains a blank EEPROM?
>
>3. The SRM mentioned that some of the TPS65217C power rails had been 
>modified to 1.5V instead of 1.8V. Where is this set? I'm guessing this is 
>done in software and somewhat related to question 2.
>
>4. The device needs to be powered by an unregulated 12v supply and be 
>able to withstand 10v - 14.5v. The TPS65217C datasheet indicates it can 
>support a supply voltage range of -0.3V to 20V, however, the recommended 
>operating supply voltage is 4.3V - 5.8V. Has anyone used the chip outside 
>of the recommended supply voltage, and were there any issues?
>
>
> Thank you in advance for any feedback.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d8a017f0-dc5b-4337-a129-ae420412fe78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: GPIO Riding Edge Interrupt w/ Time Stamp

[Graham]

Thomas:

If you are interested in the PRU, download Professor Yoder's (free) book 
from:

https://markayoder.github.io/PRUCookbook/

The PRU is a small real time processor running at a clock speed of 200 MHz, 
derived from the main clock tree in the BBB.
So, you won't get resolution of 200 MHz clock, but something more like the 
time of the fastest loop running on a dedicated 200 MHz processor that will 
count and report what you are looking for, so if the loop was 20 
instruction clock cycles long, you could get 10 MHz or 100 ns resolution.

Dennis also makes a good suggestion, in that there are "capture timer" pins 
on the BBB that I have seen used for capturing/time-stamping GPS 1PPS 
signals, for use in an NTP server.
I am not aware of any python drivers but if you are capable in "C", there 
is sample code around to run those pins in "capture timer" mode in "C".

The TICC will do exactly what you described, you can control it from Python 
running on the BBB as a (USB) serial slave peripheral. But it is another 
$190. You will also need a reasonably precise 10 MHz reference for it. 
Either your lab reference, or you can buy another kit called the "Pulse 
Puppy" from the same people that sell the TICC.

--- Graham

==


>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6b364a7f-75bd-4f3f-98b6-d4644954c955%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] GPIO Riding Edge Interrupt w/ Time Stamp

[Graham]

Thomas:

You are at the limit of a combination of the OS and Python response time.

I think you will also find that the absolute accuracy of the internal time 
base in the BBB, set by timesyncd (or optionally ntpd) will meander +/- ten 
milliseconds across several hours. 
(Put the 1PPS output from a GPS into the port and plot what happens to the 
time stamps over a 24 hour period.)

Depending on your requirements, I suggest you consider something like a 
"TICC" for the edge timing capture, it will provide a serial stream with 
the time stamps, easily read by the BBB via the USB port, that has relative 
accuracy into the 100 ps range, and absolute time a function of the 10 MHz 
reference signal you give it.

https://tapr.org/kits_ticc.html

Your other alternative is to write some code for the PRU's that can do edge 
capture in real-time, then hand off the results to the BBB main cpu.

So, depends on your need to trade off money versus your time.

--- Graham

==





On Wednesday, January 30, 2019 at 3:05:23 PM UTC-6, Thomas Remmert wrote:
>
> Hi Robert, 
> Thanks for the quick reply.  I am already using a custom overlay and 
> using the PPS/GPS tools... 
>
> trying PPS source "/dev/pps0" 
> found PPS source "/dev/pps0" 
> ok, found 1 source(s), now start fetching data... 
> source 0 - assert 1548882288.001021883, sequence: 3727 - clear 
> 0.0, sequence: 0 
> source 0 - assert 1548882289.001020522, sequence: 3728 - clear 
> 0.0, sequence: 0 
> ^C 
>
> On Wed, Jan 30, 2019 at 3:01 PM Robert Nelson  > wrote: 
> > 
> > On Wed, Jan 30, 2019 at 2:54 PM Thomas Remmert 
> > > wrote: 
> > > 
> > > Hello, 
> > > I have a contact closure switch connected to P8_14.  When the switch 
> is activated, P8_14 is brought to ground.  I need to apply a time stamp 
> when this occurs with millisecond accuracy. 
> > > 
> > > 1) I have an adafruit GPS with 1 pps output.  I see the NMEA strings 
> and have confirmed the 1 PPS is working. 
> > > 
> > > 2) I have NTP running with my local GPS and 1PPS source configured. 
>  (Maybe chrony is a better choice?) 
> > > 
> > > 3) Just for testing, I am using the following python code: 
> > > 
> > > import Adafruit_BBIO.GPIO as GPIO 
> > > import time 
> > > import datetime 
> > > 
> > > GPIO.setup("P8_14", GPIO.IN, pull_up_down=GPIO.PUD_UP) 
> > > 
> > > #GPIO.add_event_detect("P8_14", GPIO.RISING, callback=my_callback, 
> bouncetime=1000) 
> > > 
> > > while True: 
> > > GPIO.wait_for_edge("P8_14", GPIO.RISING) 
> > > ttime = datetime.datetime.now() 
> > > print(ttime) 
> > > 
> > > 
> > > When I compare my time with a very expensive DAQ, my time stamp is 
> always off by 2-4ms and it is not a consistent offset.  Does anyone have 
> any other thoughts at to how I might approach this?  I am needing to get 
> the timestamp accurate to 1ms. 
> > 
> > Use the pps driver, setup an overlay like shown: 
> > 
> > 
> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/PB-UART4-TESEO-LIV3F.dts#L63-L71
>  
> > 
> > Then you can use the pps/gps tools... 
> > 
> > Regards, 
> > 
> > -- 
> > Robert Nelson 
> > https://rcn-ee.com/ 
>
>
>
> -- 
> Thomas Remmert 
> Cell: 936-647-6030 
> Office: 281-203-0855 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0d397706-1b6d-4665-9928-4e69a73dc7c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Using FTDI Pins with PRU Cape

[graham]

For development, not for the end product, remove the six pin header 
pointing upwards, and replace it with a right angle six pin header 
protruding out the bottom-side of the board.

You now have full access to the 6 pin UART0 interface, no matter what is 
plugged in the top of the board.

Of course, you need access to someone who knows how to solder.

--- Graham

==

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/bba9295c-b648-414f-b41d-5d18796b4fe4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Reconfigure LCD data pins

[Graham]

Read the BeagleBone System Requirements Manual.
Section 8.3 and 8.3.1
It tells you several times about the requirement to protect the boot pins, 
which are common with the LCD pins.

During boot, long before the device tree has any effect, the processor must 
read the 100K pull up and pull down resistors on these lines, in order to 
know which options to use to boot.

If your cape puts any kind of load on these lines, that would modify the 
result of the processor trying to read the 100K resistors, then the 
processor will be trying to boot with some other wrong option, with the 
usual result of not successfully booting.

--- Graham

==


On Monday, January 28, 2019 at 6:52:28 AM UTC-6, Serg Penshin wrote:
>
> Hi averyone,
> Is it possible to change LCD data pins to another GPIO? The fact is that 
> my cape does not allow the Beaglebone Black to boot normally, because LCD 
> pins  are used when BBB boot. Although if I connect it after boot BBB, then 
> it works well. I tried to reconfigure the pins in the device tree so as not 
> to touch the boot pins, but there is no signal on them. Although the cape 
> attached in the slot.
> Please help me, I'v no idea, what is wrong.
> Here is my device tree-source:
> https://yadi.sk/d/VjxN_P-Vl4x9Uw
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7cf3a951-f092-45f7-8c16-47aa06d5428c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Porting application from BeagleBone Black to Pocket Beagle

[Graham]

Well, it sort of depends on what capabilities you are using.
The CPU is pretty much the same.
The available IO pins pretty much map to different places.
The PocketBeagle does not have Ethernet or Video output.
Some of the defaults are set up differently.
Since you did not mention what you were trying to do, or what capabilities 
you planned to use, the answer has to be "maybe."

If you don't need any of the missing capability, and you are ready to 
adjust for the differences in IO that is present, the answer is "probably."

--- Graham

==

On Thursday, January 24, 2019 at 11:12:35 AM UTC-6, logan...@gmail.com 
wrote:
>
> Just wondering the same thing. I would like to do my development on a 
> larger BeagleBone, but aiming at the PocketBeagle as an ultimate (built-in) 
> target. Is code written for one Beagle portable between others?
>
> Sorry if this is a newb question, but I can't seem to find an answer 
> anywhere else.
>
> On Friday, September 7, 2018 at 2:23:31 PM UTC-4, vtra...@gmail.com wrote:
>>
>> Very very good question from the OP here. I too would like to know more 
>> about porting applications to the Pocket Beagle. In fact I am so interested 
>> I am inclined to give it a try myself. I have a couple BeagleBone Blue 
>> boards that I just got. Clearly, the BB Blue comes with resources not 
>> included on the PocketBeagle. What this question needs is a straightforward 
>> explanation of common resources found on BB Blue, BB Black, and the 
>> PocketBeagle for which a class of applications will run on all of these 
>> boards. 
>>
>> On Tuesday, June 12, 2018 at 11:11:59 AM UTC-6, agm...@gmail.com wrote:
>>>
>>> Hi,
>>>
>>> I have an IoT project which uses BeagleBone Black as the central 
>>> computing device. I'm planning to move to Pocket Beagle (to save some $$). 
>>> I was using the following on BeagleBone Black
>>>
>>>
>>>1. I2C2_SCL (pin P9_19) and I2C2_SDA (pin P9_20). This maps to P1_28 
>>>and P1_26 on Pocket Beagle (not sure what mode this is on)
>>>2. SPI0 and SPI1 on BBB which maps to P1_6,8,10,12 and 
>>>P2_25,27,29,31 on Pocket Beagle. 
>>>3. UART4 on BBB which maps to P2_5 and P2_7 on Pocket Beagle
>>>4. I need an Ethernet Port, Wifi. I plan to add a USB Host A as 
>>>described here 
>>>https://groups.google.com/forum/#!category-topic/beagleboard/GOwSuY4oiyI 
>>>and connect to it a USB hub which can integrate many USB adapters. *Does 
>>>anyone info on how many devices pocket beagle can support this way (from 
>>> a 
>>>current/power perspective)*
>>>5. I was powering the BBB with 5V through pins P9_07 and P9_08. I'm 
>>>a little confused on how I can do that with Pocket Beagle. 
>>>
>>> https://groups.google.com/forum/?utm_source=digest_medium=email/#!category-topic/beagleboard/pocketbeagle/8Y5COfcW-Ok
>>>  
>>>talks about some power issues. *Any input on how I can connect my 5V 
>>>line to Pocket beagle?*
>>>
>>> *Any thoughts on move from BBB to Pocket Beagle? Any other caveats that 
>>> people have found with Pocket Beagle? Stability issues? The software status 
>>> page 'WIP' for most of the items. *
>>>
>>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7ffb8511-14da-45d7-9a03-4bdc67621a6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [beagleboard] Re: Can BeagleBone Black's OS booting time could be a problem in a harsh vibrational environment?

[Graham Stott]

Have you considered the PocketBeagle. Its power would be a soldered battery 
connection. It is much smaller than a BBB. And per the issues raised by Dennis 
reply, I believe all chips are soldered in. There is a working port of freeRTOS 
with TI starterware on GITHUB which boots fairly fast.

-Original Message-
From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Dennis Lee Bieber
Sent: Thursday, January 17, 2019 11:53 AM
To: beagleboard@googlegroups.com
Subject: [beagleboard] Re: Can BeagleBone Black's OS booting time could be a 
problem in a harsh vibrational environment?

On Wed, 16 Jan 2019 13:20:42 -0800 (PST), thejodeni...@gmail.com declaimed the
following:

>
>Hi all,
>
>I'm a beginner in the microprocessor environment, and my job is to find 
>the "best" microprocessor board to be able to perform some data 
>monitoring inside a harsh vibrational environment (Rocket).
>

Given the environment -- your first task is to eliminate anything not
suited to that usage. So... anything with socketed chips will be out (older
Arduino UNO used a socketed AVR processor).

What does the monitoring do? Log to persistent memory? Send telemetry
via a radio link? Activate a self-destruct if the parameters go out of
range?


>I looked on all the Beaglebone Black's proprieties and it would be suitable 
>for the project, but one of the members of my team suggest to avoid using a 
>microprocessor (with OS) and go for a microcontroller instead (no OS) like 
>the Arduino because if the vibrations cause a sudden loss of power, the 
>(longer?) booting time of the OS could cause a bigger loss of data.
>

If there is any realtime aspect, you would want to avoid common Linux.
The BBB PRUs would support realtime -- but the "firmware" gets loaded as
part of the Linux boot, so if there is any chance of processor restarts
that may not be desirable -- not to mention that uncontrolled power-loss
can corrupt the file system! (You do not want a R/W file system if you are
subject to power drops... Everything should be in a read-only memory
system, with logs maintained in either a volatile memory [hence lost if
power fails] or in a separate flash/EEPROM which can be, if corrupted,
reformatted [again losing older logs]*)

For something more powerful than an AVR... Arduino DUE (are they still
made), or a TIVA C 123 (EK-TM4C123GXL) may be candidates (TI-RTOS modules
for the latter, and I think FreeRTOS has been ported to DUE).


>I have the feeling that vibrations would not be enough to cause loss of 
>power if the connections are well connected, but still, I can't be sure.
>
As mentioned -- exclude anything with a socketed processor 



* in a previous life, I did work on some avionics... that was set up with a
power-loss detection circuit/interrupt, with capacitors to run the
processor long enough for a safe shutdown (eg: store processor state). No
"OS" (it did have an RTOS) that required massive file system operations. It
relied upon finding garbage in part of RAM to determine if it needed to
cold-boot, or could restore the saved state and resume where the interrupt
triggered.


-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.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.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d6m14epd21nakprd9r6rhal6su52lvb34e%404ax.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/002e01d4aea7%2404cbbee0%240e633ca0%24%40comcast.net.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BeagleBone Black clock mismatch without pullups

[Graham]

That really does not make a lot of sense.
I have five BBB's and a few Pocket Beagles, and they all free run within 50
ppm of where they are supposed to be at 24.000 MHz.
50 ppm error is about 3.5 seconds per day
You can walk them in closer to 2 ppm(at least at room temperature), by
changing C25 and C26 to 24 pF, rather than the factory supplied 18 pF.
NTPD or timesyncd do not have any problem holding time on my Beagles within
20 milliseconds or so

I would look at the lid of Y2, the main 24 MHz crystal with a magnifying
glass or microscope.
The frequency is usually laser engraved in the metal lid.

Where did you get your Beagle?

--- Graham

==


On Wed, Jan 16, 2019 at 4:33 PM pbft  wrote:

> Thanks. I'm not precisely sure of the terminology, but the BeagleBone
> decides that the 'clocksource' is 24mHz. Its RTC will then gain *exactly*
> two minutes every 24 minutes if you disable timesyncd. With pullup
> resistors it will decide that the clocksource is 26mHz and the RTC will be
> virtually perfect:
>
> debian@arm:~$ dmesg | grep -i timer
> [0.00] OMAP clockevent source: timer2 at 2600 Hz
> [0.29] clocksource: timer1: mask: 0x max_cycles:
> 0x, max_idle_ns: 73510017198 ns
> [0.39] OMAP clocksource: timer1 at 2600 Hz
> [0.000568] timer_probe: no matching timers found
> [0.463409] clocksource: Switched to clocksource timer1
>
> The custom cape leaves the 'boot pins' floating (unless I add the
> pullups), and I get the same behavior with the BeagleBone running by itself
> with no cape.
>
> On Wednesday, January 16, 2019 at 5:15:24 PM UTC-5, Graham wrote:
>>
>> The standard external clock frequency source for the BeagleBone Black is
>> 24 MHz.
>>
>> Is that what you are referring to?
>>
>> Are you protecting all the "Boot Pins", so that your "Custom Cape" is not
>> overriding the boot programming resistors on the BBB?
>>
>> --- Graham
>>
>> On Wednesday, January 16, 2019 at 3:25:48 PM UTC-6, pbft wrote:
>>>
>>> Quick update: I've built 4.18.20 from source, and it has the same
>>> behavior.
>>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/iZxmejC9750/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/040ea632-065a-4332-801a-794df698384b%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/040ea632-065a-4332-801a-794df698384b%40googlegroups.com?utm_medium=email_source=footer>
> .
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC_N71q_1MqWrt9dUrpR52Hg6RhGvnbXaPV0hKoRybfmr_A04Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BeagleBone Black clock mismatch without pullups

[Graham]

The standard external clock frequency source for the BeagleBone Black is 24 
MHz.

Is that what you are referring to?

Are you protecting all the "Boot Pins", so that your "Custom Cape" is not 
overriding the boot programming resistors on the BBB?

--- Graham

On Wednesday, January 16, 2019 at 3:25:48 PM UTC-6, pbft wrote:
>
> Quick update: I've built 4.18.20 from source, and it has the same behavior.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2683a9ce-35fa-48a3-8ea5-1b1b61673c6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Unable to get BBB to recognize USB Serial Device

[Graham]

It looks like it does show up as a ttyACM0 device, rather than a ttyUSB0 
device.
Now I need to get it running, sorry for the question.
--- Graham

==

On Tuesday, January 15, 2019 at 9:27:48 PM UTC-6, Graham wrote:
>
> I am running debian 9.5 2018-10-07 on a BBB
>
> I am trying to connect a USB Serial Device (it happens to be an Arduino) 
> to the BBB USB port so that I can control it as a serial device.
> The Arduino device works fine as a serial USB device when attached to a 
> Windows 10 USB port.
>
> The BBB can see the device:
> debian@BBB2:~$ lsusb
> Bus 001 Device 002: ID 2341:0042 Arduino SA Mega 2560 R3 (CDC ACM)
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> but the BBB does not show or create any ttyUSBx device.
>
> How do I get the BBB to create a ttyUSBx device I can access?
>
> Is this some kind of conflict with the USB gadget function?
>
> --- Graham
>
> ==
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/eb5f2f30-2644-4657-8dba-861d25e7a866%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Unable to get BBB to recognize USB Serial Device

[Graham]

I am running debian 9.5 2018-10-07 on a BBB

I am trying to connect a USB Serial Device (it happens to be an Arduino) to 
the BBB USB port so that I can control it as a serial device.
The Arduino device works fine as a serial USB device when attached to a 
Windows 10 USB port.

The BBB can see the device:
debian@BBB2:~$ lsusb
Bus 001 Device 002: ID 2341:0042 Arduino SA Mega 2560 R3 (CDC ACM)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

but the BBB does not show or create any ttyUSBx device.

How do I get the BBB to create a ttyUSBx device I can access?

Is this some kind of conflict with the USB gadget function?

--- Graham

==

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7fb1da95-6c66-4d2c-ae39-5c2b45a3d55f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone as a USBTMC Device

[Graham]

Adrian:
You are correct, I misread his request.
--- Graham

==

On Monday, January 14, 2019 at 9:42:28 AM UTC-6, Adrian Godwin wrote:
>
> If I understand Matt correctly, he doesn't want what Python USBTMC does. I 
> believe that's a Python application (which might run on a BB) that accesses 
> instruments having USBTMC interfaces.
>
> Matt wants to make the Beaglebone one of those instruments. He therefore 
> needs to have the BB offer a USBTMC device on its device port.
>
> I don't know if such a driver already exists or what would be required to 
> create one but I would start here :
>
>
> http://wh1t3s.com/2009/05/11/beagleboard-as-usb-mass-storage-device-via-usb-otg/
>
> This explains how to build the kernel with alternate device interfaces 
> such as MIDI.
>
>
>
>
>
> On Mon, Jan 14, 2019 at 3:27 PM Graham > 
> wrote:
>
>> Matt:
>>
>> Although I have never done what you are asking about, I note that there 
>> is an available USBTMC driver for Pythonf.
>> Python is a reasonable choice for test equipment control and scripting.
>> You might want to Google "Python USBTMC."
>>
>> Both Python 2 and Python 3 are readily available for the BBB.
>>
>> --- Graham
>>
>> ==
>>
>> On Sunday, January 13, 2019 at 10:51:48 PM UTC-6, Matt Bradley wrote:
>>>
>>> Hello,
>>>
>>> Does anyone know how to make the Beaglebone Black into a USBTMC device?  
>>>
>>> Please note: I am not trying to control USB devices (like multimeters 
>>> and oscilloscopes) with the Beaglebone.  I am trying to make a new 
>>> instrument and will use the Beaglebone as the brains of the instrument.
>>>
>>> I know it can be done, but I do not have any idea how to do it.  Thanks!
>>>
>>> -Matt Bradley
>>>
>> -- 
>> 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 .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/47706941-f0ac-43f4-8f93-aef2538fdfd6%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/47706941-f0ac-43f4-8f93-aef2538fdfd6%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b84b6bb2-00be-4bec-8ceb-56c9e32b6f64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone as a USBTMC Device

[Graham]

Matt:

Although I have never done what you are asking about, I note that there is 
an available USBTMC driver for Pythonf.
Python is a reasonable choice for test equipment control and scripting.
You might want to Google "Python USBTMC."

Both Python 2 and Python 3 are readily available for the BBB.

--- Graham

==

On Sunday, January 13, 2019 at 10:51:48 PM UTC-6, Matt Bradley wrote:
>
> Hello,
>
> Does anyone know how to make the Beaglebone Black into a USBTMC device?  
>
> Please note: I am not trying to control USB devices (like multimeters and 
> oscilloscopes) with the Beaglebone.  I am trying to make a new instrument 
> and will use the Beaglebone as the brains of the instrument.
>
> I know it can be done, but I do not have any idea how to do it.  Thanks!
>
> -Matt Bradley
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/47706941-f0ac-43f4-8f93-aef2538fdfd6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Booting BBB Clone

[graham]

Well, Dave, you might have to consult the experts who know a whole lot more 
about the low level details of how the BBB boots, but I think you need to 
understand the following:

1.) UART0 is not required for the BBB to boot, but when the BBB does not 
boot, UART0 is the place that has the information about why it is not 
booting. So not a good idea to try to bring up a new piece of hardware 
without access to the debug port.

2.) You might note that the same software distribution runs on five or six 
very different pieces of hardware. Multiple variants of the BeagleBone and 
PocketBeagle with different hardware sets and capabilities.  The 
information that UBoot and probably the kernel, too, needs to figure out 
what they are dealing with, is in the EEPROM. So, if you are not going to 
provide that information, you are in for some rewriting and recompiling of 
probably both uBoot and maybe the kernel, so you can hard code the 
information somewhere that they expected to get from the EEPROM.  It is not 
as simple as providing a new device tree.

--- Graham

==



On Saturday, January 12, 2019 at 7:32:53 PM UTC-6, Dave wrote:
>
> I am working to bring up a BBB "clone". 
>
> There are two significant differences that are/may be causing problems. 
>
> 1). UART0 is not accessible. 
> 2). The device does not have the BeagleBoard 32K I2C eeprom. 
>
> Anyone have pointers for building a U-Boot that Uses any other UART 
> besides 0 ?
>
> Is U-Boot going to have an issue because of the missing eeprom ?
> Linux ?
>
>
> Do I just need to change uEnv.txt to force a specific device tree ?
>
> Thank you
>
>
>
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b8598e22-1db9-47e4-b906-66ba59ec3ffa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Wifi (IEEE802.11 bgn) antenna cable frequency range for Beaglebone Black Wireless

[Graham]

If you are using Wifi at 2.4 GHz, then any antenna cable that will 
transport that band will work.
So, either 0 to 3 GHz, or 0 to 6 GHz will be fine.

You need to understand your losses per foot or per meter and keep your 
overall losses reasonable.

--- Graham

==

On Monday, January 7, 2019 at 4:29:09 AM UTC-6, don_wrt wrote:
>
> Dear All,
>
> I need a Wifi antenna cable for Beaglebone Black wireless. I searched a 
> little and see that BBWL support 2.4GHz wifi. So, could I use a coaxial 
> antenna cable with frequency range of 'DC - 3GHz' ? When I google 'wifi 
> antenna cable', comes DC - 6GHz coax cables. Will it be a problem, if I use 
> a DC-3GHz coax antenna cable with BBBWL ?
>
> Best Regards,
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/500513f3-44f3-4b47-b152-4d3b03b831c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Set up Cape's EEPROM i2c-2 BeagleBoneBlack Rev-C

[graham]

Following the instructions from that Apr 17 2017 discussion resulted in the 
cape manager disabled and no I2C addresses reserved for the capes.

I have not made the changes on recent OS releases, and there have been a 
lot of changes in the cape manager, so perhaps best to have Robert comment.

--- Graham


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5e7ea54d-a7c3-484f-a98e-8c0050ae7494%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Set up Cape's EEPROM i2c-2 BeagleBoneBlack Rev-C

[Graham Haddock]

Detailed discussion on Apr 17 2017.

--- Graham

==

On Wed, Oct 31, 2018 at 10:15 AM Graham Haddock 
wrote:

> I think there is a detailed discussion as to what is supposed to be inside
> the cape EEPROMs in the
> "BeagleBone Black System Reference Manual"
>
> It looks like there is a live Wiki version at
>
> https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual
>
> But since that address has already been reserved by the kernel, for the
> cape manager,
> you will not be able to read/write it from user space.
>
> If you want to access that address from user space on a BBB, you need to
> stop the cape manager.
> Google "BBB without reserved I2C addresses" on this forum.
> and look at "am335x-bone-common-no-capemgr.dtsi"
>
> --- Graham
>
> ==
>
>
> On Wed, Oct 31, 2018 at 10:01 AM MG  wrote:
>
>> @Graham I do have a cape with EEPROM at address 0x57 but the EEPROM is
>> wiped with nothing on it so I guess that is why the board doesn't populate
>> that address by default. How can I fix that?
>>
>> On Tuesday, October 30, 2018 at 11:14:50 PM UTC-4, gra...@flex-radio.com
>> wrote:
>>>
>>> Those addresses at 0x54-0x57 are reserved by the kernel driver.
>>>
>>> Unless you have some capes with those EEPROMS populated, there is
>>> nothing actually there.
>>>
>>> --- Graham
>>>
>>> ==
>>>
>>> On Tuesday, October 30, 2018 at 7:01:27 PM UTC-5, MG wrote:
>>>>
>>>> The BeagleBoneBlack comes with an "internal" EEPROM connected to i2c-0
>>>> line. I can see that clearly when I do i2cdetect:
>>>>
>>>> debian@beaglebone:~$ i2cdetect -y -r 0
>>>>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>>>> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 20: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
>>>> 30: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
>>>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 70: UU -- -- -- -- -- -- --
>>>>
>>>> It is showing under address 0x50. When I try to do ahexdump I get the
>>>> following values with no issue:
>>>>
>>>> sudo hexdump -C /sys/class/i2c-dev/i2c-0/device/0-0050/eeprom |
>>>> head -5
>>>>   aa 55 33 ee 41 33 33 35  42 4e 4c 54 30 30 30 43
>>>> |.U3.A335BNLT000C|
>>>> 0010  31 38 33 37 42 42 42 47  30 36 32 32 ff ff ff ff
>>>> |1837BBBG0622|
>>>> 0020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
>>>> ||
>>>> *
>>>> 1000  aa 55 33 ee 41 33 33 35  42 4e 4c 54 30 30 30 43
>>>> |.U3.A335BNLT000C|
>>>>
>>>> Now I want to add another EEPROM (with cape) on i2c-2 line which is
>>>> supported according to [BBB SRM](
>>>> https://cdn-shop.adafruit.com/datasheets/BBB_SRM.pdf) section 8.2. It
>>>> is the CAT24C256 as mentioned in the SRM. The allowable address range for
>>>> the expansion cards is 0x54-0x57. When I do i2cdetect I can see the
>>>> following:
>>>>
>>>> debian@beaglebone:~$ i2cdetect -r -y 2
>>>>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>>>> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --
>>>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 70: -- -- -- -- -- -- -- --
>>>>
>>>> I can see the addresses 0x54-0x57 showing, but when I try hex dump I
>>>> get an error:
>>>>
>>>>   hexdump: /sys/class/i2c-dev/i2c-2/device/2-0054/eeprom:
>>>> Connection timed out
>>>>
>>>> Questions:
>>>>
>>>> 1. Why are they showing as U's not actual address numbers? I know U
>>>> stands for used resource?
>>>> 2. Why am I failing to read from that EEPROM? I have tried all addreses
>>>> 

Re: [beagleboard] Re: Set up Cape's EEPROM i2c-2 BeagleBoneBlack Rev-C

[Graham Haddock]

I think there is a detailed discussion as to what is supposed to be inside
the cape EEPROMs in the
"BeagleBone Black System Reference Manual"

It looks like there is a live Wiki version at
https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual

But since that address has already been reserved by the kernel, for the
cape manager,
you will not be able to read/write it from user space.

If you want to access that address from user space on a BBB, you need to
stop the cape manager.
Google "BBB without reserved I2C addresses" on this forum.
and look at "am335x-bone-common-no-capemgr.dtsi"

--- Graham

==


On Wed, Oct 31, 2018 at 10:01 AM MG  wrote:

> @Graham I do have a cape with EEPROM at address 0x57 but the EEPROM is
> wiped with nothing on it so I guess that is why the board doesn't populate
> that address by default. How can I fix that?
>
> On Tuesday, October 30, 2018 at 11:14:50 PM UTC-4, gra...@flex-radio.com
> wrote:
>>
>> Those addresses at 0x54-0x57 are reserved by the kernel driver.
>>
>> Unless you have some capes with those EEPROMS populated, there is nothing
>> actually there.
>>
>> --- Graham
>>
>> ==
>>
>> On Tuesday, October 30, 2018 at 7:01:27 PM UTC-5, MG wrote:
>>>
>>> The BeagleBoneBlack comes with an "internal" EEPROM connected to i2c-0
>>> line. I can see that clearly when I do i2cdetect:
>>>
>>> debian@beaglebone:~$ i2cdetect -y -r 0
>>>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>>> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 20: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
>>> 30: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
>>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 70: UU -- -- -- -- -- -- --
>>>
>>> It is showing under address 0x50. When I try to do ahexdump I get the
>>> following values with no issue:
>>>
>>> sudo hexdump -C /sys/class/i2c-dev/i2c-0/device/0-0050/eeprom | head
>>> -5
>>>   aa 55 33 ee 41 33 33 35  42 4e 4c 54 30 30 30 43
>>> |.U3.A335BNLT000C|
>>> 0010  31 38 33 37 42 42 42 47  30 36 32 32 ff ff ff ff
>>> |1837BBBG0622|
>>> 0020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
>>> ||
>>> *
>>> 1000  aa 55 33 ee 41 33 33 35  42 4e 4c 54 30 30 30 43
>>> |.U3.A335BNLT000C|
>>>
>>> Now I want to add another EEPROM (with cape) on i2c-2 line which is
>>> supported according to [BBB SRM](
>>> https://cdn-shop.adafruit.com/datasheets/BBB_SRM.pdf) section 8.2. It
>>> is the CAT24C256 as mentioned in the SRM. The allowable address range for
>>> the expansion cards is 0x54-0x57. When I do i2cdetect I can see the
>>> following:
>>>
>>> debian@beaglebone:~$ i2cdetect -r -y 2
>>>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>>> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --
>>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 70: -- -- -- -- -- -- -- --
>>>
>>> I can see the addresses 0x54-0x57 showing, but when I try hex dump I get
>>> an error:
>>>
>>>   hexdump: /sys/class/i2c-dev/i2c-2/device/2-0054/eeprom: Connection
>>> timed out
>>>
>>> Questions:
>>>
>>> 1. Why are they showing as U's not actual address numbers? I know U
>>> stands for used resource?
>>> 2. Why am I failing to read from that EEPROM? I have tried all addreses
>>> from 0x54-0x57 with no luck. I can confirm that those addresses are showing
>>> in /sys/class/i2c-dev/i2c-2/device and the each dir has the following in it:
>>>
>>>  debian@beaglebone:~$ ls
>>> /sys/class/i2c-dev/i2c-2/device/2-0054/ -la
>>>  total 0
>>>  drwxr-xr-x 4 root root 0 Oct 26 19:46 .
>>>  drwxr-xr-x 8 root root 0 Oct 26 19:46 ..
>>>  drwxr-xr-x 3 root root 0 Oct 26 19:47 2-00540