Esden's Blog - thc

THC Address Space

Esden — Wed, 10 May 2006 00:00:00 +0000

I have created a small memory map displaying the current usage of the address space in THC.

0x0000_0000	Bank 0. ROM address space.
0x00FF_FFFF
0x0100_0000	Bank 0. Unused address space.
0x01BF_FFFF
0x01C0_0000	4M bytes reserved for Special function Registers. This area contains S3C44B0X special registers to control the processor itself and the peripherials that are integrated into the chip.
0x01BF_FFFF
0x0200_0000	Bank 1. This bank is currently unused. Probably the Graphics controller will get mapped to this memory area.
0x03FF_FFFF
0x0400_0000	Bank 2. Key control. In this area the key control circuit is being mapped. Through reading some of the addresses in this area you get access to the current state (pressed/not pressed) of the keys in THC. (more details to come)
0x05FF_FFFF
0x0600_0000	Bank 3. Currently unused.
0x07FF_FFFF
0x0800_0000	Bank 4. Currently unused.
0x09FF_FFFF
0x0A00_0000	Bank 5. Currently unused.
0x0BFF_FFFF
0x0C00_0000	Bank 6. SRAM address space.
0x0C7F_FFFF
0x0C80_0000	Bank 6. Unused address space.
0x0DFF_FFFF
0x0E00_0000	Bank 7. Currently unused.
0x0FFF_FFFF

THC RAM banks

Esden — Wed, 10 May 2006 00:00:00 +0000

Many parts in the schematic of THC have been based on the schematic of the S3CEV40 board schematic. This applies for example to the RAM wiring. I understood the overall idea but one detail was still a riddle to me, until yesterday.

As you can see in the following screenshot of the schematic the bank select pins BA0 and BA1 are connected through a set of 4 resistors to the address pins A21, A22 and A23 of the processor.

That is a strange setup, don't you think? Well, I dug into the documentation of the RAM chip and the processor and found out that when I am using an 8MB SDRAM chip with 4banks x 1MB x 16bit for S3C44B0X (the processor) I have to connect the address pins A21 and A22 to the bank select pins BA0 and BA1 of the RAM chip. But in case I want to use a 16MB chip with 4banks x 2MB x 16bit I have to connect the address pins A22 and A23 to the pins BA0 and BA1. !bam! finally I knew what was going on! The design of the evaluation board is made in such a way that you can put an 8MB or a 16MB RAM chip on it. And to match the address pin connection they put only two of the four resistors on the board to match the connection. I today checked that on the real board. Here is an image of the relevant part of the board.

As you can see my thoughts were right. Only two of the four resistors are in place. In my case there is an 8MB RAM chip and so only the upper alterating pair of resistors is in place.

Yes it is pretty simple, I know. But when you look at the schematic you do not think about the purpose of such a set up at first. I am still learning to think in the terms of hardware design so this was a challenge for me.

There are still many riddles to be solved. One that I know of is the way the keypad on the eval board is connected to the chip. I will write about that when I know more about it.

First encounter with S3CEV40

Esden — Mon, 08 May 2006 00:00:00 +0000

Some time ago I got the S3CEV40 evaluation board from Embest. This is a nice board featuring an S3C44B0X ARM7TDMI microcontroller, ROM, RAM, RS232, USB, Sound, Ethernet, Keypad and a Display. A nice starting point for THC work. The decision why I picked that board are described in the previous post.

As I got the board I found out that there is a test software already flashed on the board. I tested it and everything seemed ok. It took some months till I really took the challenge to get everything working. First I wanted to flash linux on the board. To do that I needed a JTAG device and flash software.

On the site of Embest there is a description how to build a JTAG cable by yourself. I soldiered one and installed a demo version of the flash software on a machine. Sadly I had to find out that the device I soldiered did not work as it should. Next step was to find a different device. I had a development kit for ARM devices from Keil available with a matching JTAG device. I connected it up and after calling Keil two times for help I managed it to flash the board with the binaries that were supplied on the CD for the evaluation board.

The problems I had were the following. The binaries on the CD were flat binaries. (the raw binary data) The Keil software can not read binary files so I had to convert them to something Keil would understand. I got a very nice open source program called srecord from the internet and converted the binaries with some offset to intel hex files. Strange thing was that Tasking reported that the files are broken. I called Keil and they told me that I should call the file not .hex but .h86 . I did that and !bam! it worked. I really do not understand why they do not have a propper parser that could distinguish the file format by the content of a file.

After these fights I could flash the board.

Now the next step was to get the uClinux distribution contained on the supplied CD to compile. It also did not work from the beginning but the only thing I had to do was to make sure all files in the uClinux distribution have 'n' ending and not 'rn' and !bam! it worked too.

Now I had my selfcompiled linux kernel + userspace that I could flash.

The last thing that was not in my hands was the bootloader. The bootloader on the CD was only in binary format and the sources were missing. I looked in the binary and found out that it is the common ARM bootloader called blob that was patched by Embest. So I called BSM-Technik and got some sources. These were wrong at first (not matching the binary) but after I asked once more I got the right sources and after some hacking I got them to compile too.

The problem was that when I compiled the bootloader and flashed it on the board I got no response. So I fired up Keil debugger and read the disassembled code. Stepped through and looked what was wrong. After some hours stepping through the pure assembler I found out that the drivers the bootloader needs were not in the binary. After some more hours I found out that because I used GCC 4.0 and not 2.95 the driver stuff got optimized out from the binary. I only had to remove the -Os command line switch for GCC and !bam! the bootloader worked.

So now I have my own linux kernel + userspace + bootloader all compiled by myself. So now I have a good starting point for writing my own software.

I still have a dream... I would like to have the 2.6.x linux kernel working on this board but that still is a big problem. I compiled the kernel but it throws a kernel panic... but for now I will work on other things before I invest my time in that.

First steps towards THC design (UPDATEx2)

Esden — Mon, 08 May 2006 00:00:00 +0000

On last thursday I started with drawing the schematic for THC. I also worked on weekend on it and now I have pretty many things wired in the schematic.

This is the list of devices that are already in the schematic and wired:

S3C44B0X (Main processor)
SST39VF320 (ROM)
HY57V641620HG (RAM)
Power supply (wall plug)
RTC power supply with battery
JTAG plug
Reset circuit
Main system oscilator circuit
RTC oscilator circuit
RS232 serial IO
Bluenicecom BlueTooth interface board (based on LMX9829 chip)
UDA1341TS (Sound interface)

What is still missing:

Key interface
Display controller (will probably be the Lime chip by Fujitsu)
Display
Battery power supply
SD Cardreader
Speakers

After I have made the schematics for the missing parts I think I will be able to start designing the PCB.

I am pretty happy with the progress till now. If you have any specific questions do not hesitate and write me. ;)

UPDATE: Added SD Cardreader to missing parts UPDATE2: Added Speakers to missing parts

THC controller interface

Esden — Mon, 08 May 2006 00:00:00 +0000

During the last weekend I thought a bit about the controller interface of THC. I found that using buttons for the cross would be a pretty big mechanical hassle. I found a solution to that at Alps. Here it is. This 8-Directional mini joystick seems to be pretty cool. Don't you think?

I also found a solution for the shoulder buttons in their product line. You can see it here.

I also called Alps today and asked for some samples. They redirected me to a supplier and he said that they will send me them. I will update you as soon as I have them.

(it is pretty funny how happy one can be, just because he is getting some switches ;) )

THC schematics rev6

Esden — Mon, 08 May 2006 00:00:00 +0000

Here are the current schematics of THC. I will be happy about every constructive feedback.

THC test programs

Esden — Mon, 08 May 2006 00:00:00 +0000

Another good news for today.

I just managed it to compile test programs for S3CEV40. To explain, the CD supplied with the board contains some small programs to test functionality of the board. For example 8LED test (driving a small 8 segment led display), LED test (driving the two led's on board, RTC test, LCD test and so on... Untill today I had problems with compiling them, because the project files were not complete or had wrong paths or other things. I now found out what the right settings are and I am able to compile them with the Education version of the Embest IDE.

Thanks to these tests I found some thing out. For example that something is wrong with the LCD (it has a blank area in the middle of the screen) or that the RTC battery is drained. I will have to get a new battery tomorrow to see if it works then. The problem with the LCD is not really important, because I will use other system to drive the LCD in the future, anyways.

But still it is good that I have these tests now. I can later apply most of them to the THC prototype to test the subsystems. So I can only say "YEY ... another step forward." ;)

Finding the Controller

Esden — Thu, 06 Apr 2006 00:00:00 +0000

As you already know from the previous post the decision which microcontroller architecture to use was set pretty fast. Now the time came to find a chip and evaluation board for that project. The search took some months as my practical training ended and I came back to study. Finally with help from a developer, at the company I was working for at that moment, we finally found a chip and an evaluation board that seemed to fit the future projects, as also THC.

We decided that S3C44B0X would be the right choice and that the board S3CEV40 from Embest would be the right choice. We also found a distributor in Germany BSM-Technik.

Why did we decide that S3C44B0X would be the right one, you ask? Well... we wanted something that we can soldier by ourselves. That means that the packaging should be something like a QFP (Quad Flat Package). That are the chips where you see the pins on the sides. In the case of QFP you have the pins extending from all four sides of the package. Sadly the most ARM chips are produced only in BGA (Ball Grid Array) packages. These packages have a matrix of balls at the bottom of the package that are the contacts. To soldier BGA you need special equipment that we did not have. That would mean that we have to ask someone to soldier it for us. And that sux(TM). ;)

You say that there are other chips that have these specifications? There were also chips in QFP packages from Atmel and Philips but Atmel is expensive and Philips is not powerful enough.

THC The beginning

Esden — Thu, 06 Apr 2006 00:00:00 +0000

Ok let's start. How did the whole story start...

Somewhere around one year ago I started practical training at a company producing hardware and also developing it. Seeing it I thought that it would be cool to create something in the style of blinkenleds there was also a prototype but finally I saw that many people were doing it so I came to the conclusion that it did not really make sense. I wanted to create something new that no one has done before.

From that point I thought that it would be better to get a bigger display and more features.

As I loved to play gameboy as I was a kid I came up with the idea that it would be cool to create a device that would have similar features. A display, some controls and a speaker.

After a session discussing the idea with Daniel Reutter we also came up with the name: "THC" that stands for "The Handheld Circuit". And the idea was born.

THC Preludium

Esden — Thu, 06 Apr 2006 00:00:00 +0000

I finally decided that I should write about the THC project and the current progress. I also decided that it should still remain private because I do not want to disturb the public. Still there are some people that may want to read it so I added that private posting capability to WordPress.

If you want to read the RSS feed you can link your RSS reader to http://www.esden.net/blog/feed/atom?http_auth=yes. Your RSS reader should ask you for your user and password you provided while registering to my blog.

I hope you will enjoy the story ;)

The features

Esden — Thu, 06 Apr 2006 00:00:00 +0000

The list of requirements for THC changed a lot during the last year. But the basics remained the same.

- It has to be handheld (Battery powered) - A display - A microcontroller - A possibility to create sound - A SD Card reader (To store games, applications and media on it) - Some way of connectivity Bluetooth, USB and or serial (Which ones varied also a little) - Gamepad controls: A cross or a joystick, some buttons

First design that did not get finished used an M16C microcontroller that was used, at company I was working for, for many projects already. Soon I came to the point that it will not be enough and that people will have problems with writing their own software of it because there was or even still is only a commercial compiler for windows available.

After some thinking and googling and talking with the lead electronics designer, in the company I was doing my practical training, we came up with the idea that an ARM microcontroller would be the best choice. This architecture is supported pretty well under Linux, Mac OS and Windows and there are GNU tools to compile for that architecture. Linux also does run on these microcontrollers. That is at least what we thought at that time. Another motivation to choose that chip for that project was that the company I was working for could use it for newer projects that require more power then the M16C could provide.

The other components drifted very often between different manufacturers and solutions. The first design containing the M16C chip was targeted at a small LCD display that we already used for a different product but it was small and slow. Not really a good choice for a device that should be able to display high paced animations, something you would expect from a gaming/multimedia device. At that time I also saw some OLED (Organic LED) displays that amazed me with brightness and contrast. But soon I also realized that this also can not be the solution because the displays are very expensive, and the massively produced ones are pretty small. We also had a prototype of such a display to test it but it was flickering terribly. So I had to leave the idea too.

Sound... yes that is the component that I made myself the least thoughts about. Something with a AC97 codec would be nice but a beeping piezo speaker would be enough for the beginning.

SD cardreader was one of the easiest parts. We had a sample of a slot for SD Cards from Glyn and that will do it's work very good. So that component was also set pretty early.

Which connectivity to use was the next thing. Providing Bluetooth would be pretty easy as we already used a module using an LMX chip that could be connected to the serial port of the microcontroller. USB? That is something for the future so I did not make a lot of thinking about that. Serial was another pretty easy thing. The microcontroller provides a serial port and the only thing you need beside that is a level shifter. That is really no real problem.

The last thing to think about were the controles. After a short time I was sure that A/B buttons would not be enough beside the cross/joystic controller. So I ended up with A/B/C/D block with addition of (L)eft shoulder and (R)ight shoulder buttons and (S)tart and s(E)lect buttons. That should be enough for most things that one would like to do with the device. The problem that remained was the cross/joystick, but I would think about that later.

So I ended up with a feature list like this one:

- Portability: Battery powered (Dough!) - A display: something bigger with fast refresh rate and reaction time, so that it is usable for multimedia. - Microcontroller: An ARM (Which one exactly still had to be found out) - Sound: at least a beeping piezo speaker connected to one of the timer interrupt ports or so. - SD Cardreader: (The one we got from Glyn) (If every decision would be so easy) - Connectivity: Bluetooth (LMX chip already used, by the company I was working for, for some products), Serial (We already need it for debugging so this one is a sure thing), USB (The time will show, "perhaps") - Gamepad controls: Cross/Joystick plus A/B/C/D block plus (L)eft shoulder and (R)ight shoulder buttons and (S)tart and s(E)lect buttons

Puhh that took months to decide. It sounds crazy but really all that was not as easy as it sounds.