[EricT]

That should be good, I have about 200uF on ours now.. is the forward voltage drop across Q2 causing an the issue? maybe try bypassing your protection circuit.

also.. Just making sure, your lab supply is not over current’ing?

[EricT]

This is similar to what happen to me when trying to power the board from 5V supply and 6ft cord.
“The 5Vin rail shows a dip every 40ms down to 1.5V – almost as if the TPIC powers up, sees a large load on the rails and resets”

Adding bulk capacitance to our board fixed the issue.

[EricT]

Hi RogerLucas, It would depend on what your “large scale production” is. If it’s your own product and no one will be trying to run different distos or whatevers on it, the methods discussed in this thread should be fine.

Otherwise you will have to program the EEPROM either externally or create some code to do it (as long as the EEPROM write protect line is not enabled)

[EricT]

Anthony, It really could be a number of things. As far as I can tell, without the UART0, it will be near impossible to figure out. Any chance you can get UART0 on at least one board?

You can build your dtb on Ubuntu 18.04 you will have to set up your environment to cross-compile for the ARM architecture.

[EricT]

I’ll look at the attached dts soon..

 

your uboot output looks like it’s trying to use an overlay as well, line 66 and 67.. is that intentional? something that can be turned off in uEnv.txt?

[EricT]

It looks like the kernel is having a hard time talking to the hardware peripherals.  Having the SD car on MMC1 should be ok.

This is likely a kernel or dtb configuration issue.

What Kernel are you using?

 

-Eric

[EricT]

Hi JAbella,

Sound like something I can help with. email me at erictanner@outlook.com,

Eric

[EricT]

baud rate is 115200 if you made it to the UART bootloader you should be getting a ‘C’ every few seconds.

[EricT]

Yes, a non-programmed  EEPROM will do to that to the SD clock.

What I learned, is u-boot needs the EEPROM data to set things like clock speed, MMC, and other stuff.  If you have access to the I2C_0 pins, you can use a i2c tool to program the EEPROM.

I was being lazy, so tried to boot over the UART following this guys blog:

http://linuxkernel51.blogspot.com/2015/08/booting-beagle-bone-black-over-uart.html

 

however I went in and hacked the uboot source to force it to use the BeagleBone Black configuration. if you want to do the same, edit:

u-boot/board/ti/am335x/board.h

static inline int board_is_bone_lt(void) { return 1; }

1 2 3 4

static inline int board_is_bone_lt(void) {         return 1; }

 

Once in the Uboot bootloader, I use the uboot i2c application to program the EEPROM.

 

Eric

[EricT]

Ok, we programmed the internal EEPROM with the proper values and our system is running. We were wrongly assuming this was pre-programmed.

Thanks,

Eric

[Author]

Posts