|
I am using MC68HC11F1 in a project. But I am facing siome problem in getting started with hardware interface and programing. I am using JBug11 to communicate with the chip. How I can interface External SRAM to MC68HC11F1. What to do with OE and WE\ pins of SRAM. If I am using Jbug11 which all lines have to be connected to interface with SRAM. How i can download a program in .s19 format to the exrernal SRAM and How i can execute it. |
|
|
Interfacing MC68HC11F1 with external SRAM
Started by ●August 25, 2004
Reply by ●August 25, 20042004-08-25
|
--- In , "jackson_cp" <jackson_cp@y...> wrote: > I am using MC68HC11F1 in a project. But I am facing siome problem > in getting started with hardware interface and programing. > > I am using JBug11 to communicate with the chip. > How I can interface External SRAM to MC68HC11F1. > What to do with OE and WE\ pins of SRAM. If I am using Jbug11 > which all lines have to be connected to interface with SRAM. > > How i can download a program in .s19 format to the exrernal SRAM > and How i can execute it. Adding external memory to a HC11F1 is quite easy, since the 'F1 provides a non-multiplexed bus (no 'HC373/573 address latch required) and also provides up to 4 firmware-programmable chip selects for memory-mapped devices. About the only extra hardware you will require - other than the RAM/ROM device(s) themselves, is a small bit of glue logic to generate the -OE (-RD) and -WE (-WR) signals that most static memory devices require. It is my preference (although, perhaps, not absolutely required) to use a 3 NAND gate approach to create these signals. I would attempt to create a ASCII graphic of the suggested schematic here, but the Yahoo message formatter would likely distort it, so I will provide a point-to-point wiring list instead. Parts needed: One (1) 74HC00 quad NAND gate. 3 of the 4 NAND gates in this package will be used. I will refer to the individual gates by letter - Gate A,B,C and D. Gate A input 1 (pin 1) to HC11 E-clock output (pin 4) Gate A input 2 (pin 2) to HC11 RW output (pin 5) Gate A output (pin 3) is -OE (-RD) signal for memory. Gate B is not used - tie its inputs (pins 4 and 5) to ground. Gate C input 1 (pin 9) to HC11 E-clock output (pin 4) Gate C input 2 (pin 10) to Gate D output (pin 11) Gate C output (pin 8) is -WE (-WR) signal for memory. Gate D inputs 1 & 2 (pins 12 & 13) to HC11 RW output (pin 5) Gate D output (pin 11) to Gate C input 2 (pin 10) Gate D is used to invert the HC11 RW signal. Here's a schematic - it will probably get clobbered, but I'll try anyway: . 74HC00 . 1 _____ .E ----o--| \ 3 . | | A |o-----> -RD .RW --o-|--|_____/ . | | 2 . | | . | | 9 _____ . | o--| \ 8 . | | C |o-----> -WR . | o--|_____/ . | |10 . | o--------------o . | 12 _____ | . o----| \ 11 | . | | D |o---o . o----|_____/ . 13 . . 4 _____ . o----| \ 6 . | | B |o----- . o----|_____/ . | 5 . _|_ . - Gnd -------------------- If you intend to use both RAM and ROM/(E)EPROM/FLASH in your design, use the F1's PG7 (CSPROG) output as the chip select (-CE/-CS) signal for the ROM device, and PG6 (CSGEN) for the RAM chip select. If you will only be adding external RAM, use PG7/CSPROG as the chip select. It would not be a bad idea to add 4.7K pull-down resistors on pins PG7 (20) and PG6 (21) if you are using it. Doing this will ensure that the external memory that is selected by these pins will stay de- selected when the 'F1 is reset into a non-external-bus mode (e.g. bootstrap or single chip). Note, however, that if you do run the 'F1 in single-chip or bootstrap mode, and attempt to use PG7 (or PG6, if it is being used as a chip select) as general-purpose I/O, you might inadvertently enable the data bus on the RAM and/or ROM, which will be connected to Port C - furthermore, if you do have two (or more) memory devices on the bus, it is possible that you might enable both for output at the same time - not a good thing. If you are using any of the Port G lines for chip selects, avoid using these as general-purpose I/O in single-chip mode. Initialize them to the inactive (typically LOW) level in your code, and leave them alone afterward. For more information on the F1's programmable chip select subsystem, read section 4.5 of the MC68HC11F1 Technical Reference. After reading this, if you have any further questions, feel free to ask. Once you have your RAM (and/or other memory devices) connected, you can read/write to it using JBug. Since JBug requires that you start up in Bootstrap mode (and hence, with the external bus disabled) you will need to change some JBug settings to enable the external bus. Go to JBug's configuration dialog under the general tab, and check the 'Alter HPRIO on reboot' checkbox. Enter the value 'E5' in the space provided ('Byte to send:'). You should also set the 'common chip defaults' to the 'F1 setting. Once JBug has started, and has uploaded the talker to your board, the HPRIO register will be changed to a setting that will enable the external memory bus (assuming you use the suggested value of $E5 for the HPRIO setting). At this point, the external memory will be addressable by the HC11, and JBug can be used to read/write/load/save from/to it. Oh, one more thing about JBug settings - you will need to add a entry to the text box labelled 'RAM' under the 'Memory Map' tab of the configuration dialog. If you have mapped your RAM to addresses $8000-$FFFF, add a line that looks like this: External RAM00..FFFF If the mapping of your RAM is different, simply replace the addresses shown above with the appropriate ones for your configuration. You might find that you will have to (manually) change the setting of the CSSTRH, CSCTL, CSGADR and CSGSIZ registers from their post- reset defaults to get all of your memory devices working properly. The post-reset defaults should be OK if you are using a single memory device controlled by the CSPROG (PG7) chip select. I usually use a JBug AUTOSTART macro to automatically modify these registers following a reboot on my 'F1 projects. Any code you write should, of course, initialize the aforementioned registers as part of its init routine. |
Reply by ●August 25, 20042004-08-25
|
Oh, one last thing I forgot to mention regarding the 'F1 and external memory - I have recently created a schematic for a 'F1 expanded mode evaluation board that I have just finished prototyping. I think I have most of the bugs worked out of the design, and would be willing to send a TIF image of the schematic to anyone who asks for it. Once I have completed verification of my prototype, I will upload this image (and a few other HC11 schematics I have created) to the files section of this group. Note that the 'F1 design I have created is not a absolutely minimalistic implementation. I have added a bit of external logic that provides the following extra features: - 29C020 ROM (256K x 8 FLASH) - CY7C198 RAM (32K x 8 SRAM) - 8-position DIP switch to set MODA/MODB, enable or disable external bus components, provide optional DTR-driven RESET (useful for JBug), connect -XIRQ to PA3 or PD0 (for BUFFALO or JBug X00 talker trace), and control the pull-up or pull-down for the CSIO2 chip select. - Extra logic (a single 74HC125) is used to buffer the chip select lines, and is put into Hi-Z mode (with pullups or pulldowns on the outputs) when the external bus is disabled by the DIP switch. - A 74HC138 is used, controlled by A8, A9, A10 and CSIO1, to provide 7 extra peripheral device select lines. - A 74HC373 latch is memory-mapped to location $1060, and is used to provide FLASH address lines A15-A17, which allows full utilization of the 256K FLASH device with appropriate bank-switching code. - Headers are shown on the schematic to bring out all the port lines, as well as the entire memory bus and bus control signals. - An extra header is shown that can be used to connect a standard LCD character module, controlled by the CSIO2 chip select. The nice thing about this design is that it can be used - with appropriate DIP switch settings - in either external-bus or single- chip modes. |
|
|
Reply by ●August 26, 20042004-08-26
|
Hi Mark, We would appreciate the schematic diagram in tif format. Please do send it to "naveen_pn AT yahoo DOT com" (- to avoid spammers, please replace AT & DOT with proper symbols). Myself and Jackson are working on the same project. This is our first project on 68hc11 architecture. We have been using flash based MCUs in several projects and finding it EXTREMELY difficult to get a 68HC11F1 based board working. We intend to accomplish the following: 1) (a) Make a 68HC11F1 board with external SRAM (32KB- CY62256) to test out example programs (external SRAM used to hold programs) (b) Example programs will be developed with GNU C in combination with EmbeddedGNU IDE for 68hc11 (http://www.ericengler.com/EmbeddedGNU.aspx). (c) We are yet to see the 68HC11F1 run a simple LED blinking program that is written in C (compiled to s19) & loaded into external SRAM using jbug11 (or any other loader). This is our first goal. (d) So our immediate requirement would be to learn how to load our C program (compiled into .s19 file) into the external SRAM and get the program to execute (expanded mode). 2) After we test out some sample programs of varying complexity in C, we will be moving on to PROM interfacing. That is, in place of the SRAM, we will have a 32KB PROM (UV erasable) in place for the final project. We know there are lots of information about 68hc11, but all of them are limited to using development boards from companies with their proprietary loader software. We want to develop our own custom designed board and get the software working on it (expanded mode) & finding it very hard to accomplish this. Any help to get us going in this direction would be most appreciated. Best Regards, Naveen.P.N. At 01:51 AM 26-08-04, you wrote: >Oh, one last thing I forgot to mention regarding the 'F1 and >external memory - I have recently created a schematic for a 'F1 >expanded mode evaluation board that I have just finished >prototyping. I think I have most of the bugs worked out of the >design, and would be willing to send a TIF image of the schematic to >anyone who asks for it. Once I have completed verification of my >prototype, I will upload this image (and a few other HC11 schematics >I have created) to the files section of this group. > >Note that the 'F1 design I have created is not a absolutely >minimalistic implementation. I have added a bit of external logic >that provides the following extra features: > >- 29C020 ROM (256K x 8 FLASH) >- CY7C198 RAM (32K x 8 SRAM) >- 8-position DIP switch to set MODA/MODB, enable or disable external >bus components, provide optional DTR-driven RESET (useful for JBug), >connect -XIRQ to PA3 or PD0 (for BUFFALO or JBug X00 talker trace), >and control the pull-up or pull-down for the CSIO2 chip select. >- Extra logic (a single 74HC125) is used to buffer the chip select >lines, and is put into Hi-Z mode (with pullups or pulldowns on the >outputs) when the external bus is disabled by the DIP switch. >- A 74HC138 is used, controlled by A8, A9, A10 and CSIO1, to provide >7 extra peripheral device select lines. >- A 74HC373 latch is memory-mapped to location $1060, and is used to >provide FLASH address lines A15-A17, which allows full utilization >of the 256K FLASH device with appropriate bank-switching code. >- Headers are shown on the schematic to bring out all the port >lines, as well as the entire memory bus and bus control signals. >- An extra header is shown that can be used to connect a standard >LCD character module, controlled by the CSIO2 chip select. > >The nice thing about this design is that it can be used - with >appropriate DIP switch settings - in either external-bus or single- >chip modes. > >---------- >>Yahoo! Terms of Service. |
|
|
Reply by ●August 26, 20042004-08-26
|
I would think that one would need a "Bootloader" program that is
first downloaded into the HC11 internal RAM. This program would then execute and
send your file to the necessary locations in the External RAM. This seems to be
how all of those proprietary companies you speak of do it. You will find a
bootloader program in the appendix pages of the Motorola Reference Manual for
that particular MCU. I would suggest spending $68 at
http://www.technologicalarts.com for their Microcore11 board, then simply
investigate as to how they do it! If you don't want to spend the money,
they do have scematics and the software for these boards free for anybody to
download. I really like these modules though, and I have never (as of yet)
needed any more I/O pins than what they provide. You can't beat the size
either, at 2" X 2" how can you go wrong? This is just my two cents
though. Take care. LF Naveen P N <> wrote:Hi Mark, We would appreciate the schematic diagram in tif format. Please do send it to "naveen_pn AT yahoo DOT com" (- to avoid spammers, please replace AT & DOT with proper symbols). Myself and Jackson are working on the same project. This is our first project on 68hc11 architecture. We have been using flash based MCUs in several projects and finding it EXTREMELY difficult to get a 68HC11F1 based board working. We intend to accomplish the following: 1) (a) Make a 68HC11F1 board with external SRAM (32KB- CY62256) to test out example programs (external SRAM used to hold programs) (b) Example programs will be developed with GNU C in combination with EmbeddedGNU IDE for 68hc11 (http://www.ericengler.com/EmbeddedGNU.aspx). (c) We are yet to see the 68HC11F1 run a simple LED blinking program that is written in C (compiled to s19) & loaded into external SRAM using jbug11 (or any other loader). This is our first goal. (d) So our immediate requirement would be to learn how to load our C program (compiled into .s19 file) into the external SRAM and get the program to execute (expanded mode). 2) After we test out some sample programs of varying complexity in C, we will be moving on to PROM interfacing. That is, in place of the SRAM, we will have a 32KB PROM (UV erasable) in place for the final project. We know there are lots of information about 68hc11, but all of them are limited to using development boards from companies with their proprietary loader software. We want to develop our own custom designed board and get the software working on it (expanded mode) & finding it very hard to accomplish this. Any help to get us going in this direction would be most appreciated. Best Regards, Naveen.P.N. At 01:51 AM 26-08-04, you wrote: >Oh, one last thing I forgot to mention regarding the 'F1 and >external memory - I have recently created a schematic for a 'F1 >expanded mode evaluation board that I have just finished >prototyping. I think I have most of the bugs worked out of the >design, and would be willing to send a TIF image of the schematic to >anyone who asks for it. Once I have completed verification of my >prototype, I will upload this image (and a few other HC11 schematics >I have created) to the files section of this group. > >Note that the 'F1 design I have created is not a absolutely >minimalistic implementation. I have added a bit of external logic >that provides the following extra features: > >- 29C020 ROM (256K x 8 FLASH) >- CY7C198 RAM (32K x 8 SRAM) >- 8-position DIP switch to set MODA/MODB, enable or disable external >bus components, provide optional DTR-driven RESET (useful for JBug), >connect -XIRQ to PA3 or PD0 (for BUFFALO or JBug X00 talker trace), >and control the pull-up or pull-down for the CSIO2 chip select. >- Extra logic (a single 74HC125) is used to buffer the chip select >lines, and is put into Hi-Z mode (with pullups or pulldowns on the >outputs) when the external bus is disabled by the DIP switch. >- A 74HC138 is used, controlled by A8, A9, A10 and CSIO1, to provide >7 extra peripheral device select lines. >- A 74HC373 latch is memory-mapped to location $1060, and is used to >provide FLASH address lines A15-A17, which allows full utilization >of the 256K FLASH device with appropriate bank-switching code. >- Headers are shown on the schematic to bring out all the port >lines, as well as the entire memory bus and bus control signals. >- An extra header is shown that can be used to connect a standard >LCD character module, controlled by the CSIO2 chip select. > >The nice thing about this design is that it can be used - with >appropriate DIP switch settings - in either external-bus or single- >chip modes. > >---------- >>Yahoo! Terms of Service. --------------------------------- Yahoo! Groups Links To __________________________________________________ |
Reply by ●August 26, 20042004-08-26
|
In a message dated 8/26/04 10:50:08 A.M. Eastern Daylight Time, writes: finding it EXTREMELY difficult to get a 68HC11F1 based board working. ================================ As you know from the datasheet, the F1 has a boot loader program on its internal bootrom.... it looks at the 1st char received to determine baudrate, then reads in binary thru the sci until gap of 4 char times or 512 bytes received, then jumps to beginning of ram. We have an hc11f1 board that uses the atmel 32k roms, and I wrote a little rom burner program that reads in the ascii/hex srecords a line at a time and burns then rom.... this little rom burner is the program that gets 'booted' into the ram in binary at power up.... the program that does this is a simple terminal type program I wrote in vc that just opens the file, reads it byte by byte and sends it to com1. You could use basic or java or whatever pc language you are good with. Are you going to have a flash rom on your board, or just dl the programs to ram for testing? |
|
|
Reply by ●August 26, 20042004-08-26
|
Hi, Thanks for your response. As I had mentioned in my post, we intend to first get the board working with some external SRAM (to hold the programs). Once we have tested programs which are run from external SRAM, we will be switching over to ROMs on which the final program will be burnt. Best Regards, Naveen.P.N. At 09:25 PM 26-08-04, you wrote: >In a message dated 8/26/04 10:50:08 A.M. Eastern Daylight Time, > writes: > >finding it EXTREMELY difficult to get a 68HC11F1 based >board working. >================================ >As you know from the datasheet, the F1 has a boot loader program on its >internal bootrom.... it looks at the 1st char received to determine >baudrate, >then reads in binary thru the sci until gap of 4 char times or 512 bytes >received, then jumps to beginning of ram. We have an hc11f1 board that >uses the >atmel 32k roms, and I wrote a little rom burner program that reads in the >ascii/hex srecords a line at a time and burns then rom.... this little >rom burner is >the program that gets 'booted' into the ram in binary at power up.... the >program that does this is a simple terminal type program I wrote in vc that >just opens the file, reads it byte by byte and sends it to com1. You could >use >basic or java or whatever pc language you are good with. Are you going to >have >a flash rom on your board, or just dl the programs to ram for testing? >---------- >>Yahoo! Terms of Service. |
|
|
Reply by ●August 26, 20042004-08-26
|
Here is a bootable program to flash an led on pa6. The s19 file has been converted to bootable binary with the FF at the front... I use a utility from simtel.com called binedit to do this.... so you should be able to just run the bat file and see the pin shake..... |
Reply by ●August 27, 20042004-08-27
|
--- In , Naveen P N <naveen_pn@y...> wrote: > Thanks for your response. As I had mentioned in my post, we intend > to first get the board working with some external SRAM (to hold > the programs). Once we have tested programs which are run from > external SRAM, we will be switching over to ROMs on which the > final program will be burnt. Have you ever heard of JBug11? It is a debugger program for the HC11 that utilizes the HC11 bootstrap mode. You can get it at: http://freespace.virgin.net/john.beatty/Jbug11_main.html JBug will work with almost any HC11 system that has appropriate serial-port hardware (MAX232 or equivalent tied to HC11 port lines PD0 and PD1) and can be configured to run in bootstrap mode (by tying HC11 pins MODA and MODB low). With JBug, you can modify memory, read/write the HC11 control registers directly, use the built-in mini-assembler to write small test programs that you can run or single-step through, and load .S19 (motorola S-record) files into RAM/EEPROM/FLASH. I have recently used JBug to test the functionality of a prototype HC11-based board that I just finished building; it is a very good tool to use for this purpose. Once you have verified the functionality of your board using JBug (it will work with an expanded-mode system that uses external memory if set up properly), you can proceed to use the gnu toolset to develop your software, and use JBug to debug it. There is a Yahoo Group dedicated to the discussion of JBug11 - you will find it at: http://groups.yahoo.com/group/Jbug11/ Good luck with your project. |
