Developer Resources for  68328 / 68EZ328 / 68VZ328 (includes some general 68K resources)

Words from the Dragon Slayer

Hello fellow developers this "site"  has been set up to assist those of you who wish to develop embedded systems using the Dragonball series of processors from Motorola. These processors provide great solutions for low power embedded systems requiring an LCD controller and other on-board peripherals.

It should be noted that the Dragonball series of processors has been made "famous" because of there use in Pilot/ Palm Pilot/ Palm PDA products originally from Palm Computing and then sold to US robotics who was bought out by 3Com who are now separating the Palm division. The original inventor (Jeff Hawkins) has started another company, Handspring, which is producing the Visor series of PDAs which also uses Dragonball processors. Another company, Royal, has produced a Palm look alike product called the DaVinci, which also uses a Dragonball processor. The point of all this gibberish is to point out that there are currently many successful products using the Dragonball series of processors. This site is not a PDA developers resource, in so far as PDA specific issues will generally not be published here. There are many great sites already dedicated to this (see links below). This is not to say that some, or all, of the information published here may not be of use to PDA developers.

The release of the 68VZ328 marks the start of a new point for the Dragonball series, until now 16MHz was it - the only speed available. Now the 68VZ328 sets the mark at 33MHz. The 68VZ328 is supposed to make it easier to connect color LCDs. With the up comming release of the color Palm PDA you can bet that they will be using a 68VZ328 processor (Just found out PalmIIIc is using 68EZ328 - strange!). Motorola have also announced a 20Mhz version of the 68EZ328.

Motorola have just announced two new versions of the Dragonball family, the Dragonball Super VZ (MC68SZ328) and the Dragonball MX1 (MC9328MX1). The Super VZ is based on the 68K core and runs up to 66MHz. The MX1 is based on an ARM9 core and runs up to 200MHz. There are lots of new peripherals in both processors including USB. The MX1 has a bluetooth interface. Sampling should be later this year (2001). To get to the preliminary documentation then following this link.

Below I have started a very crude set of helpful sections. I will add to this as time permits and would be grateful for any submissions from other developers (send to davidwilliams@ozemail.com.au). Please excuse the very low standard of page layout. This is my first time and I don't have much spare.

I am currently using the 68EZ328 processor in an embedded system.

Happy hunting,
Dragon Slayer (David Williams ).

(Note that this site is always under construction)

Motorola's Official Pages
Unofficial Bug List
Common Problems and Gotchas
Tips & Tricks
Developers Tools
Links to other 68K resources
Newsgroups & Mail Lists
IrDA stuff
Graphics: Fonts, Bitmaps etc. on LCD's
Downloads - show me the software
GDB stub
Wish List
68K books
Prebuilt Hardware
PDA Links

US Semiconductor site - wireless division
68328
 68EZ328
 68VZ328

Asia Pacific Semiconductor Site
68EZ328
68VZ328

Sometimes the Asia Pacific site has later info (sometimes not).

This list is for bugs/features that do not appear in Motorola's "release notes".

68EZ328 Maskset 1J75C

1. LCD Display Controller doesn't work with SRAM. Motorola reports various problems when using DRAM, however it also does not work with SRAM. Only fix is to use a later maskset (1J83G or later).

1. During development of software with the 68EZ328 I have found a common problem was not setting the I/O pin functions correctly via the relevant SEL register (eg. PCSEL to select either LCD function or general I/O pin) for the port that the I/O pin is on. This seems to happen easily as the description for most peripherals in the user manual rarely mentions this. Also don't forget to set the pull-up/down correctly for your system.

2. Gary Kato reported to "comp.sys.68k" news group the following "Gotcha".

I ran into a something when trying to let the Dragonball's UART receive FIFO control the RTS signal. According to the Users Manual, you should just be able to set a bit to do this, however it seems you have to turn the RTS signal off with its control bit (in the same register) in order for this to happen. It is like the manual control bit has precedence over the FIFO. The Users Manual implies the the FIFO has precedence (ignoring the RTS control bit).

3. DTACK on startup in bootstrap mode.

I found that DTACK (PG0) is not high when the processor starts in bootstrap mode. The user manual is not clear on this but it does suggest that this pin defaults to DTACK signal after a reset. I examined this on the CRO and discovered that there is a noisy low signal on this pin after a reset. Therefore the internal pull-up is not active or strong enough to pull this pin high. This problem has caught me out twice now! If you are going to use this signal as an I/O then dont connect it to something critical for bootstrap mode operation like the enable for the serial port transceiver - silly me.

1. Getting RAM to start at location 0x00000000 in memory map.

Why do this you ask. Well in 68K systems the interrupt vectors are stored in low memory. To be able to change them from your program code they need to be stored in RAM. This is a common design goal for 68K systems. Orgainising the mapping of ROM to location 0x00000000 to fetch initial PC and stack and then switching RAM to location 0x00000000 shortly after this is acheived in different ways for different 68K processors. I present here a simple method of acheiving this with Dragonball processors.

All 68K processors start by fetching the initial stack and Program Counter (PC) address from locations 0x00000000-0x00000007. The Dragonball processors map the device connected to CSA0 to all memory locations after reset. Therefore, for an embedded system, CSA0 must be used to decode your ROM device. The default size of the device connected to CSA0 is 128KB. Therefore if the actual device connected to CSA0 is at least 128KB in size then it will appear in memory repeated every 128KB. Therefore if your desired location for your ROM device appears on a 128KB location (it is almost impossible for it not to, given the available options in the chip select registers) then the initial PC can point directly at the starting location you wish to have your ROM located at even though you have not yet programmed the chip select registers so that it appears there. It appears there already because the ROM device is repeated through memory. Very early in the startup code the chip select register should be programmed so that CSA0 only appears at its desired location. As long as that is consistant with where it is assumed to be from the inital PC address then the CPU wont notice the change to the decoding of CSA0. After CSA0 has been programmed correctly then the chip select for the RAM can then be setup. The RAM can be programmed to start at location 0x00000000 as the code is happily executing from the ROM device elsewhere in memory.

Worked Example

2MB FLASH device, connected to CSA0 - to be mapped to location 0x00800000, also mapped to 0x00000000 after reset
256KB SRAM device, connected to CSB0 - to be mapped to location 0x00000000
Entry Point of code is 0x00000008 bytes into FLASH device (ie 0x00800008 in memory map)

Place 0x00800008 at location 0x00000004 of FLASH device (this is the inital PC)

Initialiser code sets CSA0 to start at location 0x00800000, CSB0 to start at 0x00000000

2. Using Hardware breakpoints without an emulation ROM.

The system I am developing uses a very small PCB and is jam packed with devices. There is no room to stick an emulation ROM and no room to stick a header that could take a daughter board to allow an emulation ROM to be attached during debugging. Also the extra cost of an emulation ROM device or inconvienance of having a daughterboard (to lose) are additional considerations. However I would still like to be able to use the on-board hardware break-point capability. It requires that the system be put into emulation mode. In emulation mode the CPU boots via the EMUCS signal which is used to decode an emulation ROM device that would typically store the debug monitor code.

I thought it would be good to be able to use the hardware break-points without going into emulation mode but Motorola have told me this wont work. (I tried it anyway but could not make it work). So my next plan is to get into emulation mode without using an emulation ROM! To do this I need to fool the CPU into thinking that it is entering emulation mode but then jump directly into my code stored in the normal ROM device.
 

I have worked out two different ways to acheive this...

2.1 Connect EMUCS to CSA0 via "and" gate (74LCX08)

Using an "and" gate to connect CSA0 and EMUCS together so that either chip select will select the ROM memory. In emulation mode the code will start executing from location 0x00000010 in the ROM device. You can then re-program the chip selects and disable the hardmap (see ICEMCR register description) and you then have full control.

I have tried out this solution using an ariel construction using an "and" gate (74LCX08) to connect together the CSA0 and EMUCS signals taking the output of the gate to the flash memory in my system. I ran into a "small" problem. The CPU sets A18 and A19 high during boot in emulation mode. This causes the CPU to read from high up in my flash memory. It would probably be better to gate these two address lines so that  the op-code fetched from the flash memory is near the start of the device. Also note that the emulation ROM is supposed to be an 8 bit device. When using the flash memory in my system (16 bit device) the CPU will in fact read the same location twice as A0 is not connected to the flash memory. This is not a problem if the op-code it fetches has the same byte in both the upper and lower bytes.  I also noticed that there are four types of exceptions that can be generated by reading various op-codes. As mentioned above you can use Trap 14 (0x4E4E).  You can also generate an illegal instruction exception by using an illegal instruction (eg 0x4F4F). You can also generate line 1010 (A Line) or Line 1111 (F Line) exceptions by using an op-code where the top nibble is either 0xA or 0xF.

2.2 Cause CPU to read fixed bit pattern when EMUCS is active (using a 74HC575)

By hardwiring the bit pattern 0x4E to the EMUCS signal (I am currently using a 74HC575, clocked by the system reset signal) the CPU will read a TRAP 14 op-code on every access to memory decoded by EMUCS. This op-code will cause the CPU to decode a vector from my ROM device (TRAP 14) and then jump to a the interrupt handler decoded from the vector. Thus any attempt to fetch an instruction from the emulation ROM will instead jump to the TRAP 14 handler.

The theory is that on entering emulation mode after a reset the trap 14 handler vector, which must be in ROM, will cause the CPU to jump to my appropriate initialisation code in the ROM. After the chip selects have been setup appropriately (see "Getting RAM to start at location 0x00000000 in memory map" above) then the TRAP 14 vector can be changed to point to the break-point handler function. Thus the trap 14 vector stored in ROM mimics the 0xFFFC0020 entry point for entry to emulation mode and the trap 14 vector placed in RAM mimics the 0xFFFC0010 entry point for break-points.

I have not tried this, I abandonned this idea in favour of the first suggestion above. I am fairly certain it would work though.
 

Note1: I have released a GDB stub that utilises the hardware breakpoint capability. See notes in software downloads section.
Note2: I have seen that 68VZ328 appears to support enabling emulation mode via software! This may make all of the above redundant on 68VZ328!
Note3: I have found that the 68EZ328 must have an external reset (taking RESET* low) to enter emulation mode. A watchdog reset will not cause the CPU to check if an emulation mode start request has been requested.

GNU GCC is a good option as the Dragonball is a 68K core and GCC has supported this for a long time. The code generation has been tested in the field for quite some time and is very good. It supports C and C++. Best of all it's free! Beware it is a little harder to get started than some commercial offerings, but not really that hard. GDB is a source level debugger that works with GCC. To use it with Dragonball processors (esp. to set breakpoints) you must either run your code from RAM so GDB can substitute op-codes at break locations or (for 68EZ328 and 68VZ328) you may use the emulation mode with the gdb stub I have written.

Pre compiled binaries for Windoze and Linux can be obtained from

Object Software  - DOS (djgpp) and WIN32 (mingw32) hosted binaries of GCC and GDB for 68K and PowerPC. These have now been removed!
David J. Fiddes Coldfire Developers Resources - WIN32 (cygwin) and linux binaries of GCC and GDB for coldfire (includes 68K). David has also made available many other resources for coldfire development (some of which may be useful for Dragonball developers).

Or you can download the sources and create your own cross compiler! See David J Fiddes site for details on creating the GCC compiler from published sources.

Mark Wyman has produced BBUGEZ32 a handy GUI utility for using the 68EZ328 in bootmode. It has a GNU licence so you can get the source too! This program can do lots of nifty things including font to C struct conversion, automated testing and burning and more.

RTEMS is a freely available RTOS that supports 68K (amongst others).  See  On-Line Applications Research Corporation (OAR Corp) .

EZAsm is a free "enhanced" assembler for Palm development. Should work for general embbeded stuff too.

Greg Colley's 68000 Editor/Assembler/Simulator full 68000 assembly IDE for Windoze. Great for teaching. Free for students and educational institutions.

BSCV  is a simulator/assembler/GUI environment - great for students.

WISM68 - The MC68000 Simulator for Windows. Free simulator/assembler/GUI.

The following companies have free 68K simulators available for download.
Lauterbach
Noral
SDS

Of course there are many commercial 68K toolsets and utilities that can be used...

Disassemblers:
 IDA Pro - Disassembler

Motorola 680x0 Resources - has references to some interesting old articles on optimisation for 68K range of processors as well as other useful links.

V68000, a synthesizable VHDL object code compatible core...  One semiconductor company has synthesized this into their deep-submicron standard cell library and optimized it to run at well over 100 Mhz!

The 68K FAQ is getting old now (last updated in 96!) but still has lots of useful information about the 68K range of processors (as well as some derivitives). This use to be posted regularly to the com.sys.m68k newsgroup but I have not seen it for a while now.

The following USENET newsgroups can often help you with problems

comp.arch.embedded
comp.sys.m68k

For GCC specific problems try crossgcc mail list.

The Dragonball series all have IrDA (SIR) support.

What a nightmare...Firstly I should qualify what follows - I have not as yet implemented any IrDA stuff on my system. I have been doing a lot of research into what stuff I should bung into my system and the follow discussion is derived from my research. Therefore it is unproven and provided as is blah blah blah.

From a software development point of view there is the question of how you can talk IrDA to your embedded application from a host (eg.a PC). Windoze(95 OSR2/98/2000) and Linux have support for IrDA. I have not looked at MAC as yet.

What support you put into your embedded device depends upon what devices you want to talk to....

IrDA and Windoze

Windoze provides two basic methods for using the IrDA protocol. Firstly Virtual Comm ports accessed via the serial port API and secondly the TinyTP protocol directly via the Winsock API. Virtual Comm ports allow you to use IrDA ports like comm ports, utilising the IrCOMM protocol. Winsock allows you to use the TinyTP layer of the IrDA protocol stack.

The IrMon applet that comes with Windoze allows you to set the comm port that will be used as the IrDA port. This allows you to select a IrDA port or standard RS232 port for IrDA communications. If the port selected is an RS232 port then the IrDA protocols will be used over a standard RS232 wired link. This can be useful for testing.

Windoze2000 drops the virtual comm port concept. It still allows access to the IrCOMM protocol, but in a more limited form via the Winsock API. This means existing application may have to be re-written to work with win2000 if they currently use virtual comm ports accessed via the serial port API. I suspect that this change will anoy a lot of people!

Windoze does not directly support the OBEX layer of the protocol stack. You can purchase third party support from Extended Systems - Quickbeam Suite. This also adds IrDA stacks to early versions of Win95 and NT4. As well as file transfer utilities and other stuff.

Microsoft have published some info on IrDA programming. See IrDA: Background and Overview from Microsoft MSDN online for programming information. Also see IrTran-P, IrLPT, and IrDA Networking Support under Windows 2000.

IrDA and Linux

The support for IrDA in Linux looks good. There appears to be support for IrComm, OBEX, TinyTP etc already. You will need Linux 2.2, and possibly some patches. Checkout the Linux/IrDA project for details of current support. I am not sure how the IrDA protocols are exposed to the developer in Linux, but I am sure it can't be that hard.

Useful links

Infrared Data Association - The IrDA standards can be downloaded from here. They also have a small message board for IrDA questions.
Linux/IrDA project - Lots of useful stuff including a survey of current products and the IrDA protocols they support.
Scenix is offering a free IRDA stack as virtual peripheral for there controllers (at about US$5.00 a piece).
The IrDA mail list is another useful resource and good place to discuss problems.

Commercial IrDA Protocol Stacks

EMBEDnet
ACTiSYS
Counterpoint Systems Foundry

Niall Murphy has written an excellent introduction to this subject. You can also check out some other useful articles he has written here.

I have posted here a collection of messages posted to the embedded newsgroup that deals with drawing lines and other shapes.

Mark Wyman has kindly donated some source code for drawing lines, rectangles, characters etc. Mark's comments: "They probably could use some more polishing, but hey, they are free. I hope they are useful and aren't too messed up to release. I have my own style of programming since I have taught myself, so some may criticize my methods. That is OK however since I am always willing to learn. These routines were designed all for 4 color display on a B&W graphic display of any size. It looks pretty sweet when in use and are blazingly fast." Mark has been developing a library of graphics routines which he plans to release soon. See his web site for more details. Mark's BBUGEZ32 has a feature to create C structures from windows font files.

Micah Dowty is developing PicoGUI for his Kiwi hardware (see hardware section below).

Ramtex International has an icon editor program that can work with fonts. (Cost is approx US$120.00).

BlueWind has a tool called bitfont that makes it easy to draw fonts and bitmaps to be used in embedded systems equipped with a graphic LCD.

If you find any of these utilities helpful or want to report any bugs or useful modifications then drop me a line. They were compiled with DJGPP as DOS executables. They use the standard C file I/O library so should run on all DOS and Windoze platforms. If anyone wants to port any of them to linux it should be really simple (perhaps only requiring to be recompiled under linux). Send me mods and exe and I will post here if anyone does it.

I have zipped up the following three utilities including source code for easy download: pcutils.zip

Srecord To Binary File Convertor

Early on in my use of the GNU tools I discovered that I needed to convert the output of the linker from Motorola S records to a binary file. I know there are many srecord to binary convertion programs out there but none of them fulfilled my needs. So I did the usual thing and wrote my own. Anyway this one is useful because it allows you to offset your binary file and also it recognised the full range of srecords. I found many of the currently available ones did not recognise all record types.

Note: I found a small bug in the first version that I released here. I have fixed this and updated the pcutils.zip file to include the new source and executable.

Wave file to C file convertor

Another useful utility that I have written is a wave file to C file convertor. It converts a Microsoft 8 bit mono uncompressed wave file to C source code. The C source file created contains a single array with the sampled data. See the top of the source code for more details.

Note there is a utility in the PPSM utilities provided by Motorola that claims to be able to do a similar conversion. I tried it and then examined the source to find that it did not really work. It does not read the header information in the wav file and so cannot convert properly.

Bitmap file to C file convertor

This utility converts 2 color (monochrome) uncompressed microsoft bitmap format (2.x, 3.x, 4.x) files to C source code. The C source file created contains an array of data that represents the bitmap and another structure that defines the parameters of the bitmap (height, width etc).

More Utilities

Eric Nelson has kindly donated the following utilities (currently binary only for win32).

Binary to S record convertor
S record to 68EZ328 boot loader format convertor

GDB Stub

The gdb stub I wrote can be obtained from 

The stub is some code that can be linked in with your application to allow GDB to debug your application. The stub is not a complete application or 'monitor' as such. It requires that the target is initialised appropriately. It could be made into a monitor for a particular target by writing a small program that sets up the target and then passes control to the stub. You could then use GDB with this 'monitor' to load and debug your application in RAM. I use the stub in a different way. I link it with my full application and then use a separate utility to burn the whole application into the flash memory on my target. I start GDB and just load the symbols from the object file and then start debugging.

It requires the use of a serial port to communicate with GDB. The 68EZ328 has only a single serial port. This version of the stub uses this internal serial port and so debugging parts of the application that use the serial port is difficult. I am thinking about implementing a software UART using the control lines so that I can have a debug port separate from the normal application serial port.

See assumption at top of source module 'gdb-68k-ez328.c'. Make sure that you can live with these assumptions. Otherwise you will need to modify the source!

The stub also assumes that the vector table is in RAM! If not then you will need to modify source.

Place a call to gdb_init() in your source to start gdb.

When running GDB invoke it using 'gdb -b 115200' replacing 115200 with the baud rate you are using. Once GDB has started then you can use the command 'target remote com2' replacing com2 with the actual serial port you are connected to.

1. A small 80x80 pixel (approx) black and white LCD display that is a standard offering from an LCD manufacturer. A mobile phone graphic display would probably be ideal.

2. A small speaker (max. 2cm diameter) that can deliver speech at a reasonable volume from 1-2 meters away from speaker! Might just be impossible!

Bibico Cando suggested

"Microprocessor Systems Design : 68000 Hardware, Software, and Interfacing" by Alan Clements. PWS Pub. Co.; ISBN: 0534948227
I own this book and find this is a good book to understand, 68K based mechanisms, Interrupt, FPU, and...
IMHO, the following is pretty good:

Chris Quayle suggested

"The Motorola MC6800 Microprocessor Family: Assembly Language, Interface Design and System Design." by Thomas L. Harman & Barbara Lawson. Prentice Hall, 1985. ISBN: 0-13-603960-X 01
I found this excellent, it became my bible for 68K, It covers everything in some detail, even has a good description of stack frames.

"MC68000 Assembly Language and Systems Programming." by William Ford & William Topp. DC Heath and Co. 1988. ISBN: 0-669-16085-7
This isn't as good as the first, but has usefull fillin material

"Dr Dobbs Toolbook of 68000 Programming" A Brady book, published by Prentice Hall. 1986 ISBN: 0-13-216649-6 (Hardback) 0-13-216557-0 (Paperback)
This is quite good. Stuff like Tiny basic, Forth, the ECB Tutor firmware and a simple multitasking kernel. Good book for getting the ideas flowing.

Paul E. Bennett suggested

"68000 Microprocessor Assembly Language Programming" by Lawrence Leventhal. It covers the subject quite well for the original 68000 chips but you may need to look at a few other publications for some of the later ones.A quick search on amazon.com did not come up with this book.  It's probably out of print--I remember it from 1982 or so.  I can't recall any recent books covering the 68xxx family.

Motorola also has many 68K books and other resources (see their web site).

Were can I get a board/device with a Dragonball already loaded you ask? There are several options.

1. Buy one of the Application Development Systems (ADS) boards from Motorola. There are 68EZ328 and 68VZ328 versions available. These are designed for developers to start writing and testing software before their own hardware is ready. This is the most expensive option.
2. Buy a PDA with a Dragonball processor inside. The original Palm (pilots) used the 68328. Later version Palm III and later (I think) use the 68EZ328. The DaVinci from Royal uses a 68EZ328 (I think). The original Visor from Handspring uses the 68EZ328. More recent models, the Prisim and Platinum, use the 68VZ328. There are software development kits, including simulators,  for these PDAs and there are versions of GCC prebuilt for these devices as well.
3. Buy a simm module from Rt-Control Inc. It has a 68EZ328 processor Has 2MB Flash, 8MB DRAM, Ethernet controller and more for only US$210.00. It has been designed to run uClinux. I have heard that they are developing a VZ version of the uSimm, but have not heard about a release date.
4. Look at OpenHardware.net for "open source hardware" - they have a 68EZ328 simm module. Not prebuilt - but circuits and PCB files available for download.
5. Mark Wyman is producing a microController board with a 68EZ328. It has an interface for 1/4 VGA LCD, two A to D convertors and more.
6. Embedded Computer Technology has a 68328 adaptor for breadboarding a 68328 processor.DragonDapter, A printed circuit adapter board for the Motorola MC68328 'DragonBall' MPU.This adapter board allows the 144 pin QFP surface mounted MPU to be used on a standard breadboard. I dont think that these guys are in business anymore as email sent to them was return as user unknown! If anybody knows what happened to them then let me know.
7. Micah Dowty is producing the 'Kiwi' - a small computer that runs uCLinux and is based on 68EZ328 MPU.
8. SDT International sells the DragonEngine II. "The DragonEngine II is a small embedded microcomputer engine based on Motorola's DragonBall™ VZ microprocessor. It has on board DRAM, Flash EPROM, multiple serial ports, Ethernet port, LCD controller, touch screen controller, 12-bit A/D converter, power supply , etc"
9. Daniel Haensse has set up a project at open hardware called Dragonix VZ.

In case you were really looking for PDA developers resources here are some

Wade's Pilot Programming FAQ - A bit old, but may still have some useful info and links.
3Com Palm Developers Zone - 3Com's official developers support site.
Handspring Developers - Handsprings official developers support site.
EZAsm - An enhanced assembler - lots of links on this page.
Dr Joes Palm Pilot Page - Plenty of links here
 

Mark Wyman, Andrew Davies, Eric Nelson.