27c256 | 4K81H | 68HC11A1 | 68HC11P1 | 68hc24 | 68HC711E9 | 68HC811 | 8255 | A2D | ADC | ADC12138 | Am85C30 | BRCLR | Buffalo | CMOS | EEPROM | EPROM | Ethernet | EVB | EVBU | HC11E1 | HC11E9 | HC711E9 | Horray | ImageCraft | IRQ | Keypad | LCD | MC68HC11D0FN | MC68HC11E1CFU3 | MC68HC11F1 | MC68HC711E9 | MC68HC711E9CFN2 | Microcore11 | Microstamp11 | Minikit | NVRAM | PSD | PSD8xx | PSD9xx | PT1000 | RS232 | RTS | RXD | SPI | SRAM | TXD | Watchdogs | XIRQ

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


______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

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!





(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

: ) 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!

__________________________________________________
">http://mail.yahoo.com

[Non-text portions of this message have been removed]



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

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>





(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

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!



______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

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!



______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

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 ---------------------------------
__________________________________________________
">http://mail.yahoo.com

[Non-text portions of this message have been removed]



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

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!





(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

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 ---------------------------------
__________________________________________________
">http://mail.yahoo.com

[Non-text portions of this message have been removed]



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

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!





(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

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.



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

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!





(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

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!





(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

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 need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

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



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )