|
Hi, I'm quite new to the HC11 architecture. I've been able to install the GNU C compiler and got it working. But I wanted to know how to configure the system to use it in expanded mode. I want to load the PROM and use it with the 68HC11F1. I know that the MODA, MODB pins should be held high to enter into expanded mode, but its quite confusing as to how to get the microcontroller start fetching the instructions from the external PROM. Also, what should be done to relocate the interrupt vector. I have a lot of experience with flash micros having in built flash memory, but working with the 68HC11 in expanded mode is quite tricky. Any help is most appreciated. Best Regards, Naveen.P.N. |
|
|
expanded mode configuration
Started by ●July 28, 2004
Reply by ●July 28, 20042004-07-28
|
----- Original Message ----- From: "Naveen P N" <> To: < > I'm quite new to the HC11 architecture. I've been able to install the GNU C > compiler and got it working. But I wanted to know how to configure the > system to use it in expanded mode. I want to load the PROM and use it with > the 68HC11F1. I know that the MODA, MODB pins should be held high to enter > into expanded mode, but its quite confusing as to how to get the > microcontroller start fetching the instructions from the external PROM. In both normal modes, the microcontroller will always fetch instructions starting from the location shown in the reset vector. So, no mystery there. > Also, what should be done to relocate the interrupt vector. You don't relocate anything. The same addresses are used in both single-chip and expanded modes. It's only the actual memory used that's different. So, for single-chip you'll have to 'burn' the built-in memory with your code, while for expanded you'll do so in the external memory chip, RAM or EEPROM or Flash, or whatever you have glued at these addresses. > I have a lot of experience with flash micros having in built flash memory, > but working with the 68HC11 in expanded mode is quite tricky. Any help is > most appreciated. Nothing tricky really. If your hardware is correct, the software doesn't need to change locations or anything (except that it can no longer use some ports -- those used for address/data). > Naveen.P.N. |
Reply by ●July 29, 20042004-07-29
|
--- In , Naveen P N <naveen_pn@y...> wrote: > Hi, > I'm quite new to the HC11 architecture. I've been able to install > the GNU C compiler and got it working. But I wanted to know how to > configure the system to use it in expanded mode. I want to load > the PROM and use it with the 68HC11F1. I know that the MODA, MODB > pins should be held high to enter into expanded mode, but its > quite confusing as to how to get the microcontroller start > fetching the instructions from the external PROM. Also, what > should be done to relocate the interrupt vector. > > I have a lot of experience with flash micros having in built flash > memory, but working with the 68HC11 in expanded mode is quite > tricky. Any help is most appreciated. While it is true that working with a true FLASH-based single-chip micro is usually easier than having to program a memory device in a system configured to use external memory, it is really not *very* difficult. Offered below is some general advice for using a HC11 in expanded bus mode: - The Motorola HC11 Reference Manual includes a schematic for a expanded-mode HC11 system. While this design is not the best possible, it does illustrate the design techniques needed to build your own. The design shown in the HC11 Reference can be considerably simplified if you use a >= 32K FLASH ROM and 32K RAM. The total major IC list would be: HC11E-series MCU, 74HC373 (or HC573), a 29Cxxx-series FLASH ROM (I use 29C020 in my designs, since I have a bunch of them in DIP packages), a 32Kx8 SRAM (I use CY7C198), a 74HC00 NAND, a voltage regulator and some sort of reset generator. - I have just finished creating some schematics for both a single- chip and expanded-mode HC11 setup. Email me if you would like me to send you a TIFF image of either schematic. Both schematics were created using OrCAD v9.2. - If you use a 29Cxxx-series FLASH device for your ROM, you can use a program called 'JBug11' to program it in-circuit. There is a Yahoo Group dedicated to JBug support issues: http://groups.yahoo.com/group/Jbug11/ Some changes are required to the standard JBug setup to make it work with an expanded-mode system using FLASH memory, but the JBug documentation is pretty good, and the author of JBug participates in the forum named above (as do I and several other 'regulars' in this group) so you should be able to get assistance if you need it. - If nothing else, you can use a EPROM/device programmer to load your program code into the non-volatile memory of your choice. - If you design your own expanded-mode system, make sure that the FLASH/EPROM is mapped to the END of the HC11 memory space. For example, if you were using a 16K EPROM (27C128) for program storage, it should be mapped such that it appears in the HC11 memory space from $C000 to $FFFF. For a 32K device, map it to $8000-$FFFF. The HC11 fetches its reset and interrupt vectors from a table located at the very end of the address space. The RESET vector is fetched from $FFFE/$FFFF. - It is not absolutely required that you map a non-volatile memory device to the end of the address space - you could design a system that is entirely RAM based, but you would need to use a program such as JBug11 to load your code into the RAM to execute it. - If you are running your program in a 'debug' environment (using a monitor such as BUFFALO or bootstrap-mode-utilizing programs such as JBug11) you need to understand how the interrupt 'pseudo vectors' work. This is described briefly in the HC11 Reference Manual. If you need further advice as to how to initialize the pseudo-vectors, let me know and I'll try to help. I hope this helps - let me know if you need further assistance. -- Mark |
|
|
Reply by ●July 29, 20042004-07-29
|
Hi Mark, Thanks for your great help. Appreciate it a lot. I intended to connect external SRAM (16K) to test out the program (using GCC C compiler), after it tests ok, the SRAM will be replaced with a EPROM. Just one problem, the datasheet mentions that in expanded mode, EEPROM occupies FE00-FFFF. Doesn't it conflict with the SRAM if installed in same location? Is there any way this conflict can be avoided. I would very much like to have the reset & interrupt vectors under my control. Please excuse me if this is a no brainer question, but the information available for 68HC11 is overwhelming, so I just don't know where to dig out this kind of information. FYI, I'm using the MC69HC11F1 variant with decoded address/data buses to avoid external glue logic. Best Regards, Naveen.P.N. At 01:28 PM 29-07-04, you wrote: >--- In , Naveen P N <naveen_pn@y...> wrote: > > Hi, > > I'm quite new to the HC11 architecture. I've been able to install > > the GNU C compiler and got it working. But I wanted to know how to > > configure the system to use it in expanded mode. I want to load > > the PROM and use it with the 68HC11F1. I know that the MODA, MODB > > pins should be held high to enter into expanded mode, but its > > quite confusing as to how to get the microcontroller start > > fetching the instructions from the external PROM. Also, what > > should be done to relocate the interrupt vector. > > > > I have a lot of experience with flash micros having in built flash > > memory, but working with the 68HC11 in expanded mode is quite > > tricky. Any help is most appreciated. > >While it is true that working with a true FLASH-based single-chip >micro is usually easier than having to program a memory device in a >system configured to use external memory, it is really not *very* >difficult. Offered below is some general advice for using a HC11 in >expanded bus mode: > >- The Motorola HC11 Reference Manual includes a schematic for a >expanded-mode HC11 system. While this design is not the best >possible, it does illustrate the design techniques needed to build >your own. The design shown in the HC11 Reference can be >considerably simplified if you use a >= 32K FLASH ROM and 32K RAM. >The total major IC list would be: HC11E-series MCU, 74HC373 (or >HC573), a 29Cxxx-series FLASH ROM (I use 29C020 in my designs, since >I have a bunch of them in DIP packages), a 32Kx8 SRAM (I use >CY7C198), a 74HC00 NAND, a voltage regulator and some sort of reset >generator. > >- I have just finished creating some schematics for both a single- >chip and expanded-mode HC11 setup. Email me if you would like me to >send you a TIFF image of either schematic. Both schematics were >created using OrCAD v9.2. > >- If you use a 29Cxxx-series FLASH device for your ROM, you can use >a program called 'JBug11' to program it in-circuit. There is a >Yahoo Group dedicated to JBug support issues: > ><http://groups.yahoo.com/group/Jbug11/" target="_blank" rel="nofollow">http://groups.yahoo.com/group/Jbug11/>http://groups.yahoo.com/group/Jbug11/ > >Some changes are required to the standard JBug setup to make it work >with an expanded-mode system using FLASH memory, but the JBug >documentation is pretty good, and the author of JBug participates in >the forum named above (as do I and several other 'regulars' in this >group) so you should be able to get assistance if you need it. > >- If nothing else, you can use a EPROM/device programmer to load >your program code into the non-volatile memory of your choice. > >- If you design your own expanded-mode system, make sure that the >FLASH/EPROM is mapped to the END of the HC11 memory space. For >example, if you were using a 16K EPROM (27C128) for program storage, >it should be mapped such that it appears in the HC11 memory space >from $C000 to $FFFF. For a 32K device, map it to $8000-$FFFF. The >HC11 fetches its reset and interrupt vectors from a table located at >the very end of the address space. The RESET vector is fetched from >$FFFE/$FFFF. > >- It is not absolutely required that you map a non-volatile memory >device to the end of the address space - you could design a system >that is entirely RAM based, but you would need to use a program such >as JBug11 to load your code into the RAM to execute it. > >- If you are running your program in a 'debug' environment (using a >monitor such as BUFFALO or bootstrap-mode-utilizing programs such as >JBug11) you need to understand how the interrupt 'pseudo vectors' >work. This is described briefly in the HC11 Reference Manual. If >you need further advice as to how to initialize the pseudo-vectors, >let me know and I'll try to help. > >I hope this helps - let me know if you need further assistance. > >-- Mark > >---------- >>Yahoo! Terms of Service. |
|
|
Reply by ●July 29, 20042004-07-29
|
----- Original Message ----- From: "Naveen P N" <> To: < > the SRAM will be replaced with a EPROM. Just one problem, the > datasheet mentions that in expanded mode, EEPROM occupies FE00-FFFF. > Doesn't it conflict with the SRAM if installed in same location? Is there > any way this conflict can be avoided. Just write the appropriate value to the CONFIG register to move EEPROM to another page. > Naveen.P.N. |
Reply by ●July 29, 20042004-07-29
|
--- In , Naveen P N <naveen_pn@y...> wrote: > I intended to connect external SRAM (16K) to test out the program > (using GCC C compiler), after it tests ok, the SRAM will be > replaced with a EPROM. Just one problem, the datasheet mentions > that in expanded mode, EEPROM occupies FE00-FFFF. Doesn't it > conflict with the SRAM if installed in same location? Is there > any way this conflict can be avoided. I would very much like to > have the reset & interrupt vectors under my control. Please excuse > me if this is a no brainer question, but the information available > for 68HC11 is overwhelming, so I just don't know where to dig out > this kind of information. FYI, I'm using the MC69HC11F1 variant > with decoded address/data buses to avoid external glue logic. As Tony P. mentioned in a earlier message, you can change the CONFIG register to either disable or move the EEPROM to a location outside of the range where your SRAM is mapped. It should be noted that when the F1 device is stared up in a single- chip mode, the EEPROM is *always* enabled and *always* mapped to locations $FE00-$FFFF. I'm sure that this is a quite intentional design feature, as the F1 does not have any internal ROM, and as such, the EEPROM serves this purpose. In expanded modes, the mapping of the EEPROM is controlled by the CONFIG register setting. Having a place to store non-volatile configuration information can be a useful thing to have in almost any non-trivial application, so my suggestion would be to set the CONFIG register to the binary value 01111111 ($7F). This setting will map the EEPROM to locations $7E00-$7FFF - out of the range of your SRAM but still accessible in the memory map. If you are sure you will not be needing the EEPROM for your application, you can disable it entirely by setting bit 0 of CONFIG to 0. The CONFIG register is described in detail starting on page 4-9 of the MC68HC11F1 Technical Data document, which you should obtain from the Motorola website if you have not done so already. The CONFIG setting is implemented as a EEPROM cell, enabling the desired configuration to be set immediately upon startup. You can use a debugger program such as JBug11 to change its value. As you are likely know already, the 'F1 provides 4 programmable 'chip select' outputs on the upper 4 bits of PORTG. The best CSxxxx output to use for your application would be CSPROG, since you intend to eventually replace your SRAM with a EPROM for program storage. The CSxxxx outputs can be used as memory-mapped device selects, eliminating or reducing the need for external bus decode logic. -- Mark |
Reply by ●July 31, 20042004-07-31
|
Hi, Thanks to all of you for the great help, I'm getting the feeling that I'm making some progress. But I'm doing something wrong. I cannot get to turn the EEPROM OFF in CONFIG. I'm doing the following: 1) Set MODA/MODB both to low on my custom rigged dev board. 2) Open JBUG11 > Settings> Memory Map 3) Choose F1 under "common chip defaults" 4) Enter the SRAM memory map as 8000..FFFF under "External flash PROM" 5) Go to the "General" tab and uncheck "Allow local commands only" & check "Allow writing to CONFIG". 6) Reset the board. 7) Type "R BPROT= 0F" to turn off PTCON (protect config register) 8) Type "R CONFIG" to turn off EEPROM 9) Jbug outputs a message to reset the board. 10) After reset, I give "R CONFIG". 11) The result is: "103F CONFIG [FF%5]" 12) The CONFIG register is not setting to FE. Am I missing something here? Please help. I'm pasting below the output window contents for your reference. r config 103F CONFIG [FF%5] (EE3) (EE2) (EE1) (EE0) NOSEC NOCOP ROMON EEON r bprot 1035 BPROT [1F= 31] 0 0 0 PTCON BPRT3 BPRT2 BPRT1 BPRT0 r bprot 1035 BPROT [0F= 15] 0 0 0 PTCON BPRT3 BPRT2 BPRT1 BPRT0 r bprot 1035 BPROT [0F= 15] 0 0 0 PTCON BPRT3 BPRT2 BPRT1 BPRT0 r config 103F CONFIG Note: reset MCU for new value to take effect Using RAM based talker on COM1 :- +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F 0000 00 8E 00 ED CE 10 00 6F 2C CC 30 2C A7 2B E7 2D .......o,.0,.+.- 0010 86 40 06 7E 00 12 B6 10 2E 84 20 27 F9 B6 10 2F .@.~...... '.../ 0020 43 8D 46 2A 51 8D 33 8F 8D 30 17 8D 2D 8F 81 FE C.F*Q.3..0..-... 0030 26 0D A6 00 8D 33 17 8D 21 16 08 5A 26 F4 3B 81 &....3..!..Z&.;. 0040 BE 26 16 17 8D 14 E7 00 18 CE 00 01 18 09 26 FC .&............&. 0050 E6 00 F7 10 2F 08 4A 26 EB 3B F6 10 2E C5 0A 26 ..../.J&.;.....& 0060 A0 C4 20 27 F5 F6 10 2F 39 18 8F B6 10 2E 2A FB .. '.../9.....*. 0070 18 8F B7 10 2F 39 81 7E 26 0C 30 8F 8D EB 17 8D ..../9.~&.0..... 0080 E8 30 C6 09 20 AC 81 3E 26 12 8D CE 17 8D CB 8F .0.. ..>&....... 0090 35 86 09 20 AF 86 4A 8D D0 0E 20 FD 81 4A 26 B9 5.. ..J... ..J&. 00A0 30 C6 09 3A 35 EC 07 8D C0 17 8D BD CC 00 98 ED 0..:5........... 00B0 07 20 C7 00 00 00 00 00 00 00 00 00 00 00 00 00 . .............. 00C0 00 00 00 00 00 7E 00 15 7E 00 58 7E 00 58 7E 00 .....~..~.X~.X~. 00D0 58 7E 00 58 7E 00 58 7E 00 58 7E 00 58 7E 00 58 X~.X~.X~.X~.X~.X 00E0 7E 00 58 7E 00 58 7E 00 58 7E 00 58 7E 00 58 7E ~.X~.X~.X~.X~.X~ 00F0 00 58 7E 00 58 7E 00 58 7E 00 00 7E 00 58 7E 00 .X~.X~.X~..~.X~. r config 103F CONFIG [FF%5] (EE3) (EE2) (EE1) (EE0) NOSEC NOCOP ROMON EEON Best Regards, Naveen.P.N. At 11:53 PM 29-07-04, you wrote: >--- In , Naveen P N <naveen_pn@y...> wrote: > > > I intended to connect external SRAM (16K) to test out the program > > (using GCC C compiler), after it tests ok, the SRAM will be > > replaced with a EPROM. Just one problem, the datasheet mentions > > that in expanded mode, EEPROM occupies FE00-FFFF. Doesn't it > > conflict with the SRAM if installed in same location? Is there > > any way this conflict can be avoided. I would very much like to > > have the reset & interrupt vectors under my control. Please excuse > > me if this is a no brainer question, but the information available > > for 68HC11 is overwhelming, so I just don't know where to dig out > > this kind of information. FYI, I'm using the MC69HC11F1 variant > > with decoded address/data buses to avoid external glue logic. > >As Tony P. mentioned in a earlier message, you can change the CONFIG >register to either disable or move the EEPROM to a location outside >of the range where your SRAM is mapped. > >It should be noted that when the F1 device is stared up in a single- >chip mode, the EEPROM is *always* enabled and *always* mapped to >locations $FE00-$FFFF. I'm sure that this is a quite intentional >design feature, as the F1 does not have any internal ROM, and as >such, the EEPROM serves this purpose. In expanded modes, the >mapping of the EEPROM is controlled by the CONFIG register setting. > >Having a place to store non-volatile configuration information can >be a useful thing to have in almost any non-trivial application, so >my suggestion would be to set the CONFIG register to the binary >value 01111111 ($7F). This setting will map the EEPROM to locations >$7E00-$7FFF - out of the range of your SRAM but still accessible in >the memory map. If you are sure you will not be needing the EEPROM >for your application, you can disable it entirely by setting bit 0 >of CONFIG to 0. > >The CONFIG register is described in detail starting on page 4-9 of >the MC68HC11F1 Technical Data document, which you should obtain from >the Motorola website if you have not done so already. The CONFIG >setting is implemented as a EEPROM cell, enabling the desired >configuration to be set immediately upon startup. You can use a >debugger program such as JBug11 to change its value. > >As you are likely know already, the 'F1 provides 4 >programmable 'chip select' outputs on the upper 4 bits of PORTG. >The best CSxxxx output to use for your application would be CSPROG, >since you intend to eventually replace your SRAM with a EPROM for >program storage. The CSxxxx outputs can be used as memory-mapped >device selects, eliminating or reducing the need for external bus >decode logic. > >-- Mark > >---------- >>Yahoo! Terms of Service. |
|
|
Reply by ●July 31, 20042004-07-31
|
In a message dated 7/31/04 12:13:02 PM Eastern Daylight Time, writes: I cannot get to turn the EEPROM OFF in CONFIG. ========================== The config reg needs to be written in the 1st 64 cycles, right? I have a little 'bootable' program that does this, but its at work..... You edit and assemble a small program that will load and run in ram, and convert the hex file to binary, and use a hex editor to add an FF as the 1st byte. This is the 'bootable' program you will send. You put the mode pins into boot mode, then you send the program at 9600 baud (the 1st byte and the xtal freq determines the boot baud rate... it is described in the f1 boot appnote). The program starts running and 'burns' the config byte. I'll send the assy source to my prog from work on Monday if you respond with another request message. |
Reply by ●July 31, 20042004-07-31
|
--- In , Naveen P N <naveen_pn@y...> wrote: > Hi, > Thanks to all of you for the great help, I'm getting the feeling > that I'm making some progress. But I'm doing something wrong. I > cannot get to turn the EEPROM OFF in CONFIG. > > I'm doing the following: > > 1) Set MODA/MODB both to low on my custom rigged dev board. > 2) Open JBUG11 > Settings> Memory Map > 3) Choose F1 under "common chip defaults" > 4) Enter the SRAM memory map as 8000..FFFF under "External flash > PROM" Since you are (for now) using SRAM in the place of a FLASH device (according to an earlier message you posted), you should not define a range for FLASH at this point. Instead, add a entry to the RAM list like this: External RAM00..FFFF Also, check the range specified for EEPROM. If you are following my earlier suggestion to re-map it to 7E00..7FFF, enter this range in the space provided. Otherwise, specify the appropriate range for the configuration you plan on selecting, or delete it entirely if you choose to set EEON=0 in CONFIG. There are one or two other changes that you need to make, which I will discuss in a moment... > 5) Go to the "General" tab and uncheck "Allow local commands only" > & check "Allow writing to CONFIG". > 6) Reset the board. > 7) Type "R BPROT= 0F" to turn off PTCON (protect config register) > 8) Type "R CONFIG" to turn off EEPROM > 9) Jbug outputs a message to reset the board. > 10) After reset, I give "R CONFIG". > 11) The result is: "103F CONFIG [FF%5]" > 12) The CONFIG register is not setting to FE. The reason you cannot seem to change CONFIG is due to the fact that when you start up the 'F1 in bootstrap mode (which is required in most cases for JBug to work properly) the stored value of CONFIG is mostly ignored; the EEPROM is always enabled, and always mapped to locations $FE00..FFFF. Fortunately, there is a way to overcome this problem. JBug conveniently provides an option to automatically switch the MCU mode after it starts up. This is done by enabling the "Alter HPRIO on reboot?" option under the General tab in the Configuration dialog, along with specifying an appropriate value in the "Byte to send:" entry box to the right. The value you want to put here is $E6, which will: RBOOT[7]=1: Enable the bootstrap ROM at $BF00..$BFFF (JBug expects the bootloader ROM to be in place) SMOD[6]=1: "Special" mode enabled, no register write time limits. MDA[5]=1: Expanded mode enabled, external bus active IRV[4]=0: Internal Read Visibility off, reads from internal HC11 resources do not appear on the external bus. PSEL[3:0]=6: Selects highest priority interrupt. With this setting, you will now be able to change the CONFIG register, and the CONFIG setting you select will be active when you reboot. Furthermore, the external bus will be enabled, allowing you to use JBug to read/write from/to your external RAM (assuming you add the "External RAM00..FFFF" line to the RAM list as I mentioned previously). Two more obscure caveat about the F1: (1). When Special Test mode is enabled (by changing HPRIO.SMOD=1 and HPRIO.MDA=1), a 256-byte chunk of the address space at $FD00.FDFF is effectively removed from the memory map. Reads and writes to these locations will NOT be seen on the external bus! This is generally not a problem, as nothing 'important' (like reset/interrupt vectors) reside in this space. Nonetheless, you should be aware of this caveat should your code grow to a size such that this space would be needed. (2). Another oddity of the Special Test mode is that, like the bootstrap mode, the interrupt vectors are NOT fetched from the usual $FFC0..$FFFF space; rather, they are fetched from $BFC0..$BFFF. When HPRIO.RBOOT=1, the bootloader ROM occupies this space. When you are testing your code to run under JBug, if you are going to use any interrupts you will have to change the interrupt 'pseudo vectors' in RAM. The pseudo-vector setup is discussed in some detail in the HC11 Reference Manual (rev. 6) starting on page 112. A practical example showing how the pseudo-vectors are used can be found in the same manual in the section that describes the timer subsystem. Try searching this document for the word 'pseudo' for additional material. Note that when you switch over your application to run in a 'standalone' mode (MODA=MODB=1 to select normal expanded mode), you will have to modify your code to use the 'normal' HC11 interrupt vector system. As you mentioned that you will be using gcc, I'd suggest you use a #define in conjunction with #ifdef / #ifndef to conditionally include/exclude those portion(s) of code that differ from running in a normal expanded vs. special test environment. To further muddy the waters, there's a third possible configuration you could start up in - you could set MODA=1 and MODB=0 so you START UP in special test mode after reset. When you start up in special test mode, HPRIO.RBOOT=0, so the bootstrap ROM is disabled... but the interrupt vectors are still fetched from $BFC0..$BFFF. In this mode, you'd define a interrupt vector table the same way you would if you were operating in normal expanded mode, but the table would have to be located at $BFC0..$BFFF instead of it's usual spot at $FFC0..$FFFF. The MC68HC11F1 Technical Data document, Section 4, provides a reasonably cogent discussion of the various modes of operation and the consequences of selecting the various modes. I would suggest that you read this section carefully, esp. subsections 4.1-4.3. Good luck, and feel free to ask if you have any more questions. -- Mark |
