Brian Traffis wrote:
>>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?
I don't know. I'm not familiar with your startup code. But my
guess is that memory.x is not the place.
>
> 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?
That's the idea. If you prefer, you could set bits on an output port.
Before setting the handlers, clear the output port. Each ISR could
then just put its number on the port, and jump to $E0000.
BTW, you still need to move the stack. That is a problem of its own.
Well, not a problem per se. But a problem when running with BUFFALO.
It's fine in and of itself.
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!
buffalo isr problem
Started by ●August 8, 2005
Reply by ●August 10, 20052005-08-10
Reply by ●August 10, 20052005-08-10
Brian Traffis wrote:
> 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! :)
If you look at my reply, you'll see that I mentioned the former,
but simply rewrapped your long lines w/o comment.
>
> 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);
No, this is not the startup code. This is some sort of configuration
file which tells the linker where to put stuff. Let's guess:
ioports where you have your registers is $1000, length $400
eeprom on-chip EEPROM is at $B600, length $200
data places statically allocated variables at $8800 len $800
text places code at $9000 len $600
Anyway, I wouldn't worry about returning to BUFFALO until after
you either need to do that in order to continue debugging, or
until this little problem is completely solved.
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 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! :)
If you look at my reply, you'll see that I mentioned the former,
but simply rewrapped your long lines w/o comment.
>
> 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);
No, this is not the startup code. This is some sort of configuration
file which tells the linker where to put stuff. Let's guess:
ioports where you have your registers is $1000, length $400
eeprom on-chip EEPROM is at $B600, length $200
data places statically allocated variables at $8800 len $800
text places code at $9000 len $600
Anyway, I wouldn't worry about returning to BUFFALO until after
you either need to do that in order to continue debugging, or
until this little problem is completely solved.
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!
Reply by ●August 10, 20052005-08-10
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?
>
> Brian
Try this:
http://www.freescale.com/files/microcontrollers/doc/data_sheet/M68HC11E.pdf
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
Try this:
http://www.freescale.com/files/microcontrollers/doc/data_sheet/M68HC11E.pdf
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!
Reply by ●August 10, 20052005-08-10
>BTW, you still need to move the stack. That is a problem of its own.
This I did, to location $8FFF and I didn't see any differing results.
I just realized two things though. First off $8FFF would be possibly
where the statically allocated variables would be held, assuming the
memory.x file starts data at $8800 and is $800 in length. Is this a problem?
I can, again, move the stack, but nonetheless the second thing I realized is
the start of the data section being at $8800 and is $800 in length. If
the start of my program is at $9000, is there going to be any clobbering here?
Brian
__________________________________________________
Reply by ●August 10, 20052005-08-10
Mark
>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
I am curious to think, would I be better off using another C compiler for this project? Although I am using EmbeddedGNU which supports the GNU embedded library, I am obviously not using it. Would you, or anyone else have any recommendations on C compilers that I could obtain and maybe, so I can be a bit lazy, tell me where to find it?
The reason for me using this C compiler was that it was easy to find and it had a hardware profile that supported the EVBplus2 board I have.
Also, I tried the use of the "&" prior to the ISR. This didnt change anything, but thanks alot for your input on the matter.
Brian
__________________________________________________
Reply by ●August 10, 20052005-08-10
>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.)?
I must take back what I said about the reset considering I just watched the scope when running the program and it never goes low/true(being active low). Only when I press the reset do I see a low signal. Thanks for your input though and sorry I thought it went low. Does this change anything on my issue?
Brian
__________________________________________________
>indicate a hardware problem. Is there anything besides a pull-up
>resistor or reset generating chip connected to RESET* (even solder
>bridges etc.)?
I must take back what I said about the reset considering I just watched the scope when running the program and it never goes low/true(being active low). Only when I press the reset do I see a low signal. Thanks for your input though and sorry I thought it went low. Does this change anything on my issue?
Brian
__________________________________________________
Reply by ●August 11, 20052005-08-11
Brian Traffis wrote:
>>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.)? > I must take back what I said about the reset considering I just
watched the scope when running the program and it never goes
low/true(being active low). Only when I press the reset do I see a low
signal. Thanks for your input though and sorry I thought it went low.
Does this change anything on my issue?
>
> Brian
Yes, it does. Because it means that BUFFALO is not fielding
an unhandled interrupt. So we're back to square one on that.
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!
>>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.)? > I must take back what I said about the reset considering I just
watched the scope when running the program and it never goes
low/true(being active low). Only when I press the reset do I see a low
signal. Thanks for your input though and sorry I thought it went low.
Does this change anything on my issue?
>
> Brian
Yes, it does. Because it means that BUFFALO is not fielding
an unhandled interrupt. So we're back to square one on that.
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!
Reply by ●August 11, 20052005-08-11
Brian Traffis wrote:
>
>>BTW, you still need to move the stack. That is a problem of its own. >
>
> This I did, to location $8FFF and I didn't see any differing results.
> I just realized two things though. First off $8FFF would be possibly
> where the statically allocated variables would be held, assuming the
> memory.x file starts data at $8800 and is $800 in length. Is this a problem?
Possibly, yes. It depends on how much of that area actually has
variables in it, and how much stack you use. So long as they
don't collide, there is no problem. You could put your stack at
$87FF and be sure. If you have RAM there, that is.
> I can, again, move the stack, but nonetheless the second thing I realized is
> the start of the data section being at $8800 and is $800 in length. If
> the start of my program is at $9000, is there going to be any clobbering here?
If the total length is actually $800, then the last byte used is
$8800 + $800 - 1 = $8FFF.
So if the linker isn't lying to you, there is no overlap of code
and data.
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!
>
>>BTW, you still need to move the stack. That is a problem of its own. >
>
> This I did, to location $8FFF and I didn't see any differing results.
> I just realized two things though. First off $8FFF would be possibly
> where the statically allocated variables would be held, assuming the
> memory.x file starts data at $8800 and is $800 in length. Is this a problem?
Possibly, yes. It depends on how much of that area actually has
variables in it, and how much stack you use. So long as they
don't collide, there is no problem. You could put your stack at
$87FF and be sure. If you have RAM there, that is.
> I can, again, move the stack, but nonetheless the second thing I realized is
> the start of the data section being at $8800 and is $800 in length. If
> the start of my program is at $9000, is there going to be any clobbering here?
If the total length is actually $800, then the last byte used is
$8800 + $800 - 1 = $8FFF.
So if the linker isn't lying to you, there is no overlap of code
and data.
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!
Reply by ●August 11, 20052005-08-11
Mike McCarty wrote:
> Brian Traffis wrote:
>
>>>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.)?
>>
>>
>>I must take back what I said about the reset considering I just
>
> watched the scope when running the program and it never goes
> low/true(being active low). Only when I press the reset do I see a low
> signal. Thanks for your input though and sorry I thought it went low.
> Does this change anything on my issue?
>
>>
>>Brian >
> Yes, it does. Because it means that BUFFALO is not fielding
> an unhandled interrupt. So we're back to square one on that.
Oh, no, wait. Somehow I misread that as E was not stopped.
My analysis stands. BUFFALO is catching an unhandled
interrupt and stopping the clock.
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:
>
>>>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.)?
>>
>>
>>I must take back what I said about the reset considering I just
>
> watched the scope when running the program and it never goes
> low/true(being active low). Only when I press the reset do I see a low
> signal. Thanks for your input though and sorry I thought it went low.
> Does this change anything on my issue?
>
>>
>>Brian >
> Yes, it does. Because it means that BUFFALO is not fielding
> an unhandled interrupt. So we're back to square one on that.
Oh, no, wait. Somehow I misread that as E was not stopped.
My analysis stands. BUFFALO is catching an unhandled
interrupt and stopping the clock.
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!
Reply by ●August 11, 20052005-08-11
I have a general suggestion as to how you might go about debugging
your (gnu C) program, but unfortunately I cannot provide specifics,
since I don't have any of my HC11 references handy...
The idea I have in mind would be to (temporarily) add a asm JMP
instruction to the BUFFALO warm-start location just after performing
the assignment to TOC2_VEC. You could then use BUFFALO to examine the
assembly code produced, and check to see if the vector itself is being
set to a "reasonable" value (e.g. within your code space).
Just how you go about doing this is something I cannot answer for
certain. In some embedded-C compilers, it is as simple as stating:
asm("jmp 0x????");
where "????" is the BUFFALO warm-start entry point (which I do not
know, unfortunately). The syntax of the <asm> macro/operation tends
to vary from compiler to compiler; as is the form of the address
specification (C-style 0x-prefixed hex numbers or Mot-style $ prefix).
I do not recall offhand how BUFFALO reacts to the insertion of a
software interrupt (SWI) instruction in the code; it *may* be the case
that such would be interpreted as a breakpoint, forcing entry into
BUFFALO. Placing a SWI instruction at the desired break point in your
code *may* be a superior alternative to performing a <JMP Warmstart>
operation.
Another thing you could try (again, can't give you specifics) is to
figure out what command-line options/makefile changes are needed to
instruct the compiler/linker to generate (or retain) an assembly
source file of the compiled program. You could then inspect this file
to see if the code being generated (esp. for the TOC2_ISR assignment)
is what you expect.
All of my HC11 projects to date have been written in assembly,
although I have used C on other targets. There are one or two
commercial vendors that produce C compilers for the HC11 (Imagecraft,
Metrowerks ?) but they have the drawback of being rather expensive.
The GNU toolchain is more than adequate for most HC11 (and other
supported) targets; the only drawback that comes to mind is the
lamentable lack of human-readable documentation - a shortcoming common
to most open-source projects :(
If you are still having trouble with your app by the time this weekend
rolls around, I might have some time that I can spend doing a little
research on the subject. I have been meaning to take a closer look at
the GNU toolset but have not had sufficient cause to do so recently.
Your problem is as good of an excuse as any...
I would welcome any commentary by those who can answer the questions
regarding specifics that I could not, to the edification of us all.
your (gnu C) program, but unfortunately I cannot provide specifics,
since I don't have any of my HC11 references handy...
The idea I have in mind would be to (temporarily) add a asm JMP
instruction to the BUFFALO warm-start location just after performing
the assignment to TOC2_VEC. You could then use BUFFALO to examine the
assembly code produced, and check to see if the vector itself is being
set to a "reasonable" value (e.g. within your code space).
Just how you go about doing this is something I cannot answer for
certain. In some embedded-C compilers, it is as simple as stating:
asm("jmp 0x????");
where "????" is the BUFFALO warm-start entry point (which I do not
know, unfortunately). The syntax of the <asm> macro/operation tends
to vary from compiler to compiler; as is the form of the address
specification (C-style 0x-prefixed hex numbers or Mot-style $ prefix).
I do not recall offhand how BUFFALO reacts to the insertion of a
software interrupt (SWI) instruction in the code; it *may* be the case
that such would be interpreted as a breakpoint, forcing entry into
BUFFALO. Placing a SWI instruction at the desired break point in your
code *may* be a superior alternative to performing a <JMP Warmstart>
operation.
Another thing you could try (again, can't give you specifics) is to
figure out what command-line options/makefile changes are needed to
instruct the compiler/linker to generate (or retain) an assembly
source file of the compiled program. You could then inspect this file
to see if the code being generated (esp. for the TOC2_ISR assignment)
is what you expect.
All of my HC11 projects to date have been written in assembly,
although I have used C on other targets. There are one or two
commercial vendors that produce C compilers for the HC11 (Imagecraft,
Metrowerks ?) but they have the drawback of being rather expensive.
The GNU toolchain is more than adequate for most HC11 (and other
supported) targets; the only drawback that comes to mind is the
lamentable lack of human-readable documentation - a shortcoming common
to most open-source projects :(
If you are still having trouble with your app by the time this weekend
rolls around, I might have some time that I can spend doing a little
research on the subject. I have been meaning to take a closer look at
the GNU toolset but have not had sufficient cause to do so recently.
Your problem is as good of an excuse as any...
I would welcome any commentary by those who can answer the questions
regarding specifics that I could not, to the edification of us all.
