Forums

buffalo isr problem

Started by btraf311music August 8, 2005
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...

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

In my actual pwm code the initialization function is as follows...

#pragma interrupt_handler oc2_isr

void init_motors(void)
/* Function: This routine initializes the motors
* Inputs: None
* Outputs: None
* Notes: This routine MUST be called to enable motor operation!
*/

{

disable();

/* Set OC2 and OC3 to output low */
CLEAR_BIT(TCTL1,0xFF);

/* Set PWM duty cycle to 0 first */
duty_cycle = 0;

/* Associate interrupt vectors with motor routines */
//*(void(**)())0x00dd = motor0; tried, doesnt work
// *(void(**)())0xffe6 = 0x00dc; tried, doesnt work

TOC2_JMP = 0x7E; // jump
TOC2_VEC = oc2_isr; // pointer to isr /* Enable motor interrupts on OC2 and OC3 */
SET_BIT(TMSK1,0x40); /* Specify PD5 as output pins.
* PD5 the direction of Motor 0.
*/

SET_BIT(DDRD,0x20);

enable();
} The problem occurs at the line when I set the bit on TMSK1 that
corresponds to the interrupts on OC2.

Would anyone have an idea what I am not doing correctly? If more
information is needed please ask. I am new to the 6811 environment.
I have tried to quickly search for previous similar issues, but
haven't found any information. Thanks!

Brian
Miami University


btraf311music 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

It is not clear to me what you mean by "I lose the clock signal".

> 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 guide/pt-install-info.html
> remapping done for buffalo such as these lines...
>
> #define TOC2_JMP (* (unsigned char *) 0x00DC)
> #define TOC2_VEC (* (void (**)()) 0x00DD)


I'll take your word for the address $00DC being correct.

Let's see if we can figure this out. Let's suppose that
your ISR address is $1234.

Here is the situation.

Address Value
------- -----
$00DC $7E
$00DD $12
$00DE $34

I'd spread things out a little bit. I'm not familiar with
GCC and #pragma interrupt, so you may need a little munging
on this to get GCC to like it.

typedef void IsrFunc(void);
typedef IsrFunc *IsrVector;
#define TOC2_VEC (*(IsrVector *)0x00DD)

Anyway, this convolutes my brain just a little bit less.
Maybe it'll confuse the compiler less, too. > In my actual pwm code the initialization function is as follows...
>
> #pragma interrupt_handler oc2_isr

I'll take your word for this.

>
> void init_motors(void)
> /* Function: This routine initializes the motors
> * Inputs: None
> * Outputs: None
> * Notes: This routine MUST be called to enable motor operation!
> */
>
> {
>
> disable();
>
> /* Set OC2 and OC3 to output low */
> CLEAR_BIT(TCTL1,0xFF);

Since you don't provide any code here, I have no idea
what this accomplishes. However, presuming it actually
sets TCTL1 to $00, you are disconnecting the outputs from
the timer. > /* Set PWM duty cycle to 0 first */
> duty_cycle = 0;
>
> /* Associate interrupt vectors with motor routines */
> //*(void(**)())0x00dd = motor0; tried, doesnt work
> // *(void(**)())0xffe6 = 0x00dc; tried, doesnt work
>
> TOC2_JMP = 0x7E; // jump

BUFFALO puts this in there for you, already, but it won't hurt.

> TOC2_VEC = oc2_isr; // pointer to isr

Hmm. Have you tried setting a break here and *looking* at what
the vectors look like?

>
>
> /* Enable motor interrupts on OC2 and OC3 */
> SET_BIT(TMSK1,0x40);

Looks like you maybe enable OC2 interrupts.

>
> /* Specify PD5 as output pins.
> * PD5 the direction of Motor 0.
> */
>
> SET_BIT(DDRD,0x20);

Ok, so you've got a control bit on PORTD. > enable();

Well, I don't see anyplace where OC2 gets connected to
PORTA. Don't you need to set OM2;OL2 to 0;1 or something
like that? I don't see the actual code for the ISR, so
I don't know what mode you need, but without something
other than 0;0 on OM2;OL2 you aren't going to get any
pulses on OC2.

> } > The problem occurs at the line when I set the bit on TMSK1 that
> corresponds to the interrupts on OC2.

Well, you haven't actually described the problem, only classified
it. To put it another way, a description would be

expected behavior is:
(stuff)

observed behavior is:
(different stuff)

By stuff, I mean a description like this:

we booted BUFFALO
we used BUFFALO to load the program into the EEPROM at $B600
we put a 'scope probe on pin x (PORTy.somebit)
we then used BUFFALO to do (something) and we see
pulses of length blah at a rate of more_blah
we used the BUFFALO commmand CALL B600 to start the program
we expected to see ...
what we saw was ...

Do you know whether your ISR is being entered? What is the clock
signal you are talking about? What pin do you have your 'scope
connected to? How do you initialize so that you see a "clock"?

I'd guess that the problem is *not* the vector itself. My guess
is that you've misprogrammed the timer subsystem.

Enquiring minds want to know!

> Would anyone have an idea what I am not doing correctly? If more
> information is needed please ask. I am new to the 6811 environment.
> I have tried to quickly search for previous similar issues, but
> haven't found any information. Thanks!
>
> Brian
> Miami University

This wouldn't be a homework problem, would it?

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!



: ) This is not a homework problem, but it is part of a summer project I am in, in attempt to get some experience with the 6811 world. No grades given, more or less something I decided to take part in this summer free willing.

I do apoligize for everything I left out. I tried to make the previous attempt at explaining my problem as concise as possible, but I guess I did leave alot unclear. I will attempt to explain everything you questioned or commented.
-------------
What I mean by a loss in clock signal is that when resetting the board, and watching the E-clock line with the oscilloscope, I have a nice 2 mhz square wave signal. When I type the go "text-address" command, the square wave is totally lost. This of course only occurs with this program. I have run other programs in c that do not use ISRs, and programs in assembly that uses ISRs without a problem. I just wish I had a .c file to compare what I am doing wrong.
-------------
According to the buffalo monitor manuals, vector jump table:
Timer Output Compare 2 $00DC-$00DE

Also, according the manual, each vector is assigned a three byte field residing in the monitors memory map locations $0000-$0100. This is where the monitor program expects the MCU RAM to reside. Each vector points to a three byte field which is used as a jump table to the vector service routine.
-------------
In terms of the line #pragma interrupt_handler oc2_isr. This is what I took from comments I found in a hc11.h file that was used with buffalo. Too bad I couldnt find the .c file to see what they did to set up the used vectors.
-------------
The function CLEAR_BIT(x,y) simply is x &= ~y; Apoligies for leaving the function purpose out. And yes this works as you assumed. SET_BIT is similar being x |= y; This is used to turn on bits.
-------------
Sorry, I did not set a breakpoint at the "TOC2_VEC = oc2_isr;" line of code. I know how to set a breakpoint in embeddedGNU, but how would I "look" at the vectors? Sorry, being new, I feel this may be a newbie question.
-------------
SET_BIT(DDRD,0x20); is a line of code that will be the direction of the motor, clockwise or counter clockwise determined by a 0 or 1. This really doesn't relate to the issue but is in the initialization.
-------------
In terms of my ISR:
void oc2_isr ()
/* Function: This interrupt routine controls the PWM to motor0 using OC2
* Inputs: duty_cycle (global)
* Outputs: Side effects on TCTL1, TOC2, TFLG1.
* Notes: init_motors() assumed to have executed
*/
{
/* Keep the motor off if no duty cycle specified.*/
if(duty_cycle == 0)
{
CLEAR_BIT(TCTL1, 0x40);
}
else
if(TCTL1 & 0x40)
{
TOC2 += duty_cycle; /* Keep up for width */
CLEAR_BIT(TCTL1,0x40); /* Set to turn off */
}
else
{
TOC2 += (PERIODM - duty_cycle);
SET_BIT(TCTL1,0x40); /* Set to raise signal */
}
CLEAR_FLAG(TFLG1,0x40); /* Clear OC2F interrupt Flag */
}

I am guessing, this is what you were wondering about if I connected OC2 to PORT A via OM2 and Ol2.
------------
Finally, to describe my issue in more detail:

The expected behavior: A steady E-clock along with pwm signals coming from OC2/PA6. This program consists of 4 files. hc11.h for base register and vector table setup. MIL.h, part of a library that includes SET_BIT and CLEAR_BIT. motor_single.c which does all the work to set up the motor and give it pwm and a direction signal. main.c which calls the functions such as init_motor.

The observed behavior: Reset board under buffalo mode (Wytec's EVBplus2), which initializes to obtain a square wave on the E-clock. Do a Make in EmbeddedGNU, which completes successfully. Download which automatically calls LOAD T. After this I hook up a scope to the E-clock and as I type the command go 9000, the e-clock signal is lost. Also, as you may guess, no signal from OC2/PA6. I don't know if I am getting into the ISR-routine but per the following message from Wytec, this is what they think...

"The reset line of the 68HC11 is bi-directional. When you run a bad program some time (not always, it all depends the code) the 68HC11 will shut itself down by changing its reset line as an open collect output and pulling the reset line low. That's why the E clcok stopped. If you have a DMM and you can check the voltage on the reset, it probably becomes 0. I don't know if your two lines of code are correct to poke the jump instruction into RAM."

I checked the reset line and from what I can see it looks to be 0.
--------------
If there is any other needed information or code please let me know. I really do appreciate your time responding to my issue. This is an independent summer program here and my professor is not sure why I am having issues as he looked over everything. I dont think he has worked with Buffalo much before. I am sort of on my own for the time being, on figuring this issue out and I appreciate any and all help/suggestions. I hate being a newb!

Brian

Mike McCarty <Mike.McCarty@Mike...> wrote:
btraf311music 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

It is not clear to me what you mean by "I lose the clock signal".

> 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 guide/pt-install-info.html
> remapping done for buffalo such as these lines...
>
> #define TOC2_JMP (* (unsigned char *) 0x00DC)
> #define TOC2_VEC (* (void (**)()) 0x00DD)


I'll take your word for the address $00DC being correct.

Let's see if we can figure this out. Let's suppose that
your ISR address is $1234.

Here is the situation.

Address Value
------- -----
$00DC $7E
$00DD $12
$00DE $34

I'd spread things out a little bit. I'm not familiar with
GCC and #pragma interrupt, so you may need a little munging
on this to get GCC to like it.

typedef void IsrFunc(void);
typedef IsrFunc *IsrVector;
#define TOC2_VEC (*(IsrVector *)0x00DD)

Anyway, this convolutes my brain just a little bit less.
Maybe it'll confuse the compiler less, too. > In my actual pwm code the initialization function is as follows...
>
> #pragma interrupt_handler oc2_isr

I'll take your word for this.

>
> void init_motors(void)
> /* Function: This routine initializes the motors
> * Inputs: None
> * Outputs: None
> * Notes: This routine MUST be called to enable motor operation!
> */
>
> {
>
> disable();
>
> /* Set OC2 and OC3 to output low */
> CLEAR_BIT(TCTL1,0xFF);

Since you don't provide any code here, I have no idea
what this accomplishes. However, presuming it actually
sets TCTL1 to $00, you are disconnecting the outputs from
the timer. > /* Set PWM duty cycle to 0 first */
> duty_cycle = 0;
>
> /* Associate interrupt vectors with motor routines */
> //*(void(**)())0x00dd = motor0; tried, doesnt work
> // *(void(**)())0xffe6 = 0x00dc; tried, doesnt work
>
> TOC2_JMP = 0x7E; // jump

BUFFALO puts this in there for you, already, but it won't hurt.

> TOC2_VEC = oc2_isr; // pointer to isr

Hmm. Have you tried setting a break here and *looking* at what
the vectors look like?

>
>
> /* Enable motor interrupts on OC2 and OC3 */
> SET_BIT(TMSK1,0x40);

Looks like you maybe enable OC2 interrupts.

>
> /* Specify PD5 as output pins.
> * PD5 the direction of Motor 0.
> */
>
> SET_BIT(DDRD,0x20);

Ok, so you've got a control bit on PORTD. > enable();

Well, I don't see anyplace where OC2 gets connected to
PORTA. Don't you need to set OM2;OL2 to 0;1 or something
like that? I don't see the actual code for the ISR, so
I don't know what mode you need, but without something
other than 0;0 on OM2;OL2 you aren't going to get any
pulses on OC2.

> } > The problem occurs at the line when I set the bit on TMSK1 that
> corresponds to the interrupts on OC2.

Well, you haven't actually described the problem, only classified
it. To put it another way, a description would be

expected behavior is:
(stuff)

observed behavior is:
(different stuff)

By stuff, I mean a description like this:

we booted BUFFALO
we used BUFFALO to load the program into the EEPROM at $B600
we put a 'scope probe on pin x (PORTy.somebit)
we then used BUFFALO to do (something) and we see
pulses of length blah at a rate of more_blah
we used the BUFFALO commmand CALL B600 to start the program
we expected to see ...
what we saw was ...

Do you know whether your ISR is being entered? What is the clock
signal you are talking about? What pin do you have your 'scope
connected to? How do you initialize so that you see a "clock"?

I'd guess that the problem is *not* the vector itself. My guess
is that you've misprogrammed the timer subsystem.

Enquiring minds want to know!

> Would anyone have an idea what I am not doing correctly? If more
> information is needed please ask. I am new to the 6811 environment.
> I have tried to quickly search for previous similar issues, but
> haven't found any information. Thanks!
>
> Brian
> Miami University

This wouldn't be a homework problem, would it?

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 Brian Traffis
> Sent: Monday, August 08, 2005 4:40 PM
> To: m68HC11@m68H...
> Subject: Re: [m68HC11] buffalo isr problem

<snip>

>
> "The reset line of the 68HC11 is bi-directional. When you
> run a bad program some time (not always, it all depends the
> code) the 68HC11 will shut itself down by changing its reset
> line as an open collect output and pulling the reset line
> low. That's why the E clcok stopped. If you have a DMM and
> you can check the voltage on the reset, it probably becomes
> 0. I don't know if your two lines of code are correct to poke
> the jump instruction into RAM."
>
> I checked the reset line and from what I can see it looks to be 0.
> --------------

Here is the problem. A zero reset line is one of the few (the only?)
things that can stop the E clock. Perhaps your software (or the
software you are using) is using the COP Watchdog or Clock Monitor
Reset. Study Section 5 of the HC11 Reference Manual (the "Pink Book").

Are you sure the Stack Pointer is properly initialized? Perhaps the ISR
is running but the return from it goes to a place that issues a STOP
instruction.

HTH

> Brian
<snip>



Brian Traffis wrote:
> : ) This is not a homework problem, but it is part of a summer
> project
I am in, in attempt to get some experience with the 6811 world. No
grades given, more or less something I decided to take part in this
summer free willing.

Hey, hit return once in a while! :-)

>
> I do apoligize for everything I left out. I tried to make the
> previous
attempt at explaining my problem as concise as possible, but I guess I
did leave alot unclear. I will attempt to explain everything you
questioned or commented.
> ------------- What I mean by a loss in clock signal is that when
> resetting the
board, and watching the E-clock line with the oscilloscope, I have a
nice 2 mhz square wave signal. When I type the go "text-address"
command, the square wave is totally lost. This of course only occurs
with this program. I have run other programs in c that do not use ISRs,
and programs in assembly that uses ISRs without a problem. I just wish I
had a .c file to compare what I am doing wrong.

Ok. This is interesting. There are only three (3) ways I know of
(off the top of my head) to kill E clock.

(1) You are using an E-series part in single-chip mode and you
disabled E clock (could also be other series, but not A)

(2) you executed a STOP instruction (could be due to executing
from wierd addresses, i.e. wild code)

(3) umm, I had a third in mind, but while I was composing, I lost it.

Maybe it'll come back to me, or someone else will remember for me. > ------------- According to the buffalo monitor manuals, vector jump
> table: Timer Output Compare 2 $00DC-$00DE
>
> Also, according the manual, each vector is assigned a three byte
> field
residing in the monitors memory map locations $0000-$0100. This is where
the monitor program expects the MCU RAM to reside. Each vector points to
a three byte field which is used as a jump table to the vector service
routine.

What series part? The addresses you list are appropriate for the
A-series part, but the E-series has 512 bytes of RAM, and BUFFALO
places those vectors at a different location. The F-series has
1K of RAM, and puts the vectors at still another location. The top
of internal RAM is always what gets used. Unless you are using
A-series parts (I always do, because I have a bunch of them
lying around) you are using the wrong addresses for you vectors.

I suspect that this is a problem. Sorry to snip all the stuff
I asked you for. I should have been more suspicious of your initial
explanation from the get-go. Try looking at RAM with BUFFALO and
finding where your vectors really are. You can find them easily,
because you'll see a bunch of

JMP SOME_PLACE
JMP SOME_PLACE
JMP SOME_PLACE
...

all in a row, all jumping to the same place.

Check this, and if necessary modify the address you are using
for your vector, and try again. If the symptoms are the same,
then we can go through what you supplied in detail. If the
symptoms change to "E clock still present, but getting wrong
duty cycle on my output pins", then I guess you'll be debugging
your code.

YMMV

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!



Mike McCarty wrote:

[snip]

I know, I know, responding to myself :-)

> Ok. This is interesting. There are only three (3) ways I know of
> (off the top of my head) to kill E clock.
>
> (1) You are using an E-series part in single-chip mode and you
> disabled E clock (could also be other series, but not A)
>
> (2) you executed a STOP instruction (could be due to executing
> from wierd addresses, i.e. wild code)
>
> (3) umm, I had a third in mind, but while I was composing, I lost it.

Oh, I remembered. You accidentally switched to single-chip mode from
expanded-multiplex, and disabled E.

OOPS! Sorry not to have snipped more stuff from that message.

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!



I probably should have stated I have an MC6811HC11E1CFN2. I can't forget all of the flavors! Mike McCarty <Mike.McCarty@Mike...> wrote:
Brian Traffis wrote:
> : ) This is not a homework problem, but it is part of a summer
> project
I am in, in attempt to get some experience with the 6811 world. No
grades given, more or less something I decided to take part in this
summer free willing.

Hey, hit return once in a while! :-)

>
> I do apoligize for everything I left out. I tried to make the
> previous
attempt at explaining my problem as concise as possible, but I guess I
did leave alot unclear. I will attempt to explain everything you
questioned or commented.
> ------------- What I mean by a loss in clock signal is that when
> resetting the
board, and watching the E-clock line with the oscilloscope, I have a
nice 2 mhz square wave signal. When I type the go "text-address"
command, the square wave is totally lost. This of course only occurs
with this program. I have run other programs in c that do not use ISRs,
and programs in assembly that uses ISRs without a problem. I just wish I
had a .c file to compare what I am doing wrong.

Ok. This is interesting. There are only three (3) ways I know of
(off the top of my head) to kill E clock.

(1) You are using an E-series part in single-chip mode and you
disabled E clock (could also be other series, but not A)

(2) you executed a STOP instruction (could be due to executing
from wierd addresses, i.e. wild code)

(3) umm, I had a third in mind, but while I was composing, I lost it.

Maybe it'll come back to me, or someone else will remember for me. > ------------- According to the buffalo monitor manuals, vector jump
> table: Timer Output Compare 2 $00DC-$00DE
>
> Also, according the manual, each vector is assigned a three byte
> field
residing in the monitors memory map locations $0000-$0100. This is where
the monitor program expects the MCU RAM to reside. Each vector points to
a three byte field which is used as a jump table to the vector service
routine.

What series part? The addresses you list are appropriate for the
A-series part, but the E-series has 512 bytes of RAM, and BUFFALO
places those vectors at a different location. The F-series has
1K of RAM, and puts the vectors at still another location. The top
of internal RAM is always what gets used. Unless you are using
A-series parts (I always do, because I have a bunch of them
lying around) you are using the wrong addresses for you vectors.

I suspect that this is a problem. Sorry to snip all the stuff
I asked you for. I should have been more suspicious of your initial
explanation from the get-go. Try looking at RAM with BUFFALO and
finding where your vectors really are. You can find them easily,
because you'll see a bunch of

JMP SOME_PLACE
JMP SOME_PLACE
JMP SOME_PLACE
...

all in a row, all jumping to the same place.

Check this, and if necessary modify the address you are using
for your vector, and try again. If the symptoms are the same,
then we can go through what you supplied in detail. If the
symptoms change to "E clock still present, but getting wrong
duty cycle on my output pins", then I guess you'll be debugging
your code.

YMMV

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! SPONSORED LINKS
Intel microprocessors Pic microcontrollers 8085 microprocessor

---------------------------------
YAHOO! GROUPS LINKS ---------------------------------
__________________________________________________




Brian Traffis wrote:
> I probably should have stated I have an MC6811HC11E1CFN2. I can't
> forget all of the flavors!

Then you have 512 bytes of RAM, and you are using the
wrong location for your vector.

Oh, BTW, someone else mentioned that you are probably
in a RESET state. That'll certainly kill E.

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!



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?

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?

Thanks again!

Brian

Mike McCarty <Mike.McCarty@Mike...> wrote:
Brian Traffis wrote:
> I probably should have stated I have an MC6811HC11E1CFN2. I can't
> forget all of the flavors!

Then you have 512 bytes of RAM, and you are using the
wrong location for your vector.

Oh, BTW, someone else mentioned that you are probably
in a RESET state. That'll certainly kill E.

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! SPONSORED LINKS
Intel microprocessors Pic microcontrollers 8085 microprocessor

---------------------------------
YAHOO! GROUPS LINKS ---------------------------------
__________________________________________________




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.

> 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.

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!