Archive for July, 2006

Head module

Sunday, July 30th, 2006

Head module for the Keto 51 project will be located in the harvester head itself. The purpose of this module is to control the hydraulic valves and read the sensor inputs. It will be connected to the main control system using CAN bus. This way the wiring between the head and the base machine can be kept simple as only power and two wires for the CAN communication is needed instead of wiring all the valves and sensors all the way to the base machine.

Locating the electronic module to the head exposes it to quite challenging environment so there might be some additional problems to solve because of this. Vibration is probably the largest problem here.

The module will use AT90CAN128 microcontroller and also XC9572XL CPLD for the quadrature counters and output diagnostic monitoring.

Here is a photo of a partially assembled board. The board was designed and sent for manufacturing in the last minutes before leaving for vacation so it’s a bit of a mess in some ways and some problems have been found already. But it should work for prototyping.

Finding the right connector to interface the module to the outside world can be challenging too. For this first prototype a Molex Minifit Jr connector was chosen as it’s cheap and easy to get and should be quite easy to make changes compared to some other connectors out there.

But a better connector would be nice later. One alternative could be Econoseal from Tyco. This one is available in small quantity from the VEMS Shop. Another tempting connector is the Ampseal series which looks like it would be easier to make a sealed case with it. Just haven’t been able to find a place that would sell these in small quantity. If someone has suggestions for a possible sealed connector to use I’d be glad to hear of them.

CerfPod good news!

Saturday, July 22nd, 2006

I got a reply and the “nBOOT_FLASH_ENA” seems to be exactly what I was hoping for.

This is the answer I got:
Yes, the CerfPod 255SE can boot from external NOR flash by pulling
that pin low. It triggers a bit of logic on the board to remap nCS0
from the DiskOnChip to nCS0 external, then maps nCS3 (I believe) to
the DiskOnChip. Then you can use the Linux DiskOnChip drivers as
general storage (you will corrupt the DiskOnChip contents and render
the board unbootable from DiskOnChip).

So very good news it looks like. Now just need to find some suitable NOR flash device that can be acquired and design a board with it.

Possible flash device could be Toshiba TC58FVM7T5BTG65 from Digi-Key. 128MBit flash for a reasonable price.

CerfPod 255SE and Linux

Friday, July 21st, 2006

CerfPod 255SE is an embedded platform from Intrinsyc using 400MHz XScale processor with 64MB SDRAM and 32MB flash memory. Officially the board only supports WinCE and naturally works fine with it. But WinCE doesn’t really fit my needs so I’d like to run something else, primarily Linux at this time.

TFTP booting Linux with the existing bootloader works just fine using NFS as the root file system. But problems start when Linux would like to be saved to the board flash and booted from there as the I-Boot bootloader version onboard doesn’t support Linux or any other OS besides WinCE. Naturally the solution here would be to build a new bootloader with the preferred features. But the problem: instead of NOR flash the board uses M-Systems DiskOnChip Millennium Plus NAND flash chip. This doesn’t work like normal NOR flash and it requires it’s own somewhat complicate driver software. Also booting from the DiskOnChip is more complicated than with NOR flash. The module only support execute in place (XIP) from a special 1KByte boot block.
It is necessary to make an initial program loader (IPL) that is stored in this 1KB block which makes basic hardware initialisation and loads the secondary program loader (SPL) from the NAND to RAM and executes it from there. This SPL then loads the OS and provides other bootloader functionality.

Clearly that is more complicated than booting from NOR flash that supports XIP straight from the whole address space of the flash chip but as the board has the DiskOnChip as the only boot device I was planning to get into the process of building a new bootloader with the features I need even if it probably would be quite time consuming task. But after gathering all the public documentation about DiskOnChip that I was able to find the documentation still seemed to be missing the details of how to exactly save the IPL and SPL code on the DOC. Also it seemed that it’s not possible to obtain this information without signing an NDA with M-Systems. So quite big problem.

All this happened some time ago already and today I took the board on the desk again and started thinking about ways to solve this problem as otherwise it is a very nice board if only it didn’t use the M-Systems DiskOnChip as the only bootable storage. It occurred to me that it might be possible to add some external NOR flash to the expansion connector on the board. The expansion connector provides 16-bit databus and address bus. With some hardware hacking it could be possible to map this external NOR flash to chip select 0 on the XScale (booting can only happen from CS0) and maybe even physically remove the DOC device (currently mapped to CS0) from the board if necessary.

Then while looking at the expansion connector pinout I noticed a pin called “nBOOT_FLASH_ENA”. This name got my hopes up that maybe a remap like I’m planning with hardware hacking might be already built into the board CPLD. Unfortunately only thing mentioned in the docs is “nBOOT_FLASH_ENA is reserved for future use“. Doing some tracing I found out that the “nBOOT_FLASH_ENA” pin goes to the CPLD on the board and also the chip select from the expansion connector goes to the CPLD. More tracing revealed that the chip select from the DiskOnChip also goes to the CPLD. So everything looks like a remap like I want might be possibly implemented in the CPLD. I sent a query about “nBOOT_FLASH_ENA” and it’s functionality and I’m hoping for answer from Intrinsyc.

Otherwise it looks like the expansion connector should work nicely for a boot NOR flash as it provides the same 16-bit databus as used with the DOC and also the (probably hardwired) XScale BOOT_SEL[2:0] setup should be same for the DOC as 16-bit NOR flash. Here’s the current memory map of the board.

If the NOR flash approach works it should be possible to just forget the existence of the frustrating M-Systems DiskOnChip or maybe use it as a normal non-bootable MTD device with the Linux GPL DiskOnChip drivers.

A10VO 71 DFR1

Monday, July 17th, 2006

Hydraulic pump to be used is Bosch Rexroth A10VO 71 with DFR1 control.

A10VO datasheet

A10VO datasheet alternative link

DFR1 control:

Click for more details:

Keto 51

Friday, July 14th, 2006

I posted couple photos with the title “New project” a while ago. In the photos was the hydraulic block of a Keto 51 harvester head. Might not tell much if you’re not already familiar with this kind stuff though. Manufacturers website.

Here is also a video of it in action to give a better idea of what it does. (10MB Quicktime)

The video originally comes from the Kronos videogallery but as it’s not available there anymore I have provided a local copy.

Target here would be to build a working system around a used Keto 51 harvester head. That would include building the electronics that control the hydraulic valves and also the rest of the hydraulic circuitry needed like the pump.

The electronics consists of a few different modules connected with CAN bus. The main brains of the system runs on top of the ADS Graphics Client Plus board. This module runs Linux with the RTAI real time system. Basically Linux runs as a low priority task on top of the realtime scheduler so it doesn’t disturb the parts needing more real time response. User interface and file IO for example are left for Linux to handle. For user interface a 320×240 pixel EL panel is used. This board should have plenty processing power and resources for future needs.

Another module is for controlling the hydraulic valves and reading sensors in the harvester head. This module should be situated in the head itself to minimize the wiring needed. This module should have the capability of controlling about 15 on/off solenoids and also possible expansion room for couple proportional outputs. For input two quadrature encoders need to be read and some inductive proximity sensors.