Olimex MSP430F169 LCD board

Olimex has different development platforms available for the MSP430. One of these is the MSP430-169LCD. This article contains some notes about the board, tests operations and tips/tricks.

This development kit is very interesting.

FEATURES:

• MCU: MSP430F169 with 60K Bytes Program Flash, 256 Bytes data Flash,2K Bytes RAM
• NOKIA 3310 LCD 84x48 pixels black & white
• Joystick with 4 directions and push button function
• SD/MMC card connector
• two LEDs: status and power
• RESET switch
• JTAG connector
• 32 768 Hz oscillator crystal
• 8Mhz crystall oscillator
• power supply voltage regulators and filtering capacitor
• extension headers for all uC pins
• PCB: FR-4, 1.5 mm (0,062"), soldermask, white silkscreen component print
• Dimensions: 67x66 mm (2.65x2.6")

On the Olimex website or the Sparkfun Electronics website , is possible to download the schematic of this board, a test program and the processor specific datasheet .

Linux development environment

First of all, I installed the mspgcc development system.
Since I use Ubuntu I installed it (another article will describe that ), then I installed the program msp430-gdbproxy and the libraries from the Soft-switch.org website.

This is very critical.
The msp430-gdbproxy must be copied in the directory where is installed the mspgcc environment (usually /usr/msp430/bin, but in my case /opt/msp430-gcc-4.4.3/bin) and the two libraries libHIL.so and libMSP430.so, must be copied in the directory /usr/lib.
It is vital to copy the program and libraries from the same site, i.e. compiled for the same version.
The mspgcc installation process already copy the libHIL.so and libMSP430.so but very likely these libraries are NOT in sync with the msp430-gdbproxy program.

JTAG test

Then I started to see if the Olimex board was working.
I connected a 9V battery to the board (Vin and GND) and the board become alive.
Then, removing the external power, I connected the board to the JTAG connector, already hooked to the parallel port of the PC.
The board come alive, since the JTAG connector, thru the jumper P-IN (inserted by default), bring the power.

At this point, following the instructions found on the Develissimo website and from this article on the MSP430 development environment , I started the msp430-gdbproxy in a terminal.
The first time I had strange error, so I reset the board and something started finally to work.
However using the suggested command :

#msp430-gdbproxy --port=2000 msp430

I obtained this error :

debug: MSP430_Configure()
error: msp430-gdbproxy: unable to open debugger connection. Will restart

I spent quite some time tracking this error but the only thing I realized, was that the error was somehow related to the TCP port used or about some conflict with other services or the Linux configuration.
Then I started to read the mspgcc documentation and I found some notes about the msp430-gdbproxy .
In the notes it was suggested to try the command:

#msp430-gdbproxy --debug msp430

and it worked !
Only I noted that the default port was not 2000 but 2001 !
So I modified the original command using the new port :

#msp430-gdbproxy --port=2001 msp430

and ... voila' !!!
I was able to connect the Olimex board with the JTAG.


So to recap, in order to open a debug session with the card :

• connect the Olimex board to the Jtag (parallel version)
• open a terminal and start the gdb proxy :
  msp430-gdbproxy --port=2001 msp430
  Note ! If is not working is possible to use sudo, but in this case the absolute path of the msp430-gdbproxy must be issued.
  For example in my case : sudo /opt/msp430-gcc-4.4.3/bin/msp430-gdbproxy msp430
• open another terminal, or a tab in the already opened, and start the gdb :
  msp430-gdb name_program_to_load.elf

Inside the gdb digit help for generic help.
Here some common operations :

1. connect to the board (first thing to do)
   target remote localhost:2001
2. erase the flash memory (needed to do every time before to load the new code)
   monitor erase
3. load a program in the flash
   load name_program_to_load.elf (or .a43)

Converting the demo code

The first test is to convert the IAR demo code available for this board, for the mspgcc.
Following the conversion rules , it is possible to compile with mspgcc the code.
To simplify the process I created a makefile. Looking at what files the IAR used to create the code, I created a simple makefile :

CC=msp430-gcc
CFLAGS=-O0 -Wall -g -mmcu=msp430x169

OBJS=main.o mmc.o system.o lcd_new.o

all: $(OBJS)
$(CC) $(CFLAGS) -o test.elf $(OBJS)

%.o: %.c
$(CC) $(CFLAGS) -c lt;

clean:
rm -fr main.elf $(OBJS)
To compile the code, simply open a terminal, go in the directory where there is the makefile and the source code and then :

• $make clean
  to clean up the objects
• $make
  to compile

The result is a file called test.elf that can be load directly using the procedure described above.
The code is running smoothly.




Joystick
Here some notes about the joystick on the board.
The joystick is seen as 5 different switches.
The higher 4 bit of the Port1 (set in I/O - input direction - MSB) are used to carry the state of the 4 direction switches and 1 bit of the Port 2 (set in I/o - input direction) is used to carry the state of the pushbutton.
Here a table :

Signal	Name	Description
P1.4	B1	Right
P1.5	B2	Down
P1.6	B3	Up
P1.7	B4	Left
P2.0	B5	Pushbutton

The signals are pulled up, so when the switch is NOT pushed the reading will be high (1).
Here a Schematic to indicate the combinations of signals (remember, a 0 means the switch is pushed).

The continue line indicates the real signals, the dotted one the combinations of signals.
The inner circles indicates the name of the connection on the schematic.
Pushing the joystick on the left for example, will generate the combination of 0x7x (0111xxxx), i.e. masking the MSB will have 0x70 (01110000).
Pushing the joystick Up and Right will generate the masked combination of 0xA0 (10100000).




Here some other link to related resources and examples.

• Nokia 3310 Lcd Thermometer Using DS18B20
• PCD8544 data sheet
• MSP430F169 specific datasheet 

MSP430 - IAR vs mspgcc

Updated !
There are some differences between a C program developed with IAR and one developed for mspgcc.
This article will try to address these differences in order  to port a MSP430 program developed for IAR into a mspgcc one and viceversa.
I'll try to keep update the article every time I found something or if I receive suggestions.

With the mspgcc (msp430-elf) version maintained by TI, there are further differences.


Include files

Component 

The main inclusion file necessary is related to the component used.
With IAR usually it was #include <msp43xxxxx.h> wherexxxx indicated the specific family.

With mspgcc is better to include the file io.h and set the cflags to the correct cpu.
For example :

IAR	mspgcc	msp430-elf
Family MSP430 F 2012 #include <msp430x20x2.h>	#include <io.h> set -mmcu=msp430x2012 in cflags	#include <msp430.h> #include <legacymsp430.h> set -mmcu=msp430f2012 in cflags Be sure to have -I and -L in the CFLAGS with the path to the MSP430_TI/include

In Code::Blocks, in order to add the correct mmcu flag :

• open Settings/Compiler and Debugger 
• go in the tab Compiler Settings/Other options
• add the line -mmcu=msp430x2012 (or the specific mcu used)

Or, it is possible to find and include the correct header.
Looking in the file io.h is possible to see the correct inclusion. 

Ports

Some programs with IAR uses different port notation.
For example, the demo program for the MSP430F169, used in the Olimex card, uses the notation :
P3OUT_bit.P3OUT_0 to address the bit 0 of the port 3.

With mspgcc the single bit need to be addressed differently.
If a single bit needs to be addressed, it is necessary to use the mask bits.
For example, to set the bit zero to 1or the port3 :

P3OUT |= 0x01;

To set it to zero :

P3OUT &= ~0x01;

Better to prepare some defines, something like this :

#define BIT_0 0x01
#define BIT_1 0x02
#define BIT_2 0x04
#define BIT_4 0x08
#define BIT_5 0x10
#define BIT_6 0x20
#define BIT_7 0x40
#define BIT_8 0x80

and then use notation like :

P3OUT |= BIT_0

Interrupts

In IAR the interrupt function is a normal function with __interrupt as type.
mspgcc has a special function called interrupt.

Because of that under mspgcc no function prototypes are allowed for interrupt functions.
For example, for the Timerinterrupt function :

IAR	mspgcc	msp430-elf
/* Timer A0 interrupt service routine */ __interrupt void Timer_A (void); #pragma vector=TIMERA0_VECTOR __interrupt void Timer_A( void ) { ... }	// Timer A0 interrupt service routine interrupt(TIMERA0_VECTOR) Timer_A (void) { .... }	// Timer A0 interrupt service routine __attribute__((__interrupt__(TIMERA0_VECTOR))) void Timer_A (void) { .... }

To enable the interrupts is possible to use the function eint() or _BIS_SR(GIE);
Include the file signals.h when it is used (#include <signals.h>)

How to use syslog

How to use syslog for our own programs.

Linux, and other systems, supports a log management system called "syslog".

It is standard and there are utilities that can interact with it.
Here what to do to use syslog to add log capabilities to your programs.

1. In the file where syslog is used, include :
   #include <stdarg.h>
   #include <syslog.h>
2. Create a function that redirect the messages to syslog.
   For example this function imitate printf, just use this function everytime a message need to be printed in the syslog :
   int
   my_syslog_printf(const char *fmt, ...)
   {
      va_list ap;
   
      va_start( ap, fmt );
      vsyslog( LOG_INFO, fmt, ap );
      va_end( ap );
   }
3. Before to write logs in the syslog system, the syslog file need to be opened.
   Do it before to start to use syslog :
   openlog("program_name", LOG_PID, LOG_USER);
   syslog(LOG_INFO, "Start log  --\n");
4. Every time a log message need to be printed out, just use the function declared above, for example :
   my_syslog_printf("This is my log\n");
5. Before to exit from the program, close the syslog using the function closelog().
   However usually exiting from the program automatically the log stream is closed by the system.
   
   close_log("program_name");

Note :

In openlog and closelog the "program_name" is an identifier for the particular log generator.
I usually use the program name as identifier but is not mandatory, anything that identify univocally the log stream is ok.

Roomba repair - common problems

It's quite a while I play with Roomba.
Here a list of the common problems for these little robots (3rd and 4th generation) placed in the most probable happening order.

Battery

THE Roomba common problem is of course the battery.
On average, at least once per year, the battery dies.
It depends about the use of course, and contrary to the common sense, more a Roomba is used, more the battery last.
But as said, on average the battery last about a year.

NiCd batteries are lasting even less, mostly due to the "memory effect".
NiHi batteries are better.

Deck/motor

The second typical  problem that can happens to your Roomba, is in the deck motor or in the deck gearbox.
The deck motor is the electric motor that drives the brushes.
Typically the problems in these areas are happening when the Roomba entangle in wires or thick carpets.
When trying to remove itself,  more trust is placed on the brushes and if this happens often, after a while the mechanic can be damaged.
Actually there are different kind of problems that can happens to that area  :

1. broken motor gears
   The motor has a gearbox used to increase the torque.
   There are 3 gears inside the motor and they are made in teflon or plastic.
   The typical problem is that one or two of these gears, broken up, losing one or more "teeth".
   The final result is to have the motor spinning and  the main shaft not moving.
   It's enough to replace the gears to fix the problem.  Unfortunately  a new set of gears can cost more than the motor ... so often is more cheap to buy a new motor with a new gearbox (they come as single piece).
   
2. broken motor
   More rare but it happens that some internal connections broke.
   In this case the only thing is to replace the motor.
   
3. broken electronic
   The motor is driven by some electronic. Specifically a Mosfet is feeding the motor.
   Sometime, even more rare than the broken motor, is the electronics that fails.
   In this case "in theory" is enough to change the mosfet to fix the unit.
   Unfortunately it is extremely difficult because you need to take TOTALLY apart the Roomba in order to extract the electronic.
   Then you change the component and in order to test if the repair is correct, you need to put back totally the unit !
   It's about 2 hours work and if something goes wrong, you need to do it again !
   Unless to have a Roomba simulator , in order to test the electronic without the need to put it in a Roomba, is one of the worse case scenario for repairing a Roomba.

Also the deck gearbox can have problems :

1. broken gears
   Like the gears in the motor, the gears in the deck gearbox can loose teeth or broke down.
   Having other broken decks is possible to substitute the broken ones.
   
2. broken gearbox cage
   A couple of times I had to repair a gearbox deck cage broken.
   The gearbox cage is screwed to the deck and if broken can not keep the gears in the right place.
   Change the gearbox deck cage or the entire deck.

Wheels

The third typical problem with Roomba are the wheels.
The Roomba wheel is quite complex object. It is composed by four parts :

1. electric motor
2. planetary gearbox
3. sensor
4. tire

Each one of these elements can develop problems, but the most recurring problem is on the sensor.

The sensor is used to determine the speed  of the wheel and is very simple.

A special wheel with some openings is mounted on the main shaft and the light from an infrared LED can reach a photodiode only when an opening in the wheel happens.

The problem is that dust can, and does on time, cover the photodiode, so that become insensitive to the infrared light.

The result is that Roomba loses feedback from the wheel, starting to act crazy.

The phenomenon is well known as circle dance and usually cleaning the sensor solve the problem.
With some luck can be cleaned with compressed air, otherwise the wheel needs to be taken apart.

In all these years I own many Roomba, I never saw a planetary gearbox broken.
It is rare, but is possible to have tires used so much that the rubber is incredibly thin or the electric motor defective.