Mark Schultz wrote:
> 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????");
A way which is portable between compilers (presuming that we
don't think the stack is hosed) is
extern void BuffaloWarmStart(void);
and in a separate pure assembly file
<necessary assembler preamble to put us into the code segment>
BuffaloWarmStart::
jmp $FF7C
<necessary assembler postamble>
Fortunately, there is a jump table in BUFFALO, so a fixed address
(supposedly) works for all versions.
>
> 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).
The addresses are (reaches for sneakernet floppy, copies
BUFFALO 3.2 source, runs to DOS machine, does assemble,
carries sneakernet floppy back to Linux machine, mounts):
4824 *** Jump table ***
4825 FF7C ORG ROMBS+$1F7C
4826 FF7C 7E E0 BF [ 3 ] .WARMST JMP MAIN
4827 FF7F 7E E1 A8 [ 3 ] .BPCLR JMP BPCLR
4828 FF82 7E E1 E9 [ 3 ] .RPRINT JMP RPRINT
4829 FF85 7E E1 F7 [ 3 ] .HEXBIN JMP HEXBIN
4830 FF88 7E E2 2A [ 3 ] .BUFFAR JMP BUFFARG
4831 FF8B 7E E2 4D [ 3 ] .TERMAR JMP TERMARG
4832 FF8E 7E E2 75 [ 3 ] .CHGBYT JMP CHGBYT
4833 FF91 7E E2 E5 [ 3 ] .READBU JMP READBUFF
4834 FF94 7E E2 EC [ 3 ] .INCBUF JMP INCBUFF
4835 FF97 7E E2 F2 [ 3 ] .DECBUF JMP DECBUFF
4836 FF9A 7E E2 FA [ 3 ] .WSKIP JMP WSKIP
4837 FF9D 7E E3 1D [ 3 ] .CHKABR JMP CHKABRT
4838
4839 FFA0 ORG ROMBS+$1FA0
4840 FFA0 7E E1 9D [ 3 ] .UPCASE JMP UPCASE
4841 FFA3 7E E3 0A [ 3 ] .WCHEK JMP WCHEK
4842 FFA6 7E E3 15 [ 3 ] .DCHEK JMP DCHEK
4843 FFA9 7E E3 6C [ 3 ] .INIT JMP INIT
4844 FFAC 7E E3 92 [ 3 ] .INPUT JMP INPUT
4845 FFAF 7E E3 BE [ 3 ] .OUTPUT JMP OUTPUT
4846 FFB2 7E E4 D2 [ 3 ] .OUTLHL JMP OUTLHLF
4847 FFB5 7E E4 D6 [ 3 ] .OUTRHL JMP OUTRHLF
4848 FFB8 7E E4 E0 [ 3 ] .OUTA JMP OUTA
4849 FFBB 7E E4 E4 [ 3 ] .OUT1BY JMP OUT1BYT
4850 FFBE 7E E4 F3 [ 3 ] .OUT1BS JMP OUT1BSP
4851 FFC1 7E E4 F0 [ 3 ] .OUT2BS JMP OUT2BSP
4852 FFC4 7E E4 FC [ 3 ] .OUTCRL JMP OUTCRLF
4853 FFC7 7E E5 0C [ 3 ] .OUTSTR JMP OUTSTRG
4854 FFCA 7E E5 0F [ 3 ] .OUTST0 JMP OUTSTRG0
4855 FFCD 7E E5 38 [ 3 ] .INCHAR JMP INCHAR
4856 FFD0 7E E3 4B [ 3 ] .VECINT JMP VECINIT
> 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.
The code in BUFFALO is this:
1780 *****
1781 ** SWIIN - Breakpoints from go or call
commands enter here.
1782 *Remove breakpoints, save user
registers, return
1783 E91F SWIIN EQU * swi entry point
1784 E91F 30 [ 3 ] TSX user sp -> x
1785 E920 9E B2 [ 4 ] LDS PTR2 restore monitor sp
1786 E922 BD EA 4D [ 6 ] JSR SAVSTACK save user regs
1787 E925 BD E9 6C [ 6 ] JSR REMBPS remove
breakpoints from code
1788 E928 DE 66 [ 4 ] LDX REGS
1789 E92A 09 [ 3 ] DEX
1790 E92B DF 66 [ 4 ] STX REGS save user pc value
1791
1792 *if(call command) remove call return
addr from user stack;
1793 E92D 7D 00 C1 [ 6 ] TST TMP2 1=go, 0l
1794 E930 26 06 [ 3 ] BNE GO3 jump if go command
1795 E932 DE 6F [ 4 ] LDX SP remove return address
1796 E934 08 [ 3 ] INX user stack pointer
1797 E935 08 [ 3 ] INX
1798 E936 DF 6F [ 4 ] STX SP
1799 E938 BD E4 FC [ 6 ] GO3 JSR OUTCRLF print register values
1800 E93B BD E1 E9 [ 6 ] JSR RPRINT
1801 E93E 39 [ 5 ] RTS done
So, it removes the SWIs it put in due to breakpoints, and replaces
them with the original code, then looks to see if the code was executed
via CALL or GO. If CALL, it "pops" the return address by modifying
the
saved SP, then displays the registers etc. So it doesn't even check
to see if the SWI was one in the table. It treats them all as
breakpoints.
> 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 :(
Other drawbacks:
often write-only code
obscure and difficult to find defects
bloatware
Unfortunately, some of this also occurs with commercial products.
Double :-( :-(
> 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.
I dunno how edifying, but see above.
As I mentioned before, it looks like BUFFALO is catching a non-handled
interrupt and disabling the clock. The exact code is:
0799 *
0800 **********
0801 *
0802 * VECINIT - This routine checks for
0803 * vectors in the RAM table. All
0804 * uninitialized vectors are
programmed
0805 * to JMP STOPIT
0806 *
0807 **********
0808 *
[snippy snippy]
0821 E365 86 50 [ 2 ] STOPIT LDAA #$50 Stop-enable;
IRQ, XIRQ-Off
0822 E367 06 [ 2 ] TAP
0823 E368 CF [ 2 ] STOP You are lost!
Shut down
0824 E369 7E E3 65 [ 3 ] JMP STOPIT In case continue
by XIRQ
So, either his vector is not getting in there, or some other
unanticipated interrupt is being acknowledged.
My suggestion was to init all vectors to point into his code,
since it should be done anyway, and then see which ISR
gets invoked.
If *none* of the ISRs gets invoked, but the clock stops,
then we know that the vector didn't get inited properly.
OW, we know which ISR got invoked, and was not handled.
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
