Flameman/m105 - Revision history

Flameman at 08:12, 17 June 2011

2011-06-17T08:12:58Z

Peter Huewe: Added to category 68k

2011-04-12T20:39:01Z

Added to category 68k

Peter Huewe: Added some text to Flamemans index link

2011-04-12T20:33:12Z

Added some text to Flamemans index link

Peter Huewe: spellcheck

2011-04-11T20:48:31Z

spellcheck

Flameman: /* doc */

2011-04-05T09:05:19Z

‎doc

Flameman: /* Common problems and Gotchas */

2011-04-05T09:03:31Z

‎Common problems and Gotchas

Flameman: /* Unofficial Bug List */

2011-04-05T09:01:47Z

‎Unofficial Bug List

Flameman: /* Unofficial Bug List */

2011-04-05T09:01:19Z

‎Unofficial Bug List

Flameman: /* doc */

2011-04-05T08:57:13Z

‎doc

Flameman: /* doc */

2011-04-05T08:56:52Z

‎doc

@@ Line 334: / Line 334: @@
 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.
 [[Category:68k]]

← Older revision		Revision as of 20:39, 12 April 2011
Line 334:		Line 334:
	Note2: I have seen that 68VZ328 appears to support enabling emulation mode via software! This may make all of the above redundant on 68VZ328!		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.		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.
		+
		+
		+	[[Category:68k]]

@@ Line 1: / Line 1: @@
-[http://www.elinux.org/Flameman#master_index]
+For more interesting projects done by Flameman, be sure to check out his [[Flameman#master_index|project index]]
-−
 = Palm-m105-m68328-Flameman =

@@ Line 11: / Line 11: @@
 == Note ==
-i'm developing for this board, the wiki page will be improved soon
+I'm developing for this board, the wiki page will be improved soon
 feel free to contact me (see the contact below)
@@ Line 293: / Line 293: @@
 === Tips & Tricks ===
-* 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.
+* 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. Organizing the mapping of ROM to location 0x00000000 to fetch initial PC and stack and then switching RAM to location 0x00000000 shortly after this is achieved in different ways for different 68K processors. I present here a simple method of achieving 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 consistent with where it is assumed to be from the initial 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
@@ Line 301: / Line 301: @@
 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)
+Place 0x00800008 at location 0x00000004 of FLASH device (this is the initial PC)
-Initialiser code sets CSA0 to start at location 0x00800000, CSB0 to start at 0x00000000
+Initializer code sets CSA0 to start at location 0x00800000, CSB0 to start at 0x00000000
 * 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.
+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 inconvenience 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...
+I have worked out two different ways to achieve this...
 * Connect EMUCS to CSA0 via "and" gate (74LCX08)
@@ Line 327: / Line 327: @@
 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.
+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 initialization 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.
+I have not tried this, I abandoned this idea in favor 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.
+Note1: I have released a GDB stub that utilizes 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.

@@ Line 257: / Line 257: @@
 == doc ==
 -04: just opened, but it will be used for "doc & versioning" http://code.google.com/p/m68328/wiki/first
@@ Line 274: / Line 273: @@
 * "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.
 * "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.
 === Unofficial Bug List ===
@@ Line 282: / Line 282: @@
 * 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).
 * address registers are corrupted in higher bit, SRAM is not directly connected to the address bus, it is connected to DRAM controller with uses CAS and RAS addresses, anyway A22,A23,A24 are multiplexed with GPIO and these bit are set to 1 ... palm hack is not reporting correct information when i dump register
 === Common problems and Gotchas ===
@@ Line 288: / Line 289: @@
 * When 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).
 * 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.
 === Tips & Tricks ===
-. Getting RAM to start at location 0x00000000 in memory map.
+* 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.
-−
 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
@@ Line 307: / Line 305: @@
 Initialiser code sets CSA0 to start at location 0x00800000, CSB0 to start at 0x00000000
-. Using Hardware breakpoints without an emulation ROM.
+* 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.
@@ Line 316: / Line 313: @@
 I have worked out two different ways to acheive this...
-.1 Connect EMUCS to CSA0 via "and" gate (74LCX08)
+* 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.

@@ Line 285: / Line 285: @@
 === Common problems and Gotchas ===
-. 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.
+* 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.
+* When 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).
-. Gary Kato reported to "comp.sys.68k" news group the following "Gotcha".
+* 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.
-−
-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).
-−
-. 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.
-−
 === Tips & Tricks ===

@@ Line 277: / Line 277: @@
 === Unofficial Bug List ===
-This list is for bugs/features that do not appear in Motorola's "release notes".
+This list is for bugs/features that do not appear in Motorola's or Palm's "release notes".
 * 68EZ328 Maskset 1J75C

@@ Line 258: / Line 258: @@
 == doc ==
-just opened, but it will be used for "doc & versioning"
+=04: just opened, but it will be used for "doc & versioning"
-−
 http://code.google.com/p/m68328/wiki/first
-if you need information/help, you could contact by email ( flamemaniii@gmail.com )
+-03: sorry still not time to update that page, so if you need information/help, feel free to contact me by email