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.
-
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?
-
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?
-
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.
-
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.
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
Hi Graham,
Thank you for the reply.
Yes, I figured this out about the TPS65217C, but couldn’t find a way to edit my post to remove that part of the question.
My initial searches didn’t turn up anything regarding the 1st question so I thought it might be faster to get some pointers from others since I’m working on a tight deadline.
Typically you have your distributor or assembly house program the
parts for you. For low volumes it's possible to program them yourself
prior to assembly if you've got the required equipment (a programmer
and the proper package adapter).
Otherwise, you would typically program things like the on-board eMMC
and EEPROM after assembly as part of the production test and burn-in
process, using an alternate boot method (eg: uSD, JTAG, USB, serial)
that would get enough software running to be able to perform in-system
programming. Note that usually the EEPROM is write-protected, so part
of the production test fixture physically enables EEPROM writes,
typically using a test point or other pad that will be pulled high or
low as required.
See the various "flasher" uSD images available for an example of how
to program the eMMC. Dig in the archives of this group and you'll
find several threads on programming the EEPROM (or customizing U-Boot
so you don't need the EEPROM).
You'll probably also want some sort of script to program things like a
unique serial number and MAC address. There are lots of ways to do
this, and typically it's handled by the same scripts that are doing
any other in-system programming and test/burn-in.
Thank you for the reply Charles. Yes, I am aware of the general process required. I was wondering specifically if all or which of the alternate boot methods (ie. mainly uSD, USB, or serial) would work on new blank chips.