I’ll follow this one up later with a description of the unbricking process.

I eventually got around to ordering an Olimex USB arm-ocd-usb.  Plugged it in to a Fedora 11 x86_64 laptop, and with the help of the gumstix wiki managed to successfully un-brick both my Verdex XM4 gumstix.  The unbricking process is pretty straight forward, the only real got-ya was that I had to install the D2XX drivers for the Olimex ocd device to work - oh and the board attaches in a weird way (on TOP of the pins of the vx-JTAG - not the 60pin Hi-Rose connector!!)

Matchbox + GPE on gumstix xm4

Since then I’ve put together two devices consisting of

* XM4 Verdex (no bluetooth)

* NetwifimicroSD-vx

* vxConsoleLCD16

* Samsung 4.3″ touch screen.

Gumstix XM4 with Samsung 4.3" tourch screen.

To test these I initially installed the factory software stack from the gumstix sourceforge site.  Using the TFPT method for the root filesystem makes the fs install take a few seconds rather than an hour using kermit, although I couldn’t get the kernel installed using tftp, so resorted to hyperterm (ick) - there are issues using minicom, and I didn;t have the patience to figure out why kermit 8.0 wouldn’t compile under fedora 11 64bit. - save that one for another day :/

I then moved on to installing the prebuilt glibc X11 image so I could get the LCD fired up - from (http://www.gumstix.net/feeds) on to a 2Gb micro SD card)  as the rootfs would not fit in the main flash on an XM4 (being only 16Mb and the image being ~27Mb). The great thing about using the mmc/sd combo is that there’s less risk of bricking the device while messing about, and the added bonus of loads of space.  I’m lead to believe that the current 2.6.21-r1 kernel doesn’t support SDHC cards yet.

I’ve taken a screenshot using the device and for a giggle uploaded it to http://scap.linuxtogo.org - mostly because one of the options on the screenshot tool on the desktop ‘encouraged’ it

* u-Boot 1.2.0

* uImage-2.6.21-r1-gumstix-custom-verdex.bin

* root_fs with glibc and X11

One problem I did encounter was extreme overheating when the wifi module was in use.  After a bit of time on nabble, it would appear that the wifi module can require current bursts of up to 2A, whilst the onboard vregs are down at 500mA, and the UK wall wart only supplied 1A.  It seems the solution is to power the netwifimicroSD-vx card (I’ve got R1700) from a separate supply.  My workaround was simply to physically remove the wifi module.

Since Last year when I last got this stuff out, the old buildroot has moved on to  OpenEmbedded, usign bitbake.  I’m now getting a BB environment set up so I can compile my groundstation code against it.

Finally I can unbrick these things and the best thing is it only takes a few minutes to get them back up and running again.

Groundstation Development

Big bag ‘o gumstix stuff

bag o gumstix bits

The UAV needs a groundstation that is light and portable, we’re going for pocket sized computing power, however there might be the requirement for a wopping great antenna to get the extra range we need.

2m_70cm_yagi

We start with a big bag of gumstix products.  In here there are a couple of the Samsung 4.3″ screens, some verdex XM4’s, and other assorted oddments.  Some of these are destined for the car, whilst others are going to end up in a picture frame computer, I digress…..

The groundstation is going to be built around a Gumstix XM4 platform giving 400MHz and 64Mb ram of linux computer, together with a 16 bit display, ethernet, wifi, and SD card storage capability - of course all running under the linux operating system.  I’ve got an old-style buildroot system set up on my linux laptop, and also copy of the latest and greatest OpenEmbedded bitbake environment.  For ease however I elected to start testing over the integration weekend with pre-build kernel and root filesystem images, to save time and messing about, and also just to verify that the hardware works - well currently the hardware works, but I seem to have bricked both my XM4’s.

I have 2 XM4’s, they were both delivered with a software build that didn’t support my intended hardware - that being Gumstix XM4 + netwifimicrosd + vx-consoleLCD16 + 4.3″ Samsung touch sensitive display.  I sooo need a box for this!!.

Over the weekend I managed to “brick” both gumstix XM4’s and now need to resort to using openOCD and the vx-Jtag board to “unbrick” them.

I had to flash these systems with all three software components, i.e. U-boot, from version 1.1.4 to 1.2.0, then upgrade the kernel to 2.6.21gum, and finally add the appropriate root filesystem build to include either qtopia or tinyx x11.

The first - and so far most reliable (and slow) method for flashing these was to make an RS232 level converter from 12v to 3v.  For this I used the circuit described in the datasheet for the MAX3232.  This ciruit works very well when powered from a 3v lab supply, (also home brew with an LM317 1.5A LDO).

vxbreakout and 12v to 3v max3232

An old Laptop running windows (yes I know!!) was used, running hyperterm to connect to ttyS0 on the gumstix - via the level shifter, allowing console access on the gumstix computer, from here it was possibe to interact with U-Boot and download a new U-Boot, Kernel, and root filesystem to the gumstix. (NB a 15Mb rootfs took 1hr 50min to download ).  There are a series of commands described on the gumstix wiki to help.

The first XM4 got bricked when I accidentally flashed the kernel image to the area in which the U-Boot resides - oops, no more U-Boot - I’ll need to attempt a re-flash using the jtag adapter.

The second XM4 however was sucessfully flashed with U-Boot 1.2.0, then kernel 2.6.21gum, and then various prebuilt binary filesystems.  The more recent kernel and filesystems allowed me to get the wired ethernet and also the wireless SMC911 lan working, and connecting to the internet via my wireless access point!!.

Whilst waiting for like what seemed forever to flash one of the images, I read more and discovered that tftp can be used to flash images.  I killed the current flash, and tried the tftp method - fantastic - this took my 1hour flash sessions down to about a minute.  Using a crossover ethernet cable, and a linux laptop with a tftp server configured, I set the boot enviromnent of the gumstix to point at the laptop ipaddress, did a saveenv, and managed to get flash images to download in what seemed like a split second - well actually about a minute!!! - way way faster than the serial method.

Sadly however whilst flashing an image containing qtopia I suffered a power outage - due to the cat’s tail knocking out power on the bench ( http://www.bigginge.com ) - hmmm, no more XM4, cant boot - won’t boot.  Another candidate for the jtag board me thinks!!.  Still problems aside I did manage to get the boards working and comunicating over wired ethernet.

My next mission is trying to figure out how to reflash - there’s a procudure on the gumstix wiki that describes the use of the jtag board, and openOCD.  I’ve downloaded openOCD and compiled it up ok on a fedora 9 x86_64 laptop but haven’t got around to actually using it because said laptop has no RS232 port - Hmmmmmm..  next I’ll try an old PC unit.

THought I’d post some images of the hardware I was using to construct (well attempt to construct) a groundstation computer

The Samsung 4.3″ touch sensitive screen

groundstation samsung display

Samsun screen and vx-consoleLCD16 adapter board - it also has solder pads for ac97 sound card and access to i2c bus, and serial ports

groundstation samsung display with vx-consoleLCD16 driver board

Samsung screen, vx-consoleLCD16, and gumstix xm4 verdex

display module with gumstix XM4

Samsung screen, vx-consoleLCD16 with XM4 stacked, and vx-netwifimicrosd card + included 2.4GHz antenna

groundstation display with netmicrowifisd board

All hardware stacked - this will make a nice tiny gound station

gumstix xm4 netwifimicrosd and vx-consoleLCD16 stacked

The vx-JTAG board - I think this board and me will be making very good friends very soon indeed!!!

vx-jtag board