Forums

buffalo isr problem

Started by btraf311music August 8, 2005
Brian

Look at the memory from FFFF down a bit and those are the
vectors to the interrupt table in a 3 byte combination of a
JSR(I think) and address in hex. Go back until the 3 byte
combinations quit being a jump table and that the fist address
will be the first interrupt and almost always falls on a even
hex 1000 boundary. The address at FFFE FFFFF is were the program
starts on reset unless you reconfigure the auto start or Buffalo
jumps to EEPROM instead if pin e.0 is held low on some versions.

Gordon Couger
Stillwater, OK
www.couger.com/gcouger > Brian Traffis wrote:
>
>>Where do I find the locations for my vector then? I am guessing a
>
> E-series specific buffalo monitor manual? If I am using the wrong
> locations for my vector, couldn't that be the main problem? I
thought I
> double checked the buffalo manual to make sure its DC, but
now that I
> look there are comments in the file that say that the hc11.h
is from an
> A8. So, again where do I look to get the proper vector locations?
>
> First, have a look at your keyboard, and try to find a key
labeled
> something like "Enter" or "Return", ok?
>
> You can compute the vector locations very easily. Since the A-
> has 256 bytes of memory, and the E-series has 512, or exactly
> $100 bytes more, just add $100 to all the addresses, and that
> should be right.


Brian Traffis wrote:
[directly to me]

I'm trying to keep as much of this as possible on
the echo, so others can either contribute or learn.

> Since I am writing my program in C obviously, are you referring to IF I wrote mine in assembly?

I'm out of context, so I don't know what question you
refer to.

Oh, I see. You top-posted. Please don't do that.

If you really want to, you can modify the startup code
so that you can use exit() and get back to BUFFALO.

IOW, your startup code would be something like this:

org Somewhere
Stack:: fcb 0
ExitCode:: fdb 0
SaveSP: fdb 0
Start:
sts SaveSP
lds #Stack
... rest of code same

_exit::
tsx
ldd 2,x ; get argument
std ExitCode
lds SaveSP
rts This would get you back to BUFFALO, and you could examine
the argument passed to exit(.) and try to figure out
what went wrong.

> Or do you mean to mix the assembly into the C? I was also confused when you mentioned
> that the vectors will get clobbered by BUFFALO upon a reset. Could you please explain a bit more?

Ok, I'll describe the architecture of the chip a little bit.
You really should RTFM.

For each possible reset, trap, etc. there is a fixed address
between $FFC0 and $FFFF assigned to contain the address
of the routine to handle that event.

When an event, like reset, or an interrupt, occurs, the processor pushes

all its registers on the stack, sets the interrupt inhibit bit in the
CCW, and loads the vector from the appropriate address into the PC.

The copy of BUFFALO you have occupies those addresses, and it has
pointers to routines. Some of those routines are inside BUFFALO, and it
uses them. The SWI instruction, for example, is used for breakpoints.

But BUFFALO attempts to let your program capture everything it doesn't
use itself. For this, it has vectors in its table which do not point
into BUFFALO, but rather to some RAM in low memory. During its
initialization, BUFFALO puts JMP STOPIT code into all those locations
associated with interrupts or traps which it doesn't use itself.

If you pull the source for BUFFALO from the location I gave you,
you can see that code. Just search for JMPSCI in the source,
and you'll see where those jumps get initialized.

If you put something into one of those revectoring routines,
and then reset, BUFFALO will happily overwrite what you put
there.

>
> Brian
>
> Mike McCarty <mike.mccarty@mike...> wrote:
>
> BTW, if you use CALL instead of GO, it is possible to write
> an exit() which will get you back into BUFFALO (has to be
> assembly) and then you can inspect your vectors, etc.
> Reset the board, and they'll all be clobbered by BUFFALO.
>
> Mike


--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!



See below.

Emmett Redd Ph.D. mailto:EmmettRedd@Emme...
Associate Professor (417)836-5221
Department of Physics, Astronomy, and Materials Science
Southwest Missouri State University Fax (417)836-6226
901 SOUTH NATIONAL Dept (417)836-5131
SPRINGFIELD, MO 65804 USA

> -----Original Message-----
> From: m68HC11@m68H...
> [mailto:m68HC11@m68H...] On Behalf Of Mike McCarty
> Sent: Monday, August 08, 2005 9:23 PM
> To: m68HC11@m68H...
> Subject: Re: [m68HC11] buffalo isr problem
>
> Brian Traffis wrote:
> > Where do I find the locations for my vector then? I am guessing a
> E-series specific buffalo monitor manual? If I am using the wrong
> locations for my vector, couldn't that be the main problem? I
> thought I
> double checked the buffalo manual to make sure its DC, but now that I
> look there are comments in the file that say that the hc11.h
> is from an
> A8. So, again where do I look to get the proper vector locations?
>
> First, have a look at your keyboard, and try to find a key labeled
> something like "Enter" or "Return", ok?
>
> You can compute the vector locations very easily. Since the A-
> has 256 bytes of memory, and the E-series has 512, or exactly
> $100 bytes more, just add $100 to all the addresses, and that
> should be right.

All my experience with a 711E9 which also has 512 bytes is that the jump
vector addresses remain in page zero, that is, the addresses Brian is
using.

>
> > What would you say would be the first step in determining the cause
> > of
> the reset state? Just for a start, how would you recommend I
> go about this?
>
> That may be difficult. Do you want to understand symptoms, or
> fix root causes? I suggest fix the address problem first, then
> if the symptoms persist, look for other avenues.

Reset being continuously low (after hitting the problem) may indicate a
hardware problem. Is there anything besides a pull-up resistor or reset
generating chip connected to RESET* (even solder bridges etc.)?

Emmett

>
> Mike
> --
> p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
> This message made from 100% recycled bits.
> You have found the bank of Larn.
> I can explain it for you, but I can't understand it for you.
> I speak only for myself, and I am unanimous in that!



Brian Traffis wrote:
> Mike,
>
> First off, should I be responding to the yahoo group for the benefit of all on this subject? As
> you know I am new here so I am not sure if this should be an off-list topic.

It seems to be straight on-topic to me. Others may disagree.

>
> BUFFALO was installed prior to purchasing the board so where the BUFFALO source came
> from, I am unaware.

It's probably from the location I gave you, modified.

> In terms of the code, you are right, I didn't write it. My professor gave me this code to use as a
> sample and we both thought it would be best to see if I could get it to run prior to using it in my
> project. He actually had the code from his colleagues in the past.

The code I was referring to was the startup code, not the C source.
The startup code is what is incompatible.

> In terms of the stack overwriting some of the revectoring, I understand what is happening. The
> thing I am confused over is regarding when you say the startup code I have is incompatible
> with the environment, I presume BUFFALO. What are you refering to as the startup code?

You wrote a program in C. The code generated by the compiler
presumes a certain setup. For example, the compiler does
not generate code to set up the stack pointer. It presumes
that *something else* has done that.

The *something else* that gets linked into your program
and which sets the machine into a state that C presumes
already exists is called "the startup code". In a hosted
environment, it finds stdin, stdout, and stderr and gets
them ready to go, and creates argc and argv, and passes
them to main, etc.

>
> In terms of not setting up every trap/interrupt, I am unaware this is the thing to do. Being new
> to the 6811 world, if I didn't set up every one of these, its unintentional as every mistake I am
> making is due to just a lack of knowledge in the matter. I am trying to not be lazy if I know what I am doing :) I just dont!

You have been lazy in not RTFMing!

Look at it this way. Every possible event is going to cause
your program to do *something*. If the processor fetches
what is presumably an op-code, and it turns out not to be
a valid instruction, then the processor IS GOING TO USE
THE VECTOR FOR ILLEGAL OPCODE. You have no choice in this
matter. So, are you going to let the processor fetch
some random value and stuff it into the PC, or are you going
to have it jump to a routine which displays "ILLEGAL OPCODE
AT LOCATION $1234" and then go into an infinite loop
waiting for you to notice and give it a reset?

HMMMM?

Now, under BUFFALO, BUFFALO has already inited that
vector to point to STOPIT, but all you'll get is a
jump to this code:

STOPIT LDAA #$50 Stop-enable; IRQ, XIRQ-Off
TAP
STOP You are lost! Shut down
JMP STOPIT In case continue by XIRQ

HEY! WAIT! THAT'S IT!

LOOK EVERYBODY! IT GOES INTO STOP MODE!

Can you say, SHUT OFF THE CLOCK?

Ok, what's happening almost surely is: you are getting an
interrupt you haven't planned for, and BUFFALO is capturing
it and SHUTTING DOWN THE CLOCK. >
> Let me try to run BUFFALO after dinner to overwrite the startup and I will let you know what
> happens.

My recommendation: write routines for each of the possible
vectors, and install them. Have each one place a known
value into, say location 0, which value indicates which
one you took, then jumps to $E000 (entry point for BUFFALO).

Build and load your program.

Modify the startup code put the stack somewhere safe.

Run the program. Immediately, BUFFALO will restart.

Dump location 0, and you'll see which trap/interrupt you took.

>
> Honestly, I can't say how much I appreciate your help in this matter. I feel like I am wandering
> around in the dark due to the lack of knowledge and experience in this subject. Thanks again
> for taking the time to help me out.

We all started out fumbling in the dark.
I didn't have help with the '11 when I was there, but many of us
owe a debt to someone else who helped.
You can't pay back, but you can pay forward. In 10
years when you are an old fart^H^H^H^H^H expert
like me, you'll give someone else a lot of help and tell
him the same thing I'm telling you. And that's
pay forward.

It's like your parents. You'll never be able to
repay them, except by rearing your own kids. It's
a debt passed down from one generation to the next,
all the way back to Adam.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!



You are right, I have read parts of the manual, but I think its time to go over the whole thing
again and not be lazy. I can't deny this. I wanted to ask you, as well as anyone else, do you
have any suggestions on important links, sources, books, etc that I should read, being a noob
to this stuff?

Brian

Mike McCarty <Mike.McCarty@Mike...> wrote:

You have been lazy in not RTFMing! __________________________________________________




Brian Traffis wrote:
> You are right, I have read parts of the manual, but I think its time to go over the whole thing
> again and not be lazy. I can't deny this. I wanted to ask you, as well as anyone else, do you
> have any suggestions on important links, sources, books, etc that I should read, being a noob
> to this stuff?
>

The best I can suggest is the Pink Book. My copy is MC68HC11A8/D,
but I'm sure you can't get that anymore. Use the one for the E
series. Most of the series are the same with regards to
everything but amount of RAM/ROM/EEPROM. Some of them have PWM
generators and that sort of thing. And the F series is not
mutliplexed and has some nice chip select pins. But
what you need is just to dig in to any of the pink books and
read it cover to cover. Freescale has downloadable versions
of those manuals in PDF.

> Mike McCarty <Mike.McCarty@Mike...> wrote:
>
> You have been lazy in not RTFMing!

Still top-posting, I see :-)

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!



Sorry for top-posting... I am working on my netiquette! I hope this is better....

>My recommendation: write routines for each of the possible
>vectors, and install them. Have each one place a known
>value into, say location 0, which value indicates which
>one you took, then jumps to $E000 (entry point for BUFFALO).

Since I tried to relocate the stack to 8fff, and still had the same issues, I think I will follow this recommendation. I'll keep you updated.

Brian

__________________________________________________





>The code I was referring to was the startup code, not the C source.
>The startup code is what is incompatible.

In my environment I am working in, I have a file called memory.x, I see that it sets the location of the stack. The following is the contents of the file. I have played around with setting the stack location and it works. Would this be were I would want to throw in the code for exit() so I could return to BUFFALO?

Also, I have one more question regarding installing routines to determine what is going and sending an output with a specific indicator to determine which routine is called. This would be simply setting up ISR's and using the code within to set a value to a certain location, right?

Brian

__________________________________________________




I forgot to include the memory.x files contents so you could tell me if this is the startup code
that you were talking about. Also, I may not have hit "enter" on everyline of the last message,
this I just remembered. So please forgive me! :)

OUTPUT_FORMAT("elf32-m68hc11", "elf32-m68hc11",
"elf32-m68hc11")
OUTPUT_ARCH(m68hc11)
ENTRY(_start)
SEARCH_DIR(C:\usr\lib\gcc-lib\m6811-elf\3.3.5-m68hc1x-20050515\mshort)

MEMORY
{
ioports (!x) : org = 0x1000, l = 0x400
eeprom (!i) : org = 0xB600, l = 0x200
data (rwx) : org = 0x8800, l = 0x800
text (rx) : org = 0x9000, l = 0x6000
}

PROVIDE (_stack = 0x8ffe);

Brian

__________________________________________________




--- In m68HC11@m68H..., "btraf311music" <btraf311music@y...>
wrote:
> I am trying to produce some pulse width modulation code in C using
> the EmbeddedGNU IDE, and the board running under the Buffalo
> monitor, but I lose the clock signal right after running the
> program. To be specific I am using an EVBplus2 6811 board. We have
> determined that the interrupt vectors most likely have not been
> initialized properly since when an interrupt occurs, the clock
> signal is lost. We are measuring the clock with an oscilliscope, so
> we can clearly see it. I have a hc11.h file that lists all of the
> remapping done for buffalo such as these lines...

<snip>

A few comments regarding some of the observations made by various
participants here on this problem:

1. If you are using BUFFALO (or even Bootstrap mode), the interrupt
pseudo-vectors are always mapped to the same place, REGARDLESS of the
device in question. This is contrary to an observation made by
someone here (don't recall who posted it) that the pseudo-vector
locations are different depending on which series device (A, E, F,
etc.) you are using. While it is true that the A, E and F devices
have differing amounts of internal RAM, the pseudo-vector locations
are always in the same place - RAM locations $00Cx-$00FF (I don't
recall the exact location of the first vector, but it's somewhere in
this region).

Thus, regardless of which HC11 variant you are using, the TOC2
pseudo-vector should be located as you presently have it:

> #define TOC2_JMP (* (unsigned char *) 0x00DC)
> #define TOC2_VEC (* (void (**)()) 0x00DD)

2. I have yet to (successfully) utilize the GNU HC11 C compiler in a
project (something I'd like to do, bu have not had time to experiment
with as of yet), but it is possible that the solution to your problem
could be as simple as this:

TOC2_JMP = 0x7E; // Unchanged
TOC2_VEC = &oc2_isr; // Note use of "&" address-of op

3. I don't have any experience using gdb, so I cannot offer any
specific step-by-step instructions on how to do what I am about to
propose, but... If you can somehow set a breakpoint on the line just
following the TOC_VEC assignment, try using whatever directive you
would use to examine a arbitrary range of memory to look at locations
$00DC-$00DE. You should see the value $7E at $00DC, and locations
$00DD-DE should contain a word value that points somewhere within your
code space.

4. I don't have my HC11 reference handy, so what I am about to say may
be wrong... but I think that the STOP instruction, if enabled, is
capable of shutting down the E-clock. If your pseudo-interrupt vector
is pointing to the wrong place, it is quite possible that a STOP
instruction is being inadvertently executed as part of the 'random
garbage' that is being executed when the CPU jumps to the (wrong)
location pointed to by the (incorrectly-set) TOC2 vector.

I'll have to take a closer look at the "EmbeddedGNU" tools you
mentioned - they might be helpful in getting me started with the GNU
HC11/HC12 toolchain.