8/28/2010

LEDs are blinking!



Today I have been successful in getting the two LEDs blinking on the board, as the video will show.

A recap of what I did:


  • Install arm-elf-gcc toolchain, roughly using instructions from Madox.net. I used GCC-4.3.3 instead of 4.3.2. And, instead of using "/usr/local" as the prefix, I chose to use "/usr/local/arm" so that the executables don't get mixed in with other things in my OS. This caused a problem when building newlib because it depends on the gcc executable that should be in the path. Basically, "sudo" commands don't take on the path set in ~/.bashrc so when using "sudo make all install" to install newlib, the arm-elf-gcc is not found. This is solved by changing to root using "su" and manually adding /usr/local/arm/bin to the path. Not the best way to do it, but it works.
  • Install Flash Magic in WINE. This is easy. Download the installer EXE from flashmagictool.com and then run it in Wine and let it install wherever it wants.
  • Add a symbolic link in ~/.wine/dosdevices/ as follows: link com1 to /dev/ttyUSB0 to use USB serial port. With this, Flash Magic successfully uses the serial port to communicate with the LPC's bootloader.
  • Download sample code (by Martin Thomas) for similar processor, available here. This is for LPC23XX but it's very similar to LPC24XX. To be safe, I found the LPC24xx.h header file in a sample application zip folder provided by NXP, and used that instead of the 23xx.h included in the project. I used this sample code to create a template for HAC-1. Martin's webpage says this is set up for WinARM, but the makefile works just fine as-is on a Linux command line as well.
  • For now, I have removed much of what was in Martin's main.c file, such as the timer and UART functions. Martin had some LED blink code in there, but it was set for a particular commercial board where the LED is on a different pin, so I moved it to the pin that one of our LEDs is on and duplicated it for the second LED.
  • In the Common/src folder of the template, the setup routine in target.c is supposed to enable the PLL and start up the external 12MHz oscillator. For some reason the program doesn't seem to work in this case, so for now I have commented out the call to the function ConfigurePLL() and left the CPU running on the internal oscillator. Hopefully we can get this kink ironed out before moving on to the display controller; The 4MHz internal RC oscillator will not be sufficient for that.

It's alive!

It's been a while since we have made a post; not much has been going on until the last couple few weeks, when we finally got our boards fabbed and all of the parts.

Here is a mostly assembled HAC-1 board:


What has happened so far:

  • Soldering of 208-QFP CPU chip, TSOP DRAM chip on backside. For IC mounting, a soldering iron temperature of 300C was used. One of three attempts at the CPU mounting was a failure due to pins getting bent when appying too much heat trying to wick away excess solder. Next time, 280C might work better.
  • Add 5V and 3.3V regulators, connector for FTDI Chip TTL232R cable.
  • 1st attempt at communicating with CPU. At the time, we hadn't ordered our surface mount resistors and caps, so we wanted to try verifying CPU operation without the passives. We tried connecting using the Flash Magic tool (unfortunately Windows-only, but it looks like it should work with little trouble in WINE under Linux), and sent an "Erase Flash" command. The CPU did not respond.


Here's where a little bit of sloppiness on our part comes in (lessons learned.. for the nth time). Our first idea was to check the oscillator so we probed that with the scope, and were discouraged when we saw no signal on the oscillator circuit. However, according to the LPC 2478 User Manual, the chip contains a 4MHZ internal RC oscillator which is automatically used on startup. The external oscillator circuit does not start up until it is told to do so in software.

After obtaining and mounting the passives (all 0805 size, soldered at 280C), the CPU did indeed respond to the Flash Magic erase command! My suspicion is now that the lack of the pull-up resistor on the reset line may have been the cause of failure before. My assumption was that unconnected lines should tend to float "high," but I guess this is not necessarily the case.

The plan now:

  • UPDATED: Precompiled binaries from gnuarm.com did not seem to work. Will have to build from source. Not too hard to do, though.
  • Write and test simple standalone CPU code: LED blink, serial port, external memory test, LCD driver.
  • Add SD card interface, figure out how to configure U-boot or some other bootloader for ucLinux. Linux image should be stored on SD card.