Tag Archives: embedded

BeagleBone Black Debian build from balloonboard.org

Leave a reply

The Balloon Board project set out more than a decade ago to produce a high-performance, low-power, open hardware embedded Linux computing platform. It successfully did that, and now thousands of them are in use in all sorts of products all over the world.

One of the major achievements of the project was a build system which could configure, download, patch and build a boot loader, kernel and root filesystem using a relatively simple menu-driven interface. The menu allows the user to select which type of board to build for, and which customisations to apply. These can include custom kernel drivers for a particular application, or a different Linux distribution (Debian and Emdebian are supported). It doesn’t need an especially powerful machine to run on, but can make use of multiple CPU cores to speed up building.

My colleague Nick Bane has recently, in collaboration with Cambridge University Engineering Department, updated the build system so that it can build software for the Raspberry Pi and BeagleBone Black, both of which are somewhat newer hardware than the Balloon Board. This should make it easier to port software and device drivers between the boards without having to start with a completely new development system.

It might also be of interest to developers working with the Raspberry Pi and BeagleBone boards who want a simple, repeatable way to create the necessary software. This is especially important for use in manufactured products, where the process for creating a whole software distribution needs to be well understood.

This page describes my first attempts at building Debian Linux and the kernel for the BeagleBone Black. This is extremely preliminary, and it doesn’t work yet,

Software build options

Get the software:

svn checkout svn://balloonboard.org/balloon/branches/menuconfig2
make menuconfig
  • Mode Expert mode
  • Balloon Board BeagleBone Black
  • Choose which buildroot version to build -> Feb 2013
  • Select kernel version 3.8
  • make kernel-menuconfig
  • Select Kernel Features -> unselect Compile the kernel in Thumb-2 mode
  • make buildroot-menuconfig
  • Package Selection for the target -> Hardware handling -> Misc devices firmwares -> unselect rpi-firmware
  • Hardware handling -> unselect rpi-userland
  • Debian rootfs
  • Select kernel and module installation method -> Build Debian rootfs with kernel modules
make

Create Micro SD card

I used a 2GB card in a USB card reader connected to my Debian Squeeze PC. I created two partitions using fdisk. Partition 1 is a 50MB FAT16 (type 6) partition, and partition 2 is the rest of the card formatted as ext3 (type 83). On my system, the card appeared as /dev/sdc.

sudo mkfs.msdos /dev/sdc1
sudo mkfs.ext3 /dev/sdc2

Copy the files MLO, u-boot.img and uEnv.txt from the BeagleBone USB drive to the FAT partition.

Make uboot image

sudo apt-get install uboot-mkimage

In build/kernel, do

mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux" -d ImageBoot uImage

copy uImage into /boot on ext3 partition

copy am335x-boneblack.dtb from /boot on the original BeagleBone Black board into /boot on ext3 partition

The board tries to boot, but kernel dies with a stack dump:

## Booting kernel from Legacy Image at 80007fc0 ...
 Image Name: Linux
 Image Type: ARM Linux Kernel Image (uncompressed)
 Data Size: 8750560 Bytes = 8.3 MiB
 Load Address: 80008000
 Entry Point: 80008000
 Verifying Checksum ... OK
## Flattened Device Tree blob at 80f80000
 Booting using the fdt blob at 0x80f80000
 XIP Kernel Image ... OK
OK
 Using Device Tree in place at 80f80000, end 80f88bac
Starting kernel ...
[ 0.113797] platform 53100000.sham: Cannot lookup hwmod 'sham'
[ 0.114013] platform 53500000.aes: Cannot lookup hwmod 'aes'
[ 0.114792] omap_init_sham: platform not supported
[ 0.114807] omap_init_aes: platform not supported
[ 0.156004] omap2_mbox_probe: platform not supported
[ 0.225933] Unhandled fault: external abort on non-linefetch (0x1028) at 0xf4
[ 0.233938] Internal error: : 1028 [#1] SMP ARM
[ 0.238662] Modules linked in:
[ 0.241861] CPU: 0 Not tainted (3.8.0 #1)
[ 0.246424] PC is at rtc_wait_not_busy+0x14/0x50
[ 0.251241] LR is at omap_rtc_read_time+0x10/0xa4
[ 0.256147] pc : [<c03eee84>] lr : [<c03ef490>] psr: 40000193
[ 0.256147] sp : df053d60 ip : 00000000 fp : c08b0f28
[ 0.268112] r10: df053e18 r9 : c07d31e4 r8 : df2b7000
[ 0.273560] r7 : df2b71c8 r6 : c08b0f28 r5 : c083a9cc r4 : 00000000
[ 0.280365] r3 : f9e3e000 r2 : 00000000 r1 : df053dc4 r0 : df101010
[ 0.287172] Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kel
[ 0.294880] Control: 10c5387d Table: 80004019 DAC: 00000015
[ 0.300873] Process swapper/0 (pid: 1, stack limit = 0xdf052240)
[ 0.307134] Stack: (0xdf053d60 to 0xdf054000)
[ 0.311684] 3d60: df053dc4 df053dc4 df053dc4 c03ef490 df2b7000 c03ebbd8 c08b0
[ 0.320217] 3d80: df2b7000 c03ec884 00000000 00000000 00000001 df053dc4 00004
[ 0.328746] 3da0: df053df4 c084fcd4 60000113 df2b54b0 00000000 00000000 80000
[ 0.337275] 3dc0: c084fcc4 00000000 00000000 00000000 00000000 00000000 00000
[ 0.345805] 3de0: 00000000 00000000 00000000 c084fe34 c08b0f28 00000000 00000
[ 0.354335] 3e00: 00000000 df101010 c07d31e4 df103640 c08b0f28 c03eba44 dfef0
[ 0.362866] 3e20: 60000113 df101080 df101010 60000113 00000004 60000113 0000c
[ 0.371394] 3e40: df101080 df101000 df101010 c08b0f30 df104cc0 c08b0f2c c07f8
[ 0.379923] 3e60: 00000000 df101044 df2ccb80 c084fe78 c084fdf4 df101010 df104
[ 0.388453] 3e80: c084fdf4 c08af648 c07d31e4 c07ddb14 00000000 c031e1cc c084c
[ 0.396982] 3ea0: df101010 df101044 c084fdf4 c031cf88 df052000 c031d014 00008
[ 0.405510] 3ec0: c084fdf4 c031b66c df045478 df104c80 df052000 df001840 df2c4
[ 0.414040] 3ee0: c0841ea0 c031bf14 c0725ca0 c084fde0 c084fdf4 c084fde0 c0847
[ 0.422570] 3f00: c0860608 c031d5fc c0860608 c084fde0 c07ddb4c 00000007 c086c
[ 0.431102] 3f20: c07ddb4c c07eff94 c07ddb4c c0008858 00000006 00000006 c0780
[ 0.439633] 3f40: 00000000 c07efcac c07eff94 c07ddb4c 000000dd c086060c c07a4
[ 0.448163] 3f60: c0860600 c07ac314 00000006 00000006 c07ac3f0 c0cc8d80 c0570
[ 0.456693] 3f80: c0577e98 00000000 00000000 00000000 00000000 00000000 00004
[ 0.465222] 3fa0: 00000000 00000000 c0577e98 c000e6d8 00000000 00000000 00000
[ 0.473751] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000
[ 0.482280] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 b637d
[ 0.490833] [<c03eee84>] (rtc_wait_not_busy+0x14/0x50) from [<c03ef490>] (om)
[ 0.500636] [<c03ef490>] (omap_rtc_read_time+0x10/0xa4) from [<c03ebbd8>] (_)
[ 0.510257] [<c03ebbd8>] (__rtc_read_time+0x58/0x5c) from [<c03ec884>] (rtc_)
[ 0.519423] [<c03ec884>] (rtc_read_time+0x30/0x48) from [<c03ecad4>] (__rtc_)
[ 0.528773] [<c03ecad4>] (__rtc_read_alarm+0x1c/0x290) from [<c03eba44>] (rt)
[ 0.538858] [<c03eba44>] (rtc_device_register+0x140/0x268) from [<c07d3358>])
[ 0.548850] [<c07d3358>] (omap_rtc_probe+0x160/0x3b8) from [<c031e1cc>] (pla)
[ 0.558576] [<c031e1cc>] (platform_drv_probe+0x1c/0x24) from [<c031cdec>] (d)
[ 0.568657] [<c031cdec>] (driver_probe_device+0x80/0x21c) from [<c031d014>] )
[ 0.578459] [<c031d014>] (__driver_attach+0x8c/0x90) from [<c031b66c>] (bus_)
[ 0.587902] [<c031b66c>] (bus_for_each_dev+0x60/0x8c) from [<c031bf14>] (bus)
[ 0.597431] [<c031bf14>] (bus_add_driver+0x178/0x23c) from [<c031d5fc>] (dri)
[ 0.606963] [<c031d5fc>] (driver_register+0x5c/0x150) from [<c031e58c>] (pla)
[ 0.616948] [<c031e58c>] (platform_driver_probe+0x1c/0xa4) from [<c0008858>])
[ 0.626936] [<c0008858>] (do_one_initcall+0x2c/0x164) from [<c07ac314>] (ker)
[ 0.637019] [<c07ac314>] (kernel_init_freeable+0x108/0x1e4) from [<c0577ea4>)
[ 0.646648] [<c0577ea4>] (kernel_init+0xc/0x164) from [<c000e6d8>] (ret_from)
[ 0.655452] Code: e59f6038 e59f5038 e3a04000 e5963000 (e5d32044)
[ 0.661858] ---[ end trace 33e6cc13d62fdb11 ]---
[ 0.666954] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0b
[ 0.666954]

Raspberry Pi portable development system

Leave a reply

I’m often away from my lab and need to carry on working, in airports, co-working offices, at customer premises and so on. Of course, I have a laptop, but that only goes so far when you’re working on embedded Linux hardware. I need to be able to take the hardware with me, and work with it.

Recently I’ve been doing some work with the Raspberry Pi. The Pi is normally set up so that you plug a monitor, keyboard and mouse into it and use it as a desktop computer. That’s OK, but inconvenient for travelling with. You can also log in to it over a network, but that’s not a great idea when I have no idea what networking facilities, if any, will be available where I’m working.

My preferred way of talking to embedded systems is old-fashioned: over a serial port. It may not be the fastest, but it’s reliable and need no infrastructure at all. The Raspberry Pi has a serial port on its GPIO connector, pins 8 and 10, and the standard Raspbian Linux distribution has it set up to be a console. That’s just what I want. Now I just needed a way to connect it to my laptop.

As luck would have it, FTDI make some handy USB-to-serial converter cables. The one I chose for this application is the TTL-232R-3V3. They’re available from various places, but I bought mine from Farnell, part number 1329311.

The connector on the FTDI cable has six pins. As delivered, they are

DSC_0485

  1. Black GND
  2. Brown CTS
  3. Red VCC
  4. Orange TXD
  5. Yellow RXD
  6. Green RTS

The pins along the edge of the Raspberry Pi’s GPIO connector go:

2. +5V
4. +5V
6. 0V
8. TXD
10. RXD

Ooh! How convenient. The 5V power input is available next to the serial port. By rearranging the pins on the FTDI cable’s connector, it’s possible to make a cable which will both power the Raspberry Pi from USB and connect the console to the serial port. That’s perfect for mobile use. The cable is easy to modify: the pins are held in by little black plastic tabs which you can gently bend back with a jeweller’s screwdriver, tweezers or a scalpel. The modified cable is wired like this:

DSC_0487

  1. Red +5V
  2. not connected
  3. Black 0V
  4. Yellow TXD
  5. Orange RXD
  6. not connected

The spare brown and green should be cut off or insulated.

It works! I can drive a Raspberry Pi from my laptop with just this one cable. Very handy. Just be careful to plug it in to the right place on your Raspberry Pi’s GPIO connector, right in the corner. Any other location will apply 5 volts to a pin which isn’t expecting it, and could damage your Pi.

DSC_0488

There are a couple of finishing touches, however. I like to be allowed the responsibility of logging in as root, which Raspbian normally has disabled. It may not be good for schoolchildren to be able to do this, but for embedded developers fiddling with kernel drivers, it’s a great time-saver.

To enable root logins on the serial port, you’ll need to:

  • Enable the password on the root account:

Log in as the default user (user name pi, password raspberry), then

sudo passwd root

Then enter your desired root password twice.

  • Enable root login on the serial console:
echo ttyAMA0 >> /etc/securetty

That’s it. You’re all set.

Bubble Development Board Ethernet and SD working

Leave a reply

I’ve got a couple more features of the Bubble development board working. The Micro SD card needed pullup resistors from its data and command/data lines, then it Just Worked though the card detect function doesn’t do anything yet. While modifying the VHDL to get Ethernet working (see below) I noticed a message that sd_card_detect has been optimised out of the design because it’s not connected to anything. That would explain it. I’ll look at it in a while. I’m not even sure whether the kernel driver supports a card detect line.

Most excitingly, Ethernet works now. I’ve connected its interrupt output to a register in the CPLD and modified the platform code in the kernel to point it at the relevant interrupt, and it works! It gets an address by DHCP and I’ve successfully copied files to and from it by scp. It seems a bit slow, topping out at about 3.5Mbit/s, but the Samosa bus timing is pretty relaxed and could probably be speeded up significantly. I saw one transmit timeout message, too, so maybe something isn’t quite right yet. Oh, and the MDI/MDI-X negotiation still seems a bit unhappy so the link doesn’t come up every time.

I’d also like to wire the ‘link’ output of the W5100 to a GPIO so that the driver can see it and do sensible things when the cable gets plugged in and unplugged.

Raspberry Pi Power Architecture

2 Replies

Embarking on some work with the Raspberry Pi recently, I wanted to know what its power architecture looked like. The schematic diagrams are freely available but a quick web search didn’t reveal any higher-level design documents like this, so I drew my own and here it is.

I offer no guarantees of accuracy. Don’t blame me if you use this documentation and destroy your Raspberry Pi or anything else. This is not an official document. I hope it’s useful to someone.

The original version of this that I posted in April 2013 had a mistake in it, which Kai kindly pointed out. The version below has been corrected.

Raspberry Pi Power Architecture2

There’s a nice shiny pdf of it here: Raspberry Pi Power Architecture

Bubble Development Board – progress

Leave a reply

Having now had the Bubble Development Boards for a few days, I’ve tested a few more features.

Both JTAG sockets (Xilinx 14-pin and ARM 20-pin) work with their respective dongles.

The Ethernet adapter, a Wiznet W5100, is showing signs of life. If I plug an Ethernet cable into it, the ‘link’, ‘full duplex’ and speed indicator LEDs come on. Frequently the ‘link’ LED blinks continuously along with the Rx LED. I don’t know why, though searching on the web indicates that the W5100 can be fussy about the choice of transformer it’s used with, and sometimes about what kind of hub it’s plugged into – apparenly the automatic MDI/MDI-X negotiation can get confused. The tests were done with a TP-Link TL-SF1005D switch and I haven’t tried any other. Sometimes, though, the link will settle down to a steady state, then I see the Tx and Rx LEDs doing sensible things.

DSC_0453

The W5100 chip is wired to the Samosa bus with very simple address decoding so that it should appear every 4 bytes across the whole 256-byte Samosa address range. Manually poking and peeking its registers from the Bubble board’s boot loader gave sensible results, and I even managed to get it to try and send a packet, the Tx LED blinking reassuringly.

Recent Linux kernels have a driver for the W5100. I tried kernel version 3.7.1 which has already been patched for the Bubble board. The existing drivers expect the chip to be I/O or memory mapped, which is not the case on this board because it’s on the Samosa bus. The Samosa bus is accessed using its own function calls inside the kernel. I patched the driver, and had to undo one or two assumptions made in the code about memory access, and the results are promising: the chip is found correctly, interface eth0 appears, and it even sends packets from the DHCP client attempting to get itself an address. However, the first attempt to send a packet results in an error:

NETDEV WATCHDOG: eth0 (w5100): transmit queue 0 timed out

and a stack trace, though the kernel carries on running. It seems that the Ethernet chip’s interrupts are not making it into the kernel. This turns out to be due to the offending interrupt line not being connected to anything in the Bubble board’s CPLD, so I’ll have to fix that next. That needs the Xilinx programming dongle which I haven’t got with me at the moment.

Bubble Development Board – first prototypes received

1 Reply

A couple of days ago I received the first examples of the Bubble Development Board and started testing them.

DSC_0420

Much to my joy, the board fits neatly into a low-cost plastic case from Farnell, part number 1526699. With front and rear panels suitably cut out, it should be well protected and easy to connect things to.

DSC_0421

But does it work? Well, yes, largely. Here are the results so far.

  • Power: the LEDs (green for +5V input, orange for VDD_IO from the Bubble) come on and the Bubble board starts up reliably.
  • Reset button: does what it says on the tin.
  • Serial port: console works.
  • USB host: tested to work with a memory stick and a USB-to-Ethernet adapter.
  • USB slave: working. USB networking connection successfully established to a desktop PC as documented at http://www.balloonboard.org/balloonwiki/USBNetworking.
  • Audio: output works, straight into a pair of headphones, and quality seems good with no unpleasant background noises. Haven’t tried input yet.
  • HDMI: the Bubble board I was using was set up to drive an LCD panel, but by installing fbset and fiddling around with the settings (making them roughly 800×600, 60Hz) I managed to get a display on a monitor connected to the HDMI port. However, the image tends to disappear every few seconds and then come back again with some flickering, so something’s not quite right. I tried another monitor via an HDMI-DVI cable with the same result.
  • Micro SD socket: not working yet. The kernel reports an error during boot and /dev/mmc* devices don’t appear. I’ve noticed that other implementations of the SD card socket from Bubble have pullup resistors on all the data and clock lines which I neglected to put on this board. This might be an easy fix because the wiring looks right.
  • JTAG, Samosa, Raspberry Pi header, Ethernet: not tested yet.

Here’s another picture with the Bubble board turned over so you can see what’s on it.

DSC_0422

How to Get a Real Serial Port – PCI Express under Linux

2 Replies

serialport

I do a lot of hardware and software development on things with embedded processors, ranging from little 8-bit Atmel chips to big 32-bit ARM-based things like the Balloon Board. Often the systems they’re built in to don’t have much of a display or keyboard, so getting information in and out of them for testing and debugging purposes is tricky. One thing that really helps is a good old-fashioned serial port. Pretty much every embedded processor has some kind of serial port on it, and they’re generally very easy to use from software so can be got working very early in the development process.

In order to make use of a serial port, you need another one to connect it to. This used to be easy: they used to be ubiquitous on desktop and laptop PCs. However, in the last 10 years they’ve gradually died out and been replaced by USB to serial adapters. Though such adapters are cheap and readily available, I’ve had loads of problems with them. Since they’re easily detached, they often seem to go missing, or get left in toolboxes and attached to projects. Some of the ones I’ve used also sometimes seem to get themselves in a mess and start turning my data into junk until they’re unplugged and reinserted. This is not helpful.

usb-serial

It can also be hard to predict how the serial port will be identified when it’s plugged in: under Windows, it gets a COM port number, but which number it gets depends on how many other such devices have ever been plugged into that machine and even into which USB socket, so setting debugging software up to find the one you want is impossible. Under Linux the same problem exists but with an extra feature: if you have a terminal program watching a serial port, then accidentally unplug it and plug it back in again, the program carries on as if nothing has happened but you don’t see any output . That’s because the operating system thinks that the old port is still in use even though it’s not there any more, and allocates a new, available number when it’s plugged back in, so /dev/ttyUSB0 magically becomes /dev/ttyUSB1. Even restarting your terminal program doesn’t work, because it’s still going to look at the old number. You can reconfigure the terminal program to look at the new one, but then you’ll find that if you shut everything down and restart it, the USB serial port will have moved back to /dev/ttyUSB0. The only way out is to stop the program, unplug the adapter again, plug it back in and restart the program. This is a serious pain.

I recently had the chance to do something about this problem in my own workshop. I was configuring a new Linux PC for the workbench, and discovered, to my great joy, a little-documented feature on the shiny new Gigabyte GA-Z77N-WIFI motherboard: a serial port! Tucked away on a little white connector, there it was, forgotten and unloved. All it needed was a cable to bring it to the outside world, and it worked. It turns up as COM1 under Windows and /dev/ttyS0 under Linux, and it’s always there, can’t be unplugged, and never changes its number. Wonderful.

If one serial port is good, more must be better. The motherboard has a PCI Express slot on it, intended for a turbo-nutter graphics card which this machine didn’t need. I found a PCI Express serial port card, similar to the PEX4S553 from Startech.com which looked like it would do the trick. Actually I had it lying around because I’d fitted it to a Mac Pro a couple of years ago, but it never worked properly in the Mac.

startech-card

I put it in the machine and switched on. Would it work? Typing lspci revealed that it was there, and was working, so were the ports usable?

ls /dev/ttyS*
ttyS0    ttyS1    ttyS2    ttyS3

Not bad, but why only four? There’s the one on the motherboard, plus four on the card, so that should be five, right? Well, to cut a long story short, after a bit of web research, I found that the standard serial port driver in the Linux kernel only looks for four serial ports as standard, but responds to a kernel command line parameter to make it look for more (or indeed less). Experimentally rebooting and manually editing the kernel command line in grub to add

8250.nr_uarts=5

to the end of it worked! I had all five ports, and they all did what they should. To make the change permanent, I edited /etc/default/grub to add 8250.nr_uarts=5 to the end of the GRUB_CMDLINE_LINUX_DEFAULT parameter, and ran update-grub. Now all five ports turn up every time I switch the machine on, and I’m a happy developer. By the way, I’m running Debian Linux 6.0 (squeezy) with kernel version 3.2.something from backports, but the kernel version won’t make any difference – this stuff is all ancient history.

It remained only to tidy up the wiring. The ports on the Startech card appear on 10-pin headers. The wiring on these is simple: pin 1 on the header goes to pin 1 on the 9-pin D connector, pin 2 to pin 2, and so on. Pin 10 isn’t used. However, the way the pins are numbered differs between the headers and the D connectors: the headers are numbered on alternate sides, like a street, so one side is 1/3/5/7/9 and the other is 2/4/6/8/10. The D connectors are numbered 1-5 on the top row and 6-9 on the bottom row.

I had a load of serial port breakout cables in the bottom of my PC parts box, left over from the early 90s. I found that many of them were wired straight-through, like this:

DSC_0359[1]

which is wrong for the Startech card. I had to rewire them to look like this:
:DSC_0362[1] DSC_0361[1]

according to the correct pin numbering, and then they worked. The card fitted neatly in the back of the machine:

DSC_0366[1]and, as a finishing touch, I did a ‘case mod’ to mount two of the serial ports on the unused 3.5″ floppy drive blanking plate:

DSC_0365[1]Notice how they’re labelled, so I always know which is which! It’s a very practical arrangement for the workbench, having reliable serial ports always at hand. The other two are round the back, and will probably be used less frequently.

150W Boost Converter Schematic

51 Replies

In a recent project, I needed a boost converter to step up 5V to about 8V at a few amps. A few different Chinese-made boost converter modules are available from various sources: I’ve seen them on eBay and Amazon. One very common one is known as the ‘150W Boost Converter’. I believe it’s intended for charging laptops from car batteries. It’s specified to take an input of 10-32V and output 12-35V, which isn’t quite what I was looking for, but the price was right so I thought I’d take a chance. This is what I found.

boost

I had a good look at the circuit board. It’s based on the UC3843 chip, which is a pretty old device (I think it dates back to 1984) and is often found in PC power supplies. However, its age and ubiquity means that documentation on it is readily available. I traced out the circuit, so here’s the schematic diagram:

150W_ boost

You can also have it as a PDF file: 150W_ boost.

It’s a pretty straightforward boost converter topology with a MOSFET switching transistor and a variable resistor in the feedback loop to set the output voltage. There is no over-current, over-voltage or reverse polarity protection at all, and the chip isn’t designed for low power consumption so this module wouldn’t be suitable where very low standby power is a requirement. There are a couple of interesting features, though.

The circuit includes an arrangement with an NPN transistor which feeds some bias to the current sense feedback loop. According to the UC3843 datasheet, this improves the stability of the converter at duty cycles higher than 50%.

The control supply for the UC3843 is derived from a 9V regulator, so it’s independent of the input or output voltage. This is convenient.

The UC3843 is designed to operate from fairly high supply voltages, and won’t start up until its supply voltage reaches 8.4V. That was a bit of a problem for my application, where the input voltage was only 5V. However, there’s nothing to say that the chip power supply has to be the same as the power input. In fact, the module already has a handy 9V regulator which feeds the control chip. Looking at the circuit diagram, there are even a pair of resistors (I’ve labelled them R1 and R2) which select whether that regulator is fed from the input or the output. As supplied, R2 was fitted, so the control chip was fed from the output. Here’s a closeup of the relevant part of the board showing R1 and R2.

DSC_0310crop

My application happened to have a low-current 12V supply available, which would be perfect for powering the UC3843. I simply removed R2 and connected my 12V supply to the point where the black arrow is in the photograph. The boost converter now worked perfectly with a 5V input.

I also had to modify it a little to be able to reduce the output voltage below about 11V. R3, labelled in the photo, is part of the feedback network. I simply removed it and replaced it with a piece of wire. Now the output voltage was variable down to 5V, and I was able to set it to the 8V I wanted.

The module seemed very comfortable delivering 3.3A at around 8V, and drew about 5A from the the 5V input. The heatsinks only got slightly warm.

Unfortunately, the power supply I wanted to run the converter and its load from didn’t like starting up with it all connected. This is quite often a problem with boost converters, since the inrush current at startup can be very large as the controller tries to bring the output up to voltage as quickly as possible. I solved this by adding a soft-start circuit to the module. More on that later.

Bubble Development Board V1.0

1 Reply

I’ve just got V1.0 of a development board for the ‘Bubble’ embedded ARM module ready for manufacture, and will hopefully have prototypes soon.

BubbleDevBoard1.0

It’s designed to make the Bubble board easy to work with, and brings out various useful connectors:

  • JTAG ports compatible with Xilinx (14-pin) and ARM (20-pin) dongle pinouts
  • Serial port for the console
  • USB host, for memory sticks, keyboards and whatever else
  • USB slave, for mass storage or USB networking
  • Micro SD card
  • HDMI for monitor connection
  • Ethernet
  • Stereo analogue audio in/out
  • Raspberry-Pi compatible expansion connector with I2C, SPI and GPIO

It’s all powered from a Micro USB connector which should take a standard mobile phone charger, and is designed to sit neatly in a low-cost plastic box for protection.

Everything except the Ethernet port is already supported by Linux on the Bubble board, though making the HDMI port work will involve some fiddling with the LCD output timings. The Ethernet port is based on the Wiznet W5100 chip, which is popular in the embedded community and is supported by recent Linux kernels.