Thanks John for guidance on where to find the info I need on Jbug and it's interrupts. I am relying on downloaded manuals, etc and with hundreds of pages of the stuff to wade through and get some understanding of. It is tedious on a PC and takes a while, but I'm getting there - Thanks for pointing me in the right direction. Mark, I am still absorbing the info/advice you sent me. Meantime, I am making some progress on my engine control project. To answer your question about use of the pulse accumulator. I am not using it. I only mentioned it because I found out (by trial and error) that it was one of the interupts which upset JBug comms. With John's leads (above) I can get a bit more scientific about understanding Jbug's capabilities and limitations. Re RPM in my application: I need a 1mA FSD meter reading (0-3000RPM) and 100RPM precision is sufficient. In fact, only about 600-3000RPM is of interest ie. only about 24 discrete values are sufficient. I looked at a PWM/PFM analog-type output approach, but have instead, chosen the following:- I plan to use TICI and TOI to measure the period between the rising edge of successive tacho pulses (~20mS to >100mS), average a few to reduce jitter, then use a lookup table to give me an appropriate output voltage for the meter via latched port outputs and an D/A chip. This avoids a lot of messy uP arithmetic with reciprocals and scaling constants. The same D/A and meter also displays engine temp, oil pressure, hydraulic oil temp, and battery volage. Many thanks and Regards to all contributors, jem

Hi John <> wrote on Wed 12/05 and Thur 13/05, and Mark Schultz <> wrote on Thur 13/05 concerning JBug11 and interrupts. The JBug11 manual explains interrupts on page 1, with further information on page 39 (second paragraph from the bottom), at the top of page 77 where the terminal program interaction with JBug11's monitor is discussed, under 'Hardware' in Appendix B, page 83. Tracing through illegal opcodes is discussed on page 20, and additional information is available in the file: ISR_Demo.asm which you can find in the 'Files' area of the Jbug11 group on Yahoo: http://groups.yahoo.com/group/Jbug11/ John Beatty ____________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html

--- In , "John" <jmacey_au@y...> wrote: > I have however found a (serious for me) problem with writing to > TMSK2. Setting PAOVI, PAII, PRI, & PR0/1 HI is no problem, but > JBug monitoring doesn't work if I set TOI or RTI to Hi (enabled) - > I need TOI in my applications! Bear in mind that I have just started to experiment with JBug myself, and have had my share of difficulties making it work as a true debugger (and not just a loader), so while my comments below might not fix your problem, they might go a ways towards solving it. It is important to remember that when the JBug talker gains control, it will ENABLE interrupts - even if they are disabled in your application. At least I'm pretty sure this is the case. Thus, it is very important that you follow a few do's and dont's: 1. DO NOT attempt to single-step the code that initializes the RAM- based vectors. Actually, you can probably do this safely if you... 2. DO make sure that your RAM vectors are initialized, along with any variables your ISR needs, BEFORE you set the interrupt-enable bit (s) for the interrupt source(s) you will be using. Normally you could do this at any point in your init routine before doing a CLI, but JBug enables interrupts whenever it gets control - so if you set the interrupt-enable bits for the subsystems you are using (e.g. RTII, PAII, PAOVI) before you init the psuedo-vectors or your ISR variables, and attempt to single-step using JBug, it is quite possible that one or more of your interrupt sources could 'fire' before you have the rest of your init done, which will cause JBug to hang or your program to malfunction. 3. DO make sure that you follow whatever procedure is necessary (during init) to clear any pending interrupt flag(s) for source(s) you will be using BEFORE you turn on the corresponding interrupt- enable bit. This step may not be absolutely necessary, and may not even do much good in a debug environment (e.g. clearing RTIF when debugging in single-step mode won't do much good since it is going to get set before you step to the next instruction anyway). 4. Make sure your ISRs are written in a robust-enough manner so they can 'deal with' the unexpected - such as a jittery signal on a input capture (check and reject any out-of-band measurements), or the initial non-event you might get right after initialization. This suggestion is just an extension of the general rule that suggests writing ALL of your code in such a way that it will react gracefully as possible when it receives bad input - bounds-checking values, detecting, correcting or rejecting errors, etc. One final application-specific note: What were you planning on using the pulse accumulator for? Engine RPM measurement? If this is the case, you may find that you will get better resolution (and faster updates) if you use a timer input capture to measure the single- rotation PERIOD of the engine, rather than measuring how many rotations it makes over a fixed period of time using the PA. Even at an engine speed of, say, 5000 RPM, a timer input capture measurement (assuming EClk = 2 MHz and timer configured to use the E/1 prescaler setting) will give you 400 counts, with updates every engine revolution. You could average (or sum) several period measurements to get a more stable and/or higher-resolution measurement.

--- In , "Mark Schultz" <n9xmj@y...> wrote: >...I have summarized some of the key points below, to confirm > and extend the information you have: > 1.... [thanks for confirming my experience] > 2.... [ditto] > 3.... [ditto re SCI,SWI & ILLOP interrupt unavailability - no problem for my apps] >Also, your interrupt routines will continue to run at full speed, >even when your (main-level) program appears to be stopped in JBug. [I hadn't realised that yet. Thanks for the head-up] > > Finally, keep in mind that when > using JBug your stack space *may* be a bit restricted - check the > JBug configuration dialog (after you configure it to use the > appropriate 'talker') to see what memory region(s) JBug uses for > code and stack, and what regions in RAM it leaves free. This is > particularily critical if you are using JBug with an E2 device, as > this part only has 256 bytes of internal RAM. [I'll have to give this some more thought. Haven't yet figured out the problem and it's implications] > > 4...68HC811E2...[A nice lead- thanks for that.] > [However, I now think that lack of writable memory at the top end (including the interrupt vector space) is not my real problem, so E2s or E9s won't solve it. I think the real problem is the restriction to de-bugging in BS-mode. see comments below] Thank you Mark, for all the above good stuff. I have written and trialed a few more test programs to probe the limitations of applications using E1s in BS-mode (and access to JBug de-bugging). I find no problems using my user code to write JMPs to the available RAM-located bootstrap vectors. I have however found a (serious for me) problem with writing to TMSK2. Setting PAOVI, PAII, PRI, & PR0/1 HI is no problem, but JBug monitoring doesn't work if I set TOI or RTI to Hi (enabled) - I need TOI in my applications! I don't yet know if JBug actualy loads my TMSK2 instruction (with TOI bit set)to EEPROM. I think it does, because it doesn't immediately crash JBug and G $B600 appears to run the program. However, JBug fails with a comms error as soon as I try to trace or read any memory contents - so presumably JBug needs to have timer overflow (TOI) dissabled for successful communication. I am suspicious that either a) programs using timer overflow interrupts will not run in BS-mode? or b) they run OK, but JBug de-bugging is not available? I think that b) is most probably the correct situation. I'll write some more test code to check this (provided that my wife doesn't divorce me for desertion - citing Motorola). If you know the answers/solution you could save me some time - and maybe a marriage! If I cannot use TOIs im my applications, I'll rewrite them to run without interrupt - messy and inelligent to write 4sec and 20sec delays with a 2MHz clock (without using TOI) but it will get the job done . I would really like to get an engine-control circuit functional by this weekend (elegant/agricultural, just as long as it works). Thamks for your help and encouragement to date - much appreciated. Regards, jem

Jon, it appears as if you have managed to figure out almost everything you need to know to use the E1 that you have to create simple (<= 512-byte) standalone applications using the internal EEPROM. I have summarized some of the key points below, to confirm and extend the information you have: 1. It is possible to auto-start a program in internal EEPROM on a E- series device (including the E1) by placing the device in BS mode, and connecting PD0 (RXD) and PD1 (TXD) together. The BS ROM (at $BF40-$BFFF) will detect this condition at reset and execute a JMP to $B600 where the internal EEPROM resides. 2. When the HC11 is in one of the 'special' modes (Bootstrap or Special Test), it expects to fetch interrupt vectors in the block from $BFC0-$BFFF. In BS mode, the bootstrap ROM resides in these locations. However, the BS ROM conveniently places JMPs for all the vectors (except RESET) to RAM locations varying from $00C4..$00FD. The specific location in RAM that is JMP'd to for each interrupt source is listed in the HC11 Reference Manual (the "White Book"). If you need to use a given interrupt source, your program (in EEPROM) needs to write JMP $xxyy instruction(s) in the appropriate RAM location(s) to point to your ISR(s). 3. As you noted earlier, the JBug RAM talker makes use of the SCI, SWI and ILLOP interrupts, so you should avoid overwriting these vectors in your own application. Also, your interrupt routines will continue to run at full speed, even when your (main-level) program appears to be stopped in JBug. Finally, keep in mind that when using JBug your stack space *may* be a bit restricted - check the JBug configuration dialog (after you configure it to use the appropriate 'talker') to see what memory region(s) JBug uses for code and stack, and what regions in RAM it leaves free. This is particularily critical if you are using JBug with an E2 device, as this part only has 256 bytes of internal RAM. 4. FWIW, you can often find HC11-series parts - even the E2 - for sale on eBay. I just did a quick check and found this listing for 12 E2 devices for $30 USD: http://cgi.ebay.com/ws/eBayISAPI.dll? ViewItem&categoryP915&item%93622760&rd=1&ssPageName=WD1V Or, do a search on eBay for "68HC811E2FN" The seller indicates that they will ship internationally - probably pretty expensive but even if the shipping cost is the same as the parts cost, you'd still get the parts for $5 USD/ea, not a bad deal. 5. For more complex designs, your best bet (as others here have indicated) would be to use the HC11 in normal expanded mode with external ROM/Flash and (optionally) RAM. You will, of course, loose ports B and C, but you can make up for this lack by using serial shift registers, memory-mapped latches/buffers, or use another E1 or similar device as a 'Slave IO controller' - see my next message for more details on this approach. If there is anything else that you are uncertain of with regards to using the HC11 bootstrap mode or related issues, feel free to ask for clarification - as you can see, the people on this list are more than willing to help, esp. when the person being helped takes the initiative to find some of their own answers, as you have obviously done!

WOW! - I'm impressed! - 6 replies with good advice in less than 24hrs! Thanks to all for your interest and quick responses. It seems that the easy solution to running SC-mode on a BOT1 board is to buy some E9s. The disadvantage is the time/cost/difficuly of buying E9s from Australia. Nevertheless, it may be the right "final solution". Working my way up a steep learning curve and information overload - I now know that an E1 in BS-mode (with Tx-Rx looped) will boot-up and re-boot from reset or power-up, jump to $b600 user programe (which doesn't use interrupts)and work OK in a working environment (ie. when not connected to JBug). The bootloader doesn't use RAM or interrupts - so I don't need RAM battery back-up. If I can get all/most of the interrupt facilities to work (primarily timer related ones) with E1s in BS-mode, then that would suit my purposes at zero cost. I don't need SWI, SCI or SPI facilities in my simpler applications. I would appreciate advice on the following asessments of operating E1s in BS-mode with programs that use timer interrupts:- a)It appears to me that the bootloader re-locates interrupt vectors to RAM at $00C4..$0040. So, I could include setup instructions in my user programs to write JMP instructions to these RAM vector locations (the inaccessable BS-mode $BF40 RESET vector is no problem because it results in a JMP to $B600, as required). If this is correct, then the only remaining problem is de-bugging. b) It also appears that JBug uses only the SCI interrupt. The ILLEGAL OPCODE INT jumps to $0000 and all other interupts jump to $0058 which contains an RTI. Since my user interrupt routines will also end in an RTI, I think (not sure?) that JBug will still work OK with my interrupt intensive user programmes running, provided that I don't use RAM below $0100 and don't change the SCI or ILLOPCODE vectors. c)If JBug works OK under these circumstances, I realise that it's processing overhead will affect precise timing - I can live with that. d) Are there any "Gotchas" that I haven't yet identified? Regards, jem

That is correct, the windowless E9's cannot have the EPROM erased which is why they are known as OTP devices. The EEPROM (512 bytes) still works normally. Windowed E9 (CFSn suffix) which can be erased are still available, but are quite expensive (about $30.00) although you only need 1-2 of them to test your code with. Oh, btw, the OTP E9s are known as 68HC711E9s, not 68HC11E9s as I think I stated in an earlier post. So OTP E9s can be programmed once, windowed E9s can be programmed many times, and E1s can be programed zero times. Have you considered that if your code will fit in the RAM space of an E1 it will also fit in the EEPROM space of an E9. Best wishes, Bob Smith --- Avoid computer viruses, Practice safe hex --- -- Specializing in small, cost effective embedded control systems -- http://www.smithmachineworks.com/embedprod.html Robert L. (Bob) Smith Smith Machine Works, Inc. 9900 Lumlay Road Richmond, VA 23236 804/745-2608 ----- Original Message ----- From: "Torgeir Veimo" <> To: <> Sent: Tuesday, May 11, 2004 12:47 PM Subject: Re: [m68HC11] Re: HC11E1 - won't run in SC mode? > On Tue, 2004-05-11 at 12:36 -0400, Bob Smith wrote: > > A much simpler (and probably less expensive solution) is to throw away > > the > > E1s and drop in an E9. Both PCBUG11 and Jbug11 program them just > > fine. > > If you have a windowless E9, then its EPROM can only be programmed once? > -- > Torgeir Veimo < > -- ------ > Yahoo! Groups Links > > a.. To

Any individual bit can only be cleared, not set. As long as one is careful, there can be many programming sessions. But, there are methods where one can have multiple pseudo-interrupt vector tables so only the last table is active and any previous table is cleared. Emmett Redd Ph.D. mailto: 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: Torgeir Veimo [mailto:] > Sent: Tuesday, May 11, 2004 11:48 AM > To: > Subject: Re: [m68HC11] Re: HC11E1 - won't run in SC mode? > > On Tue, 2004-05-11 at 12:36 -0400, Bob Smith wrote: > > A much simpler (and probably less expensive solution) is to throw away > > the > > E1s and drop in an E9. Both PCBUG11 and Jbug11 program them just > > fine. > > If you have a windowless E9, then its EPROM can only be programmed once? > -- > Torgeir Veimo <

On Tue, 2004-05-11 at 12:36 -0400, Bob Smith wrote: > A much simpler (and probably less expensive solution) is to throw away > the > E1s and drop in an E9. Both PCBUG11 and Jbug11 program them just > fine. If you have a windowless E9, then its EPROM can only be programmed once? -- Torgeir Veimo <

A much simpler (and probably less expensive solution) is to throw away the E1s and drop in an E9. Both PCBUG11 and Jbug11 program them just fine. Bob --- Avoid computer viruses, Practice safe hex --- -- Specializing in small, cost effective embedded control systems -- http://www.smithmachineworks.com/embedprod.html Robert L. (Bob) Smith Smith Machine Works, Inc. 9900 Lumlay Road Richmond, VA 23236 804/745-2608 ----- Original Message ----- From: "John" <> To: <> Sent: Tuesday, May 11, 2004 11:54 AM Subject: [m68HC11] Re: HC11E1 - won't run in SC mode? > > --- In , Brian Moerdyk <bmoerdyk2@y...> wrote: > > You're right... To get memory in this space, you need to add an > external EPROM....unless you always want to run in BS mode... > > Thanks for responding Brian and confirming my conclusions. > > Yes, using external memory and expanded-mode with E1s is a solution, > but for simple jobs, I would like to stick with the simple BOT1's and > E1s (I have 5 of them) so I will have to run in BS-mode. > > It seems that to do this, I will need to add battery backup to > preserve the talker prog in RAM and also write prog in EEPROM to > change the bootloader's interupt vector JMPs after I disconnect JBug. > I haven't figured out how to do this yet. If it gets too complicated, > I'll give up and use external memory. > > I have 1 68HC11E2 which would also solve the problem, but only for 1 > application. > > Fortunately, I also have a few bigger, more complicated, BOT2 > prototype boards which support external memory. I was planning to use > these boards with E1s for more ambitious projects requing bigger > programs and lots of I/O. Maybe I will use them universaly? > > You also said... > > In BS mode, the interrupt vectors are starting at $BFC4 or > something like that, but they are three bytes (never understood this) > > I think I can help YOU there - extended jump instuctions need 3 bytes > > Thanks again for your support and quick response. > > FYI > My 1st project is a deisel engine controller/monitor for my yacht > (glowplug timer, tacho, engine temp, oil pressure, hydraulic oil > temp, alarms, etc). > Then I plan on an electronic compass (using a VECTOR compass module) > and more ambitiously, a fast (eventualy adaptive) autopilot with yaw > accelerometer inputs. > > Should keep me occupied for a while! > > Regards, jem > > > -- ------ > Yahoo! Groups Links > > a.. To