Robo-TX (unsorted "blog" 8-)

ASkr 8/2009:

I just received a Fischertechnik Robo-TX.

Equipped with:

operated by "Smart Network Devices'" 4NETOS and obviously created by "MSC-GE"
(You will find all this in the Robo-TX firmware file ;)

8MB RAM and especially 2MB flash are somehow ridiculous and unfortunately not enough for Linux. After having my experience with Linux on a Linksys WRT54G router, I can tell you that this is no fun at all...
Your flash memory will be full before a single selfmade elf binary is born ;)

Therefore, the Robo-TX is subject of getting lualized ;-)

Digital/analog IOs should be a piece of cake, PWMs and interfaces (I2C/UARTs/...) not too challenging but somehow I doubt that the bluetooth part can be operated.

We will see..

It looked much bigger in the WWW. I did not expect a flatfish...

A closer view.

The parts of interest...

Powered up normally, it has VID:PID 146A:1000 (*1*)
Holding down the left, red button while powering up results in
having a SAM-BA compatible USB connection ;-)

(Which is somehow strange... According to USB-IF, this VID (0x146A) is registered to Knobloch GmbH, the developers of the "old" RoboInterface... Mhhh...)

Assuming you are running linux:
To make SAM-BA work with your connection you have to load the "usbserial" module via:

modprobe usbserial vendor=0x03eb product=0x6124

Type "dmesg" to see the device your Robo-TX now is attached too (usually "/dev/ttyUSBx")

Assuming you are running windoze:
Should work out of the box.
If you previously installed a Lego NXT, surprise ;)

If powered up normally, you will see the "Fish-Term", FTs serial terminal. Beside the commands that are listed via "?", there are some more:

  • test_mode
  • BT_tst_mode
  • test_eeprom
  • ...
I am not interested in this stuff.
Especially "erase_boot" sounds scary. But I _assume_ (!assume!) this command refers to a RoboPro downloaded and automatically executed byte code? I really can not believe they are referring to the flash memory boot loader...

I suggest you better keep your hands off scary commands ;)

Right now, we're working on a little FT Robo-TX bootstrap file.
Sam-ba now has a new entry, a Robo-TX ;)


Randnotiz: Alles aus deutscher Hand, HW, SW und PCB. So würde ich mir das von vielen wünschen...


Ahh. Looks like someone lost the box with 1.27 pitch connectors ;)
A wide SCSI connector helped there, so it does here:

Digging deeper into this (almost) required an update of an old, well known circuit.
Well, "almost":

(Here follows a more general approach on finding the JTAG pins or pinout of foreign hardware)

We will need at least:

  • TMS, TDI, TCK (all inputs, "usually" pulled high)
  • TDO (although an output, this pin is mostly left floating)

Additionally there might be:

  • JTAGSEL (input, selects ICE or boundary scan functionality; evil signal ;)
  • NRST (bidirectional, processor reset)
  • NTRST (JTAG tap logic reset)
  • DBGRQ, DBGACK (used for debugging purposes)
  • VREF/VTARGET (used by interface to detect/measure voltage supply and levels)

An ARM standardized 20pin JTAG connector looks like this (pin numbers omitted)


Although the 20pin testpoint/header pads look promising, it is not your 20pin ARM compatible JTAG port...
A simple multimeter (or scope test, while running) will convince you...

But wait, we still have another 2x5 pads around here.
If you can not manage finding the power supply pins 3V3 and GND, you probably should go reading a book or develop software (ouch, sorry ;)
Further probing (power off) reveal 3 x 100k pulls to 3V3 (3rd row, left and right; 4th row left). Well, maybe TMS, TDI and TCK? All other pins float (substrate diode clamped).

Grab a ~47k resistor and measure pins while hardware is turned on:
Pull every single pin to 3V3 or GND to distinguish in- and outputs.
Beside the 3 100k pulled pins, you will find:

  • 2 outputs on the 2nd row, left and right
  • 2 inputs, pulled high, on the first row, left and right
  • 1 floating pin, 4th row, right

Go even further, here:
While powered on, connect your multimeter to a single output and successively pull all input pins in their active direction. By doing so, you will find out that the pin at row 3, right toggles pin row 2, right.

There are only two JTAG signals which behave like that:

  • TCK
  • RTCK
If you aren't all fingers and thumbs, you just reduced the amount of trial and error probing to two (disregarding JTAGSEL or custom/hidden JTAG solutions).

To cut a long story short...

Welcome on board...
No matter what you are going to do from here on. Be advised to create a backup of your flash content!

Sample settings for J-LINK

While the flash can be accessed right away, the SDRAM of course needs some bootstrapping. SAM-BA comes with sample applet code ("board_memories.c") for a AT91SAM9260 (-EK board) with different memory. This needs to be rewritten.

While the SDRAM datasheet tells us enough about the RAM itself (ROWs, COLs, TRC, TRAS, CAS-lat, ...) we still need the pins of the bus matrix (and maybe the Robo-TX standard RAM settings as well).

Because you should have a working JTAG connection now, you can read out the SDRAMC from

0xFFFF EA00 - 0xFFFF EC00
and the PIOs from
0xFFFF F400 - 0xFFFF FA00

Anyway, you will need to study the AT91SAM9260 datasheet and the ARM9E-S Core(tm) TechnicalReference Manual (also available as PDF from Atmel).

Although not much nicer than before...

It becomes a handy HDK ;)

Customizing and compiling SAM-BA for FTs Robo-TX:

If you are not familiar with ARM, toolchains, SAM-BA, etc..., here are some hints. As an exception, we are going to do this with windoze(ntm).

You will need the following:

  • SAM-BA; AT91-ISP.exe, WIN-XP, v1.13 will be fine
  • Sourcery G++ Lite a nice toolchain (arm-none-eabi)
  • Notepad++; the world's best and free editor (not required but recommended ;-)
  • Cygwin; use this if you prefer a real shell over M$s command-line (not required but recommended ;-)

Install Sourcery G++ and test it by entering:

  arm-none-eabi-gcc: no input files


If this does not work, you (or Sourcery G++) most likely forgot to add the subordinated "bin" directory to your $PATH variable. Do it now...

Install SAM-BA but do not yet start it.

Depending on your budget you may use the following to hook up your Robo-TX:

  • a) an USB cable
  • b) Atmel SAM-ICE JTAG-Interface (no licence to program flash memory!)
  • c) Segger J-Link ARM (this is what I normally use)
  • d) any other ARM JTAG equipment (without SAM-BA)

If you previously attached a Lego NXT in firmware update mode, you have a little problem with the USB connection. The NXTs SAM7 comes up with exactly the same VID/PID combination. Therefore, windows does not offer you the usual "new device driver install" window but claims you attached a Lego NXT in firmware update mode:

In this case, you need to update the driver to Atmels included "ATM6124.INF/SYS". Otherwise you will not be able to use SAM-BA via an USB connection! (Note: Keep this change of the driver in mind if you someday switch back to your Lego stuff ;-)

No matter what interface you are using:
Power up your Robo-TX while holding down the left, red button.

SAM-BA asks for your connection and the attached board. Usually it fills out the right connection setting for you. If not. Good luck debugging ;) Or even better: Use Linux! (see above for instructions on how to load the "usbserial" module).
For now, choose "at91sam9260-ek" as your board. Don't mind about the RAM initialization error as you have a complete other device...

If all is right and windoze(ntm) is having a fine day too, you will see SAM-BA in action:

Your first SRAM readouts (9260-ek start-settings default to 0x200000):

What you see right now, is one half of the SAM9260s internal 2x4kB SRAM (0x200000-0x201000 and 0x300000-0x301000). Try to change the value 0x0 in 0x200020 by double clicking on it. Enter any new value and refresh the display. Easy, isn't it?

Keep your mouse off the tab bar below (DataFlash, EEPROM, NandFlash, etc...). Except for SRAM, these won't work yet... Right now, you only have access to those memory areas (read the SAM9260 datasheet):

  • 0x00000000 - 0x00001000 mapped to SRAM1 0x200000
  • 0x00200000 - 0x00201000 SRAM1
  • 0x00300000 - 0x00301000 SRAM2
  • 0xfffa0000 - 0xfffffd60 peripherals and system

Although nothing special is working for now, you could use the two internal SRAM sections to slam in your code. Simply use tab "SRAM", send your naked binary (un-elfed ;) type "go 0x200000" in the SAM-BA console, et voila...

Well, the weekend is already gone.
Here's a sneak preview of upcoming stuff...

Those, who are familiar with SAM-BA, can meanwhile use this to enable the Robo-TX SDRAM:

Necessary SDRAM modifications to SAM-BAs "board_memories.c."
Be sure to set "16 bit mode" in your TCL file or exchange "sdrc_dbw" with "AT91C_SDRAMC_DBW_16_BITS":

  // ftrobotx settings; ASkr
                                    | AT91C_SDRAMC_NR_12
                                    | AT91C_SDRAMC_CAS_2 
                                    | AT91C_SDRAMC_NB_4_BANKS
                                    | sdrc_dbw        // or alt.: AT91C_SDRAMC_DBW_16_BITS
                                    | AT91C_SDRAMC_TWR_1
                                    | AT91C_SDRAMC_TRC_5
                                    | AT91C_SDRAMC_TRP_2
                                    | AT91C_SDRAMC_TRCD_2
                                    | AT91C_SDRAMC_TRAS_2
                                    | AT91C_SDRAMC_TXSR_4);


My time is limited. More to come...

  • SDRAM init routines
  • bootstrap code
  • setting up a Robo-TX toolchain
  • sample "Hello World" (or "Hello Pin") code
  • finding peripheral connections via boundary scan
  • finding peripheral connections via firmware

Some links to try in the meantime (if you have no clue yet):

ASkr 8/2009