|
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! |
|
|
HC11E1 - won't run in SC mode?
Started by ●May 11, 2004
Reply by ●May 12, 20042004-05-12
Reply by ●May 13, 20042004-05-13
|
--- 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 |
|
|
Reply by ●May 13, 20042004-05-13
|
--- 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. |
|
|
Reply by ●May 13, 20042004-05-13
|
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 |
Reply by ●May 13, 20042004-05-13
|
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 |
|
|
