68332 CSBOOT* help?
Russell Magee
I feel bad asking this question, but I'm under the gun, so to speak, and
my boss is getting very uncomfortable with some upcoming deadlines, so I'd
appreciate any info!
The situation is this: We're in the process of porting OS-9 to a 68332
system with SRAM, serial stuff etc. Now according to the board's designer,
the system has been designed to be as close to the 68332 EVS as possible.
There are two major (minor?) differences, though: the static RAM's
Write chip selects are swapped with respect to the EVS's RAM setup (CS0-1).
No prob, that's just a minor change in the config files and a new make of
RomBug. Second difference, the EPROM is one 16-bit wide 27C1024 instead of
two 8-bit wide EPROMS.
It made sense (to me) to get OS-9's RomBug up and running on the EVS first.
So far, so good. RomBug comes up fine. Now, I try out the slightly massaged
RomBug on our '332 system, and PLOP. Nothing, except the CPU gets stuck in
an endless cycle of RESET*/HALT*. However, if I assemble the SAME code, but
at origin $0 instead of origin $60000 (where the EVS expects its ROM), the
CPU actually seems to start out ok. (A logic analyzer we borrowed actually
showed the initial SP/PC fetch, and the first few branch instructions being
found in the EPROM, from base $0.)
I can't seem to figure out how CSBOOT* is mapping the EPROM in the '332's
address space. The EVS executes Rombug fine at $60000; the start of the
EPROM is like this:
Offset 00 01 02 03 04 05 06 07 . . .
------ -- -- -- -- -- -- -- --
$00000 00 00 49 00 00 06 04 c4 ..
This means the CPU's initial SP will be $4900, PC will be $6004c4, which
works. But HOW does the EVS find the EPROM at $60000 immediately after
bootup? My understanding of the 332 is that the EPROM (and all other
peripherals hooked up to the chip select lines) must be mapped into
memory by the boot code (via the CSAR/CSORs). If this is so, how does
the EPROM get up to $60000 at the very start?
A local hardware guru we've talked to says that the '332 must execute
the EPROM from $0.l after a reset, then the software must remap the EPROM
afterward if desired.
Sorry for the long message. I am kind of at a dead end here...email replies
would be appreciated.
-Russ Magee
ma...@cpsc.ucalgary.ca
Thomas Doerfler
> Hello all,
> It made sense (to me) to get OS-9's RomBug up and running on the EVS first.
>So far, so good. RomBug comes up fine. Now, I try out the slightly massaged
>RomBug on our '332 system, and PLOP. Nothing, except the CPU gets stuck in
>an endless cycle of RESET*/HALT*. However, if I assemble the SAME code, but
>at origin $0 instead of origin $60000 (where the EVS expects its ROM), the
>CPU actually seems to start out ok. (A logic analyzer we borrowed actually
>showed the initial SP/PC fetch, and the first few branch instructions being
>found in the EPROM, from base $0.)
> I can't seem to figure out how CSBOOT* is mapping the EPROM in the '332's
>address space. The EVS executes Rombug fine at $60000; the start of the
>EPROM is like this:
>Offset 00 01 02 03 04 05 06 07 . . .
>------ -- -- -- -- -- -- -- --
>$00000 00 00 49 00 00 06 04 c4 ..
>This means the CPU's initial SP will be $4900, PC will be $6004c4, which
>works. But HOW does the EVS find the EPROM at $60000 immediately after
>bootup? My understanding of the 332 is that the EPROM (and all other
>peripherals hooked up to the chip select lines) must be mapped into
>memory by the boot code (via the CSAR/CSORs). If this is so, how does
>the EPROM get up to $60000 at the very start?
You are right, all CSx-lines will be inactive after reset, with
exception of CSBOOT. It will be active for the first Megabyte (range
$000000-$0FFFFF), having 13 Waitstates, for Read and Write cycles. So
your exception vectors and your Code is reachabe at $60000.
There is one more setup item required. It is, whether the EPROM is
exepected to be 8 bit wide or 16 bit wide (which is your
configuration. The '332 can read 16 bit per cycle in your system).
This is determined by the state of data bus line DB0 during reset (See
"Chip Select Pin Assignment Register 0"). In your case, DB0 must (!)
be high during reset. Normally this is accomplished with weak pull up
resistors in the '332, but sometimes external devices can disturbe
this pull-up. So you (or your hardware guy) should watch this
carefully.
Note, that some other selections are made with this mechanism as well
(but with different data lines).
By the way, why don't you use the background debug interface? Motorola
offers a software for the PC, called BD32 for free(!), and it allows
to whatch the CPU single step through your boot code. Even if your
boot code where totally wrong,(which I don't expect), you could still
inspect the EPROM contents AS SEEN BY THE CPU, the on-chip registers
including the CS-Unit and so on. You just have to install a small
interface (two TTL chips in handywork) between your PC parallel port
and your '332. See "Development Support" in the '332 User's manual".
This interface is absolutely genuine for debugging boot code, and it
works!!
So I wish you success, if you have any more questions, please mail me.
By, Thomas.
P.S: Where did you program your 16 bit EPROM? I once had a similar
problem, it took me half a day to understand, that I made the EPROM in
a wrong way. I programmed it on a universal programmer connected to a
PC, and due to the "intel-hosted" environment, the programmer actually
wrote the bytes in "little-endian mode" rather than big-endian, so all
bytes were swapped in the EPROM...
--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler Elilandstrasse 12
D-81547 Muenchen Germany
email: i...@m.isar.de
Patrick Powell
: Hello all,
: I feel bad asking this question, but I'm under the gun, so to speak, and
: my boss is getting very uncomfortable with some upcoming deadlines, so I'd
: appreciate any info!
: The situation is this: We're in the process of porting OS-9 to a 68332
: system with SRAM, serial stuff etc. Now according to the board's designer,
: the system has been designed to be as close to the 68332 EVS as possible.
: There are two major (minor?) differences, though: the static RAM's
: Write chip selects are swapped with respect to the EVS's RAM setup (CS0-1).
: No prob, that's just a minor change in the config files and a new make of
: RomBug. Second difference, the EPROM is one 16-bit wide 27C1024 instead of
: two 8-bit wide EPROMS.
: It made sense (to me) to get OS-9's RomBug up and running on the EVS first.
: So far, so good. RomBug comes up fine. Now, I try out the slightly massaged
: RomBug on our '332 system, and PLOP. Nothing, except the CPU gets stuck in
: an endless cycle of RESET*/HALT*. However, if I assemble the SAME code, but
: at origin $0 instead of origin $60000 (where the EVS expects its ROM), the
: CPU actually seems to start out ok. (A logic analyzer we borrowed actually
: showed the initial SP/PC fetch, and the first few branch instructions being
: found in the EPROM, from base $0.)
: I can't seem to figure out how CSBOOT* is mapping the EPROM in the '332's
: address space. The EVS executes Rombug fine at $60000; the start of the
: EPROM is like this:
: Offset 00 01 02 03 04 05 06 07 . . .
: ------ -- -- -- -- -- -- -- --
: $00000 00 00 49 00 00 06 04 c4 ..
: This means the CPU's initial SP will be $4900, PC will be $6004c4, which
: works. But HOW does the EVS find the EPROM at $60000 immediately after
: bootup? My understanding of the 332 is that the EPROM (and all other
: peripherals hooked up to the chip select lines) must be mapped into
: memory by the boot code (via the CSAR/CSORs). If this is so, how does
: the EPROM get up to $60000 at the very start?
: A local hardware guru we've talked to says that the '332 must execute
: the EPROM from $0.l after a reset, then the software must remap the EPROM
: afterward if desired.
: Sorry for the long message. I am kind of at a dead end here...email replies
: would be appreciated.
: -Russ Magee
: ma...@cpsc.ucalgary.ca
Russ, the 68332 has a special signal sequence that is sent out during
the first couple of memory accesses after reset. This signal sequence
is usually decoded by a PAL to produce a BOOT ROM Chip Select signal.
In addition, usually the address signals are decoded as well, allowing the
Boot Rom to be accesss. Now the 68332 also has on-chip memory decoding,
which allows some of the output pins to be used as chip selects.
So you can get some pretty strange effects if you do not know what you
are doing at the hardware/software level.
Moral of the story: you need the PAL equations for the support chips,
a circuit diagram, AND a COMPLETE listing of the startup code.
Then you start poking around... for weeks sometimes...
I am curious - who is making the EVS clone? I would be interested in a
couple of these.
--
Prof. Patrick Powell
Dept. Electrical and Computer Engineering,
San Diego State University,
San Diego, CA 92182-1309
Office (619) 594-7796; Lab (619) 594-7578 FAX (619) 594-7577
email: papo...@sdsu.edu
Ajay Mahagaokar
Path: bose!news.ultranet.com!bigboote.WPI.EDU!news.ecii.org!news3.near.net!news.ner.bbnplanet.net!news.mathworks.com!newsfeed.internetmci.com!howland.reston.ans.net!usc!newshub.csu.net!newshub.sdsu.edu!dickory!papowell
From: papo...@dickory.sdsu.edu (Patrick Powell)
Newsgroups: comp.os.os9,comp.sys.m68k
Followup-To: comp.os.os9,comp.sys.m68k
Date: 22 Jan 1996 15:12:44 GMT
Organization: San Diego State University
Lines: 74
References: <4dkvv8$v...@linux.cpsc.ucalgary.ca>
NNTP-Posting-Host: dickory.sdsu.edu
Xref: bose comp.os.os9:2845 comp.sys.m68k:6699
: -Russ Magee
: ma...@cpsc.ucalgary.ca
Prof Powell:
I do not know where you are getting this information from, but its all hogwash.
The essense of M6833x family Chip Select module is that it makes interfacing
to *many* types of memory devices and organization *totally* glueless. Yes,
there is extensive decoding logic inside the 68332 SIM, and I doubt if any
one needs to know about it since most of us can write decoding equations for
PALs.
You do not need a PAL or any such device.
For your benefit, the following is a correct explanation:
When a 68332 comes out of reset, the only Chip Select (CS) that has
usable values is the CSBOOT. It defaults to 8-bit, read only with
max wait states (13). The start of memory is set at 0x000000 and the
size of memory is 0x080000 (1 MB).
As in Russ's case, the ROM is 128 KB or 0x010000. This implies that
the ROM appears to CSBOOT at all multiples of 128K starting from
0x000000 and ending before 0x80000. Actually, the ROM appears
MAX_ADDR_SPACE modulo ROM_SIZE number of times. In Russ's case these
are 1MB, 128 KB, implying that the ROM will appear 8 times in the
CSBOOT default address space. This is why, even though his program
is compiled at 0x060000, it gets executed.
As far as his problem is concerned, when he wants to relocate the code at
0x000000, apart from setting the ORG directive or LINK directive to start
program space at 0x000000, he needs to set up the CSBOOT Start Address register
to 0x000000. Note that the Motorola DBUG program sets this to 0x60000.
The moral of the story is: Little knowledge can be dangerous - to oneself.
Happy learning!
Ajay
Thomas Doerfler
>Russ, the 68332 has a special signal sequence that is sent out during
>the first couple of memory accesses after reset. This signal sequence
>is usually decoded by a PAL to produce a BOOT ROM Chip Select signal.
Well, I built a lot of 68332 systems up to now, and I never used any
external address decoders like PALs etc. All address decoding and
memory interfacing can be done internally, and even better than
external, so why built extra stuff around this chip?
Note, that normally not all address lines are available on the
external bus!
>In addition, usually the address signals are decoded as well, allowing the
>Boot Rom to be accesss. Now the 68332 also has on-chip memory decoding,
>which allows some of the output pins to be used as chip selects.
>So you can get some pretty strange effects if you do not know what you
>are doing at the hardware/software level.
>Moral of the story: you need the PAL equations for the support chips,
>a circuit diagram, AND a COMPLETE listing of the startup code.
>Then you start poking around... for weeks sometimes...
Well, with the right hints, this should take hours, not weeks... :-)
>I am curious - who is making the EVS clone? I would be interested in a
>couple of these.
>--
>Prof. Patrick Powell
>Dept. Electrical and Computer Engineering,
>San Diego State University,
>San Diego, CA 92182-1309
>Office (619) 594-7796; Lab (619) 594-7578 FAX (619) 594-7577
>email: papo...@sdsu.edu
--------------------------------------------
Ian Caddy
says...
>
> Hello all,
<snip>
> I can't seem to figure out how CSBOOT* is mapping the EPROM in the
'332's
>address space. The EVS executes Rombug fine at $60000; the start of the
>EPROM is like this:
>
>Offset 00 01 02 03 04 05 06 07 . . .
>------ -- -- -- -- -- -- -- --
>$00000 00 00 49 00 00 06 04 c4 ..
>
>This means the CPU's initial SP will be $4900, PC will be $6004c4, which
>works. But HOW does the EVS find the EPROM at $60000 immediately after
>bootup? My understanding of the 332 is that the EPROM (and all other
>peripherals hooked up to the chip select lines) must be mapped into
>memory by the boot code (via the CSAR/CSORs). If this is so, how does
>the EPROM get up to $60000 at the very start?
>
> A local hardware guru we've talked to says that the '332 must execute
>the EPROM from $0.l after a reset, then the software must remap the
EPROM
>afterward if desired.
The local hardware guru is correct that after reset the 332 will get the
initial stack pointer and program counter address from address 0 to 8.
When the 332 resets only the CSBOOT is valid and it is valid for from 0
to 0x0FFFFF with 13 wait states. Now the boot EPROM is much smaller than
this in your case 1mbit or 128KBytes or from 0 to 0x01FFFF which is a
subset of the chip select. What happens (or should happen) is that the
contents of this EPROM are mirrored on the boundaries of 0x020000 so the
data at address 0 is the same as the data at address 0x020000 and
0x040000 and 0x060000 etc. due to the limited amount of address lines
connected to the EPROM.
So the trick in software is to ORG your code at a high mirrored address
that is valid when the 332 boots and then at a later stage you can set
the chip select for CSBOOT to just point to the chosen address, in this
case 0x060000.
When creating your EPROM files the best thing to do is also ORG your
vectors at 0x060000 and when the compiler creates an S record file,
convert it to binary with a base address of 0x060000 or load into your
EPROM programmer and set the base address to 0x060000.
Hope this resolves your question, if you have any other questions just
drop me some mail.
Ian Caddy
IC Systems Pty Ltd
Perth, West Australia
Ajay Mahagaokar
Path: bose!news.ultranet.com!bigboote.WPI.EDU!transfer.stratus.com!news3.near.net!paperboy.wellfleet.com!news-feed-1.peachnet.edu!gatech!news.mathworks.com!newsxfer.itd.umich.edu!news2.acs.oakland.edu!news1.cris.com!news
From: LVScott <Lvs...@cris.com>
Newsgroups: comp.os.os9,comp.sys.m68k
Date: Thu, 25 Jan 1996 07:53:19 -0500 (EST)
Organization: Concentric Internet Services
Lines: 15
References: <4dkvv8$v...@linux.cpsc.ucalgary.ca> <4e09hc$t...@hole.sdsu.edu> <AJAYM.96J...@bud.bose.com>
NNTP-Posting-Host: viking.cris.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Xref: bose comp.os.os9:2868 comp.sys.m68k:6703
On 23 Jan 1996, Ajay Mahagaokar wrote:
> For your benefit, the following is a correct explanation:
>
> When a 68332 comes out of reset, the only Chip Select (CS) that has
> usable values is the CSBOOT. It defaults to 8-bit, read only with
> max wait states (13). The start of memory is set at 0x000000 and the
> size of memory is 0x080000 (1 MB).
I thought the state of the Data 1 line at reset determines whether
CSBOOT is for an 8 bit device or a 16 bit device. If data 1 is held low
out of reset CSBOOT defaults to 8 bit and if it is Data 1 is held high
CSBOOT defaults to 16 bits.
Hi:
Spitting out the manual on CSBOOT was not my intent. It irks me when
supposedly learned people make an assertive statement on a topic w/o
having *any* idea about what the topic is. Niether was my intent to cover
every possibility in 68332 memory interfacing.
Cheers,
Ajay
LVScott
> For your benefit, the following is a correct explanation:
>
> When a 68332 comes out of reset, the only Chip Select (CS) that has
> usable values is the CSBOOT. It defaults to 8-bit, read only with
> max wait states (13). The start of memory is set at 0x000000 and the
> size of memory is 0x080000 (1 MB).
I thought the state of the Data 1 line at reset determines whether
White Gibson
>
Yo - Ajay
I commend you on solving the "mystery" of how the code works, I have always
wondered about it, but have never taken the time to solve the puzzle.
However, I do find two faults with yor post:
1. At RESET, the parameters of CSBOOT are not exactly as you state. The
Chip Select is BOTH read and write and the default port size is 16-bits
unless two things happen. If D0 is actively pulled low during RESET and the
device does NOT receive a 16-bit data strobe acknowledge (DSACK1-) when
reading the stack pointer and instruction pointer. (I have personal
experience with the second part).
2. If you are going to be snotty about someone else's mistakes, you should
have your facts COMPLETELY in order.
Moral: Nobody likes snotty posts!
White Gibson | The opinions expressed in this article are those of
gibso...@wec.com | the author, for what that's worth.
Yvan Calderon
Hello everybody!
I would lika to ask if somebodycoul help me to understand
somethings.
I have a M68331 based board, very simple (just ram, eeprom and
some ports on). Now I try to make:
. a boot program. What should I include on it?
. configure all interrupts and chip selects. I'm really
confused about it! I don't understand:
how interrupt levels work
how interrupt vectors are implemented (which is the
difference between cpu space and user space, and
wich is the correct adressing modes for them)
how does the IARB (interrupt arbitration b...) work...?
. I suppose I should make it in assembly language. But, can I
make it in C??
From somebody who tries to make a good "debut" in hardware...
Yvan Calderon
ycal...@epfl.ch
ycal...@disun.epfl.ch
PS. I got a 68331 user's manual... but it is really hard to do!
Thanks a lot!
Rob & LeAnne Platt
Actually it's quite simple to do following these steps:
You can even do it in C
I will mail you an example that I use in a design
-------------------------------------------------------
Rob & LeAnne Platt 'Better software through Espresso!'
rjp...@gti.net http://www.gti.net/rjplatt
Robert_Platt%SCHI...@notes.worldcom.com