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!

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.

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

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 __________________________________________________

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 __________________________________________________

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

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!

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!