Avrdude problems...

[jocke]

Hey! I can now connect and have access to the boot-loader again, the error was in my mind
I have written, compiled and downloaded a small program (that just moves a servo around) to the CM-5 using minicom, I press reset and nothing happens, isn't the servo supposed to start moving at this point? When do I have to press the reset button? Emidiently after the download?

[jocke]

What do you mean with:

Ok.
Now I just need to figure out how to tell the CM5 to reset AND without disturbing the newly uploaded program.

Oh, and thanks for the help!

[jocke]

I think that the hex file isn't downloaded completely, I get an error and the checksum isn't right...

[billyzelsnack]

Ok.
Now I just need to figure out how to tell the CM5 to reset AND without disturbing the newly uploaded program.

Oh that's just for my own program. I don't like hitting the reset button manually.

Yes.. Hit it right after you transmit and there is no feedback.

The example.c program needs you to be connected with a terminal to hit return for each of the little tests.

Maybe try transmitting the original hex file and see if you can talk to that from the terminal.
[/quote]

[Bullit]

My appologies, the robot terminal converts the hex file to binary and then sends it. Its a simple conversion to binary.

[billyzelsnack]

Ok. I got something hacked together. I've transferred back and forth between my .hex files and the bioloid .hex file. I still am using robot terminal get it into bootloader mode. I'll add that in a little bit as well as clean up my code. Here's the function I have so far..

Code: Select all

bool hex2cm5(FILE* fp,FILE* fpout)
{
   unsigned char totalChecksum=0;

   while(!feof(fp))
   {
      unsigned char lineChecksum=0;
   
      int numPairs;
      int addressHi;
      int addressLo;
      int recordType;
            if(fscanf(fp,":%02x%02x%02x%02x",&numPairs,&addressHi,&addressLo,&recordType)!=4)
      {
         return false;
      }
      lineChecksum+=numPairs;
      lineChecksum+=addressHi;
      lineChecksum+=addressLo;
      lineChecksum+=recordType;
      
      //printf("%d %d %d %d\n", numPairs, addressHi, addressLo, recordType);
      
      for( int ii=0; ii<numPairs; ii++ )
      {
         int value;
         if(fscanf(fp,"%02x",&value)!=1)
         {
            return false;
         }
         if(recordType==0)
         {
            fprintf(fpout,"%c",value);
            
            unsigned char buffer[1]={unsigned char(value)};
            if(serial_write(1,buffer)!=1)
            {
               return false;
            }
            totalChecksum+=value;
         }
         lineChecksum+=value;
      }
      lineChecksum=(~lineChecksum)+1;
      
      int checksum;
      if(fscanf(fp,"%02x\n",&checksum)!=1)
      {
         return false;
      }
      
      //printf("%02x %02x",checksum, lineChecksum);
      
      if(checksum!=lineChecksum)
      {
         return false;
      }

   }
   
   //printf("%02x\n",totalChecksum);
         
   return true;
}


fpout is just a file to save out the binary version of the hex file so I could diff it against the intel hex2bin output. It will go away.

[Marmakoide]

Hi all

I'am trying to upload a program into the CM-5 from Linux. What I'am doing now :
* Compiling the C program (The Robotis Example.c) into binary file
* Using gtkterm, similar to minicom. I set the connection to 57600 bauds, 8 bits, no parity bit, one control bit, no stream control.
* Entering in the bootloader with the #-and-red-button trick.
* Sending the load command
* Sending my binary file.

When I do that, the program is stuck after my first keypress. The orignal Robotis binary works fine, but not mine. Here it is my make file :

Code: Select all

GNU_AVR_PATH=/home/marmakoide/Bioloid/tools

CC=$(GNU_AVR_PATH)/bin/avr-gcc
OBJCOPY=$(GNU_AVR_PATH)/bin/avr-objcopy
CFLAGS=-O2 -mmcu=atmega128 -Wall

OBJECTS=\
./Example.o

TARGET=example


all: $(TARGET).hex $(TARGET).bin

$(TARGET).elf: $(OBJECTS)
   $(CC) -o $@ $(OBJECTS)

%.hex:%.elf
   $(OBJCOPY) --output-target ihex -R .eeprom $< $@

%.bin:%.elf
   $(OBJCOPY) --output-target binary -R .eeprom $< $@
%.o:%.c
   $(CC) $(CFLAGS) $(INCLUDES) -o $@ -c $<

clean:
   rm -f $(OBJECTS)

cleaner: clean
   rm -f $(TARGET).elf $(TARGET).hex $(TARGET).bin


What's wrong ?

[billyzelsnack]

Does it print anything out at all?

[billyzelsnack]

Does it print anything out at all?

[Marmakoide]

Problem solved, seems to be a compiler flag order issue

Here it is the script I made to build my Linux/GCC cross-compiler

Code: Select all

#!/bin/bash

# ----------------------------------------------------------------------------
# build-toolchain.sh $1
#
# $1 Where to install the tools
#
# Build a toolchain for the AVR Atmel GCC C compiler
#
# Based on the following docs :
#   http://lists.gnu.org/archive/html/avr-gcc-list/2006-08/msg00098.html
# ----------------------------------------------------------------------------


function download {
  if [ ! -f $2 ]; then
    wget $1/$2

    if [ "$?" -ne "0" ]; then
      echo "Fail to download" $2 "at" $1
      return 1
    fi
  fi
}


# --- Init ---
BUILD_TMP=/tmp/
ORIGIN=`pwd`

if [ "$#" -lt 1 ]; then
  echo "No installation path specified"
  return 1
fi

INSTALL_PATH=$1



# --- Get the packages to install from the net ---
download ftp://sourceware.org/pub/binutils/releases binutils-2.17.tar.bz2
download ftp://ftp.gnu.org/gnu/gcc/gcc-4.1.1 gcc-core-4.1.1.tar.bz2
download http://download.savannah.gnu.org/releases/avr-libc avr-libc-1.4.5.tar.bz2



# --- Build the binutils ---
if [ ! -f ${INSTALL_PATH}/bin/avr-as ]; then
  cd ${BUILD_TMP}
  tar xjf ${ORIGIN}/binutils-2.17.tar.bz2
  cd binutils-2.17
  ./configure --target=avr \
              --prefix=${INSTALL_PATH} \
              --disable-nls
  make
  make install
  cd ${ORIGIN}
  rm -rf ${BUILD_TMP}/binutils-2.17
fi



# --- Build gcc ---
export PATH=${INSTALL_PATH}/bin:$PATH

if [ ! -f ${INSTALL_PATH}/bin/avr-gcc-4.1.1 ]; then
  cd ${BUILD_TMP}
  tar xjf ${ORIGIN}/gcc-core-4.1.1.tar.bz2
  cd gcc-4.1.1
  ./configure  --target=avr \
               --prefix=${INSTALL_PATH} \
               --enable-languages="c" \
               --disable-libssp \
               --disable-nls \
               --enable-clocale=gnu

  #./configure  --target=avr \
  #             --prefix=${INSTALL_PATH} \
  #             --enable-languages=c \
  #             --disable-libssp \
  #             --enable-__cxa_atexit \
  #             --enable-clocale=gnu \
  #             --disable-nls

  make
  make check
  make install
  cd ${ORIGIN}
  rm -rf ${BUILD_TMP}/gcc-4.1.1
fi



# --- Build the libc ---
if [ ! -f ${INSTALL_PATH}/avr/include/stdio.h ]; then
  cd ${BUILD_TMP}
  tar xjf ${ORIGIN}/avr-libc-1.4.5.tar.bz2
  cd avr-libc-1.4.5

  ./configure --host=avr --prefix=${INSTALL_PATH} CC="$INSTALL_PATH/bin/avr-gcc"
  #./configure --build=`./config.guess` --host=avr --prefix=${INSTALL_PATH}
 
  make
  make install
  cd ${ORIGIN}
  rm -rf ${BUILD_TMP}/avr-libc-1.4.5
fi


Here it is the Makefile that works

Code: Select all

TARGET=example

GNU_AVR_PATH = /home/xxx/Bioloid/tools

CC = $(GNU_AVR_PATH)/bin/avr-gcc
OBJCOPY = $(GNU_AVR_PATH)/bin/avr-objcopy

OPTIM_LEVEL = s

#
# Compiler flags
#
CFLAGS  = -g
CFLAGS += -O$(OPTIM_LEVEL)
CFLAGS += -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
CFLAGS += -Wall -Wstrict-prototypes
CFLAGS += -std=gnu99

OBJECTS =\
./Example.o

LDFLAGS =


all: $(TARGET).hex $(TARGET).bin

$(TARGET).elf: $(OBJECTS)
   $(CC) -mmcu=atmega128 $(LDFLAGS) -o $@ $(OBJECTS)

%.hex:%.elf
   $(OBJCOPY) -O ihex -R .eeprom $< $@

%.bin:%.elf
   $(OBJCOPY) -O binary -R .eeprom $< $@
%.o:%.c
   $(CC) -mmcu=atmega128 $(CFLAGS) -o $@ -c $<

clean:
   rm -f $(OBJECTS)

cleaner: clean
   rm -f $(TARGET).elf \
                $(TARGET).hex \
                $(TARGET).bin


My procedure to upload a .bin executable to the CM-5 :
* lauching gtkterm (As minicom but with a more handy user interface)
* setting the connection to 57600 bauds, 1 stop bit, no parity bits, no stream control
* doing the #-and-red-button trick to enter in the bootloader (Matrix, here we come )
* typing load in the gtkterm shell
* sending my .bin file with the gtkterm ASCII file send functionality
* it's done, don't care about the CM-5 checksum complaints

[Sascha77]

I've tried using minicom on Mac OS X to download c-programs as described above. Whereas it is no problem to activate and use the bootloader, I have not managed to transfer the binaries correctly. I hope, someone can help me with this problem (should be the same problem using Linux):

I've used minicom -s to setup the serial port as described by the user guide and Marmakoide above: 57600 Baud, 8N1, no hardware flow control, no software flow control.

The problems occured when I tried to download the binary program (e.g. example.bin): using the ascii protocol the minicom reported only 1.1 KB of the 3.3 KB to be transfered. I've tried several settings of ascii-xfr (use minicom -s to change settings of "file transfer protocols"): with or without line-end translation (option -n) and with control-d or control-z as end-of-file character (option -e / -d). Nothing worked correctly. When I use ascii-xfr to pipe the original binary into another file (ascii-xfr -sv[dne] example.bin > copy.bin) I noticed that the files actually are different.

I then tried my own "transfer protocol". I added the following short program to minicom's transfer protocols:

Code: Select all

#include <stdio>

int main(int argc, char *argv[]) {
  FILE* in;
  in = fopen(argv[1], "r");
 
  fprintf(stderr, "Start transfering %s. ", argv[1]);
  char c;
  int count = 1;
  while (fread(&c, sizeof(char), 1, in)) {
    printf("%c",c);
    usleep(2000);
    if (count++%1024==0) fprintf(stderr, "."); // print a dot every kb
  }
 
  fclose(in);
  fprintf(stderr,"Done.");
  return 1;
}


I've verified "bcat example.bin > copy.bin" to produce an exact copy of the original file. When I use this program to load the example.bin into the CM-5 with the minicom, the bootlader just hangs after the transmission. Pressing any keys does not help. After disconnecting and reconnecting to the Bioloid and entering the bootloader again (#+red button), I had a look at the contents of the flash memory. Actually, the program was partially uploaded (actually the file-end is there, but in the wrong place)but not in the correct order. The download seems to start correctly, but always something wents wrong later on: either the CM-5 misses some big parts between the correct file start and the correct file ending or already transfered content gets overwritten with the end of the program.

I've played around a little bit with the usleep after each character: the delay makes a difference. With some settings the first 400 or so bytes are correct and than there is a discontinuity (several hundred bytes missing), with other settings there are only 3 bytes in the correct order. Repeating with the same delay always produces the same memory content in the CM-5. But longer delays do not result in a later disconitinuity.

Does someone have a clue, how to resolve this problem or where to look at next? For me, it would be really great to understand what's going wrong here exactly and to have minicom working.

But for the time being I have a workaround:

1. Use minicom to enter the boot loader and start the file transfer by entering "load"
2. Without quitting minicom simply cat the binary file directly to the device using another console. For me this is "cat example.bin > /dev/tty.KeySerial1 (using a Keyspan USA-19QW).

In the minicom the CM-5 reports the correct file size and the example.bin works as expected. Simple!

[Marmakoide]

Well, gtkterm does the same job as minicom, but with a better graphical interface, maybe you could try it. In my case, I made a my own CM5 uploader (Linux, but should work with OSX) because I was fed up of the '#' stuff, you just have to type CM5-upload -i foo.bin, then to press the red button and it upload.

Here it is the way I setup the serial port and I trigger the bootloader :

Code: Select all

#include <stdlib>
#include <termios>
#include <unistd>
#include <errno>
#include <sys>
#include <sys>
#include <fcntl>
#include <string>
#include <stdio>



typedef struct {
  struct termios previousState;
  int fileId;
} SerialPort;



int
SerialPort_init(SerialPort* inPort, const char* inName) {
  struct termios lNewState;

  /* Open the serial port */
  inPort->fileId = open(inName, O_RDWR | O_NOCTTY | O_NDELAY);
  if (inPort->fileId <0>fileId, &(inPort->previousState));

  /* Set the state needed to perform a com with the CM5
   * 57600 bauds
   * 8 bits per word
   * 1 stop bit
   * no parity bits
   * no stream control
   */
  memset(&lNewState, 0, sizeof(struct termios));

  lNewState.c_cflag = B57600 | CS8 | CLOCAL | CREAD;
  lNewState.c_iflag = IGNPAR | ICRNL;
  lNewState.c_oflag = 0;
  lNewState.c_lflag = 0;
  lNewState.c_cc[VTIME] = 0;
  lNewState.c_cc[VMIN] = 1;

  /* Set the port to our state */
  tcsetattr(inPort->fileId, TCSANOW, &lNewState);
  tcflush(inPort->fileId, TCOFLUSH);
  tcflush(inPort->fileId, TCIFLUSH);

  /* Job done */
  return 1;
}


void
SerialPort_dispose(SerialPort* inPort) {
  if (inPort->fileId != -1) {
    /* Set the port to previous state */
    tcsetattr(inPort->fileId, TCSANOW, &(inPort->previousState));
    tcflush(inPort->fileId, TCOFLUSH);
    tcflush(inPort->fileId, TCIFLUSH);

    /* Close the port */
    close(inPort->fileId);
    inPort->fileId = -1;
  }
}



#define BUFFER_SIZE 256



void
SerialPort_enterCM5Bootloader(SerialPort* inPort) {
  int lNbBytesRead, lNbBytesWrite;
  char lBuffer[BUFFER_SIZE];
  int lEntered;

  lEntered = 0;
  lNbBytesWrite = 0;
  while(!lEntered) {
    memset(lBuffer, '\0', BUFFER_SIZE);
    lBuffer[0] = '#';

    lNbBytesWrite = 0;
    do {
      lNbBytesWrite = SerialPort_write(inPort, lBuffer, 1);
    } while(errno != EAGAIN);
    usleep(10000);

    lNbBytesRead = SerialPort_read(inPort, lBuffer, BUFFER_SIZE - 1);
    if (lNbBytesRead > 0) {
      if (strncmp(lBuffer, "\n\n\n SYSTEM O.K. (CM5 Boot loader", 24) == 0)
        lEntered = 1;
    }
  }
}


[bootstrap]

Just send the hex file as text. Its not XModem or ZModem. Its not compressed at all its just a text file. If you want to use avrdude you need to replace the bootloader which requires adding wires to the cm-5 to access the spi port to erase the ATMega128 (bootloader fuse is write locked). Bear in mind the bioloid application uses the bootloader to save poses to the flash so changing the bootloader will break the boiloid application as well.

I have a AX-12 ,I dint buy a CM-5.In my experimentation I erased the code in the AX-12.After that the power LED was always on (like here ,where the CM-5 was stuck in the bootloader).I copied the hex from another AX-12 which was working and tried dumping it using the STK500v2 USB programmer.But it dint work.Now the other working AX-12 got damaged (I wired it up the reverse way and fumes came from it).

Is there a way that I can dump this firmware for AX-12
(given here:
http://www.tribotix.info/Downloads/Robotis/Dynamixels/DXL_AX12_REV0x16_20060518_LD.rom and get the AX-12 working back?

[StuartL]

http://robosavvy.com/forum/viewtopic.ph ... hlight=rom

[bootstrap]

http://robosavvy.com/forum/viewtopic.php?p=17416&highlight=rom

Before dumping in ,I first tried to tune some of my Atmega8 to 16Mhz,I ended up messing with the fuse bits and both the Atmega8 stopped responding.Could you please tell me the exact fuse settings (lfuse and fuse) for the Atmega8