Mahajan, Gauri (IE03x) wrote: > Hi Mike!
>
> Thanks a lot for your valuable advise! After your mail, we turned our
> focus in that direction and on Friday came to the conclusion that this
> is the only possibility. Till that time we tried each and every option
[.... We ascertained that the]
> ROMON bit was enabled. So it was executing from
internal memory. We just
> disabled that and we could execute our test program in expanded mode
> from external flash. Actually, this chip was custom part and was
> supposed to have no internal ROM memory.
[snip]
> Thanks a lot again!!
Glad to be of service. It's always hard to figure out what's wrong
with one's program when it isn't actually the one being executed!
:-)
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!
Reply by Mahajan, Gauri \IE03x\●December 19, 20052005-12-19
Hi Mike!
Thanks a lot for your valuable advise! After your mail, we turned our
focus in that direction and on Friday came to the conclusion that this
is the only possibility. Till that time we tried each and every option
possible in hardware, putting pull-ups on data bus, changing operating
frequency to 1 MHz etc. etc. But It didn't worked. Finally on Saturday
we put the processor in the universal programmer and checked ROMON bit.
As you have said, it is a 68HC11E variant with 8K onchip ROM memory
which was supposed to be disabled with ROMON bit . But it was not.
ROMON bit was enabled. So it was executing from internal memory. We just
disabled that and we could execute our test program in expanded mode
from external flash. Actually, this chip was custom part and was
supposed to have no internal ROM memory. That's where we got misleaded.
Anyway....
Thanks a lot again!!
Gauri
________________________________
From: m68HC11@m68H... [mailto:m68HC11@m68H...] On Behalf
Of Mike McCarty
Sent: Thursday, December 15, 2005 4:15 PM
To: m68HC11@m68H...
Subject: Re: [m68HC11] Help needed for 68HC11E processor external memory
interface
Mahajan, Gauri (IE03x) wrote: > Hello Mike,
>
> Yes , I mean no internal ROM. But internal RAM, Register memory and
> EEPROM are present and we have tried it with disabled EEPROM in our test > program. But no effect.
I would expect that disabling internal EEPROM at $B600-$B7FF would have
no effect, since you didn't report fetches from those addresses.
But it was reasonable to check.
> We are using logic analyzer for tapping the
address, data, E clock, AS , > CE, OE signals. The LA shows the 0xFFFE and 0xFFFF
addresses and their
> correct data (which we have stored in those locations) on screen. Even
Ok. Sounds like your FLASH is responding and driving the bus.
> for the addresses which it gives starting from
E000, the data is being
> fetched from memory and we could see it on bus on LA. So I said memory
> is being read properly. But we doubt if processor is taking data inside > or not. The /CE is output of a NAND and inputs to
NAND are A15 line
> shorted to both inputs which gived 0x8000 address. /OE is NAND output of > R/W and E clock.
Ok, so FLASH responds to addresses $8000-$FFFF. You also have qualified
R/W- with E (see below). This sounds correct to me.
> The internal RAM and register memory is at default
locations and we have > initialized the stack at 0x01FF.
Hmm. This sounds ok, if you really are using an E-series part. For the
A-series this would not work. One question... are you using some sort
of a monitor? I mean like BUFFALO? Or just hardware analyzers? If you
are using a monitor of some sort, then you might be getting interference
from it. (Probably not, since you didn't mention it, and you claim
not to have any ROM.)
> We are able to see the flash data on bus with LA
correctly with address. > So I thought that the FLASH is being read
properly.
Sounds like it.
> We are using AS line for the external latch for
latch enable signal and > its waveforms are OK. Does it mean that the
processor is in expanded
> mode?
If AS is toggling, then you are in expanded multiplex or special test
mode.
> About data and address lines, we have confirmed
the connections are
> right. We have reconfirmed it. I couldn't understand what you say about > qualifying a signal. Does it mean we have match
timing for it? We have
> done processor expanded mode and memory read timing verification.
> Anything else is needed to be done?
I meant doing exactly what you did. Since R/W- is not guaranteed to
change at any particular moment in time, it cannot be used as a
timing signal. So the state of R/W- must be further qualified by E,
which is what you are doing. You confirm that R/W- has a valid state
by checking (qualifying) with E.
I didn't think you had the address or data bus miswired, but
when the impossible is happening, it's always good to check
the impossible, you know what I mean?
This is a bit of a mystery.
Did you check the interrupt/trap vectors for matches with the
locations you are jumping to?
Did you check the actual absolute voltage levels on the data
bus when reading FLASH to ensure that they were within spec,
and not possibly overloaded? Is there any chip between the
FLASH and the uC on the data bus? I mean like a bus driver
chip like the 74HC244 or similar? You might not be reversing
the direction of the bus driver chip, or not enabling it,
or something.
Have you checked all signals to be within timing spec? This is
a bit of a stretch of the imagination, at these clock speeds,
but signal skew is always a possibility. I don't guess that
you have much capacitive loading, but are the signals nice
and "square" (IOW, how about rise/fall times)? How flat are the
tops? Too much noise? How about ground bounce? Did you check
for that? Is everything nicely bypassed close to the chips, and
not back through the ground plane?
Hey, I thought of something! How about the ROMON bit in CONFIG
at $103F? Even on the "no ROM" parts, there *is* a ROM, it's
just
disabled in CONFIG. If you have ROMON set, then you'll read
from internal ROM. The external accesses will look normal, but
the uC will ignore the external bus data, and read from the
internal resource. So you'd be executing whatever program
is there, probably belonging to another company who did an
upgrade of their firmware, and gave FreeScale permission to
sell the chips, and not your own program.
Also, check out the NOCOP bit while you're at it. In fact,
just what is in CONFIG?
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!
________________________________
> .
________________________________
Reply by BobG...@...●December 15, 20052005-12-15
In a message dated 12/15/05 12:20:11 A.M. Eastern Standard Time,
gauri.mahajan@gaur... writes:
I mean no internal ROM. But internal RAM,
=================================
I used to bring up external memory hc11 boards with several little programs
that would bootload into ram and perform a test, flash an led. These programs
run in internal ram, but can turn on external mem and test it. Its pretty
easy to write a mem fill with increasing data and read back, print back over
serial. You know how to write a bootable program? Need to cvt the ascii srecord
file to binary, then binary edit it to add an FF as the 1st byte to set the
baud rate.
Reply by Mike McCarty●December 15, 20052005-12-15
Mahajan, Gauri (IE03x) wrote: > Hello Mike,
>
> Yes , I mean no internal ROM. But internal RAM, Register memory and
> EEPROM are present and we have tried it with disabled EEPROM in our test
> program. But no effect.
I would expect that disabling internal EEPROM at $B600-$B7FF would have
no effect, since you didn't report fetches from those addresses.
But it was reasonable to check.
> We are using logic analyzer for tapping the
address, data, E clock, AS ,
> CE, OE signals. The LA shows the 0xFFFE and 0xFFFF addresses and their
> correct data (which we have stored in those locations) on screen. Even
Ok. Sounds like your FLASH is responding and driving the bus.
> for the addresses which it gives starting from
E000, the data is being
> fetched from memory and we could see it on bus on LA. So I said memory
> is being read properly. But we doubt if processor is taking data inside
> or not. The /CE is output of a NAND and inputs to NAND are A15 line
> shorted to both inputs which gived 0x8000 address. /OE is NAND output of
> R/W and E clock.
Ok, so FLASH responds to addresses $8000-$FFFF. You also have qualified
R/W- with E (see below). This sounds correct to me.
> The internal RAM and register memory is at default
locations and we have
> initialized the stack at 0x01FF.
Hmm. This sounds ok, if you really are using an E-series part. For the
A-series this would not work. One question... are you using some sort
of a monitor? I mean like BUFFALO? Or just hardware analyzers? If you
are using a monitor of some sort, then you might be getting interference
from it. (Probably not, since you didn't mention it, and you claim
not to have any ROM.)
> We are able to see the flash data on bus with LA
correctly with address.
> So I thought that the FLASH is being read properly.
Sounds like it.
> We are using AS line for the external latch for
latch enable signal and
> its waveforms are OK. Does it mean that the processor is in expanded
> mode?
If AS is toggling, then you are in expanded multiplex or special test
mode.
> About data and address lines, we have confirmed
the connections are
> right. We have reconfirmed it. I couldn't understand what you say
about
> qualifying a signal. Does it mean we have match timing for it? We have
> done processor expanded mode and memory read timing verification.
> Anything else is needed to be done?
I meant doing exactly what you did. Since R/W- is not guaranteed to
change at any particular moment in time, it cannot be used as a
timing signal. So the state of R/W- must be further qualified by E,
which is what you are doing. You confirm that R/W- has a valid state
by checking (qualifying) with E.
I didn't think you had the address or data bus miswired, but
when the impossible is happening, it's always good to check
the impossible, you know what I mean?
This is a bit of a mystery.
Did you check the interrupt/trap vectors for matches with the
locations you are jumping to?
Did you check the actual absolute voltage levels on the data
bus when reading FLASH to ensure that they were within spec,
and not possibly overloaded? Is there any chip between the
FLASH and the uC on the data bus? I mean like a bus driver
chip like the 74HC244 or similar? You might not be reversing
the direction of the bus driver chip, or not enabling it,
or something.
Have you checked all signals to be within timing spec? This is
a bit of a stretch of the imagination, at these clock speeds,
but signal skew is always a possibility. I don't guess that
you have much capacitive loading, but are the signals nice
and "square" (IOW, how about rise/fall times)? How flat are the
tops? Too much noise? How about ground bounce? Did you check
for that? Is everything nicely bypassed close to the chips, and
not back through the ground plane?
Hey, I thought of something! How about the ROMON bit in CONFIG
at $103F? Even on the "no ROM" parts, there *is* a ROM, it's
just
disabled in CONFIG. If you have ROMON set, then you'll read
from internal ROM. The external accesses will look normal, but
the uC will ignore the external bus data, and read from the
internal resource. So you'd be executing whatever program
is there, probably belonging to another company who did an
upgrade of their firmware, and gave FreeScale permission to
sell the chips, and not your own program.
Also, check out the NOCOP bit while you're at it. In fact,
just what is in CONFIG?
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!
Reply by Mahajan, Gauri \IE03x\●December 15, 20052005-12-15
Hello Mike,
Yes , I mean no internal ROM. But internal RAM, Register memory and
EEPROM are present and we have tried it with disabled EEPROM in our test
program. But no effect.
We are using logic analyzer for tapping the address, data, E clock, AS ,
CE, OE signals. The LA shows the 0xFFFE and 0xFFFF addresses and their
correct data (which we have stored in those locations) on screen. Even
for the addresses which it gives starting from E000, the data is being
fetched from memory and we could see it on bus on LA. So I said memory
is being read properly. But we doubt if processor is taking data inside
or not. The /CE is output of a NAND and inputs to NAND are A15 line
shorted to both inputs which gived 0x8000 address. /OE is NAND output of
R/W and E clock.
The internal RAM and register memory is at default locations and we have
initialized the stack at 0x01FF.
We are able to see the flash data on bus with LA correctly with address.
So I thought that the FLASH is being read properly.
We are using AS line for the external latch for latch enable signal and
its waveforms are OK. Does it mean that the processor is in expanded
mode?
About data and address lines, we have confirmed the connections are
right. We have reconfirmed it. I couldn't understand what you say about
qualifying a signal. Does it mean we have match timing for it? We have
done processor expanded mode and memory read timing verification.
Anything else is needed to be done?
Thank you!
Gauri
________________________________
From: m68HC11@m68H... [mailto:m68HC11@m68H...] On Behalf
Of Mike McCarty
Sent: Wednesday, December 14, 2005 11:00 PM
To: m68HC11@m68H...
Subject: Re: [m68HC11] Help needed for 68HC11E processor external memory
interface
gaurimahajan_21 wrote: > Hello,
>
> I need some help regarding the 68HC11E1 processor external memory
> interface. We are using the 614 KHz clock frequency and are using
> the processor custom chip which doesn't have internal program
I suppose you mean no ROM.
> memory. We have tied the MODA and MODB pins to VCC
thru pull-up
> resistors. The reset is thru external monitor chip.And we have
> interfaced flash as external memory at address above 0x8000. The
> flash interface is fine and the flash data is being read
> properly.The first problem is, even though we are giving the start
How do you know the FLASH is being read properly? IOW, please
define "read properly".
> address 8000H at FFFE and FFFF, after fetching
this address, the
> processor is somehow jumping to address E000H irrespective of what
> start address we are giving. Second problem is it reads data fine
> from addresses serially upto E004H starting from E000H. But then it
> jumps to address FFFFH, then to 100AH and then it returns to E005H
> where it has left main processing. This is happening after every few
> data read cycles of flash and the diversion addresses are
This sounds like it might be an interrupt or trap, like perhaps
Invalid Instruction. Try comparing the address you are jumping to
to the addresses in the Vector Table. You might get a match.
Also, what RAM are you using for your stack? If you are calling
subroutines, and you haven't set up a valid stack, then you can
"return" to arbitrary addresses. Does the address you have set
your SP to point to agree with where you put it using the
INIT register at $x03D? Have you moved your registers somewhere
else using INIT?
> repeated.Very surprisingly, the processor
doesn't seem to understand
> the data, as it is not taking any action on the instructions read.
Then what makes you think that the FLASH is being "read properly"?
> We really don't know if it is working in
external memory mode. Can
> anybody suggest how it could be confirmed? or What are the things in
> hardware and software (registers etc) which should be initialised to
> make processor work in expanded mode?
Look at the AS line. This line is STRA in unexpanded modes, which is
an input. If it's toggling, then it is being used as an output AS.
Some possible causes:
You have scrambled either the address or data lines to/from the
FLASH. IOW, the FLASH may be programmed properly, but the data
or address bits are mis-connected.
You are not using the E clock to qualify the /OE line on the FLASH.
(The R/W line is *not* a timing signal on Motorola parts, and must
be qualified, unless you are qualifying /CS or /CE whichever your
part has.)
You have overburdened one or more of your control, address, or
data bus lines. (This is somewhat of a stretch, I realize.)
You are using slow parts. (REALLY a stretch at these clock rates.)
You are asserting writes to the FLASH, and it is "going away".
(Seems very unlikely.)
I hope that while this may not have been very helpful, it has
sparked your imagination. One difficulty I have in circumstances
like this is not being sufficiently inventive in thinking of things
that are "wrong".
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!
SPONSORED LINKS
Reply by Jack Donoghue●December 14, 20052005-12-14
Robert Smith wrote:
>Hi Jack --
>
>This being a group that Mike McCarty lurks on please allow me to reply
>in "proper form" by "bottom posting"
>
>IOW, see below!
>
Got it, Bob. Thanks!
Jack Donoghue
jdsb@jdsb...
Reply by Robert Smith●December 14, 20052005-12-14
Hi Jack --
This being a group that Mike McCarty lurks on please allow me to reply
in "proper form" by "bottom posting"
IOW, see below!
----- Original Message -----
From: "Jack Donoghue" <jdsb@jdsb...>
To: <m68HC11@m68H...>
Sent: Wednesday, December 14, 2005 11:11 AM
Subject: Re: [m68HC11] Help needed for 68HC11E processor external memory
interface
> Robert Smith wrote:
>
> >Dear Gauri --
> >
> >A very common problem when trying to get a new system running in
> >stand-alone mode the first time is to overlook the requirement to either > >disable, or service the watchdog correctly.
> >
> >Make certain to attend to the watchdog so it is knocking your system out > >of the program during startup. See the
MC68HC11 "White Book" for
> >details.
> >
> > Best wishes, Bob Smith
> >
>
> Hi Bob.
>
> Perhaps I missed something (it wouldn't be the first - or the billionth! > time). What is the "WHITE" book? I know
the "PINK" book. Have I missed
> something?
>
> We did this thing at my company once, and it worked. I don't recall
> using a white book. I want to stay on top of things like this.
>
> Thanks for reading my E-mail.
>
> Jack Donoghue
> jdsb@jdsb...
> SPONSORED LINKS Freescale semiconductor inc Microcontrollers Pic microcontrollers > 8051 microprocessor
>
Hi Jack --
The "White Book" (my name for it, no one else's) is the
up-to-date
revision of the old Pink Book. Its Motorola part number is M68HC11RM/D,
Rev 6, 4/2002. It is bit fatter that the Pink Book and contains a
number of revisions. You can surely order a no charge copy from the web
site.
Best wishes,
Bob Smith
Reply by Mike McCarty●December 14, 20052005-12-14
gaurimahajan_21 wrote: > Hello,
>
> I need some help regarding the 68HC11E1 processor external memory
> interface. We are using the 614 KHz clock frequency and are using
> the processor custom chip which doesn't have internal program
I suppose you mean no ROM.
> memory. We have tied the MODA and MODB pins to VCC
thru pull-up
> resistors. The reset is thru external monitor chip.And we have
> interfaced flash as external memory at address above 0x8000. The
> flash interface is fine and the flash data is being read
> properly.The first problem is, even though we are giving the start
How do you know the FLASH is being read properly? IOW, please
define "read properly".
> address 8000H at FFFE and FFFF, after fetching
this address, the
> processor is somehow jumping to address E000H irrespective of what
> start address we are giving. Second problem is it reads data fine
> from addresses serially upto E004H starting from E000H. But then it
> jumps to address FFFFH, then to 100AH and then it returns to E005H
> where it has left main processing. This is happening after every few
> data read cycles of flash and the diversion addresses are
This sounds like it might be an interrupt or trap, like perhaps
Invalid Instruction. Try comparing the address you are jumping to
to the addresses in the Vector Table. You might get a match.
Also, what RAM are you using for your stack? If you are calling
subroutines, and you haven't set up a valid stack, then you can
"return" to arbitrary addresses. Does the address you have set
your SP to point to agree with where you put it using the
INIT register at $x03D? Have you moved your registers somewhere
else using INIT?
> repeated.Very surprisingly, the processor
doesn't seem to understand
> the data, as it is not taking any action on the instructions read.
Then what makes you think that the FLASH is being "read properly"?
> We really don't know if it is working in
external memory mode. Can
> anybody suggest how it could be confirmed? or What are the things in
> hardware and software (registers etc) which should be initialised to
> make processor work in expanded mode?
Look at the AS line. This line is STRA in unexpanded modes, which is
an input. If it's toggling, then it is being used as an output AS.
Some possible causes:
You have scrambled either the address or data lines to/from the
FLASH. IOW, the FLASH may be programmed properly, but the data
or address bits are mis-connected.
You are not using the E clock to qualify the /OE line on the FLASH.
(The R/W line is *not* a timing signal on Motorola parts, and must
be qualified, unless you are qualifying /CS or /CE whichever your
part has.)
You have overburdened one or more of your control, address, or
data bus lines. (This is somewhat of a stretch, I realize.)
You are using slow parts. (REALLY a stretch at these clock rates.)
You are asserting writes to the FLASH, and it is "going away".
(Seems very unlikely.)
I hope that while this may not have been very helpful, it has
sparked your imagination. One difficulty I have in circumstances
like this is not being sufficiently inventive in thinking of things
that are "wrong".
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!
Reply by Jack Donoghue●December 14, 20052005-12-14
Robert Smith wrote:
>Dear Gauri --
>
>A very common problem when trying to get a new system running in
>stand-alone mode the first time is to overlook the requirement to either
>disable, or service the watchdog correctly.
>
>Make certain to attend to the watchdog so it is knocking your system out
>of the program during startup. See the MC68HC11 "White Book"
for
>details.
>
> Best wishes, Bob Smith
>
Hi Bob.
Perhaps I missed something (it wouldn't be the first - or the billionth!
time). What is the "WHITE" book? I know the "PINK" book.
Have I missed
something?
We did this thing at my company once, and it worked. I don't recall
using a white book. I want to stay on top of things like this.
Thanks for reading my E-mail.
Jack Donoghue
jdsb@jdsb...
Reply by Robert Smith●December 14, 20052005-12-14
Dear Gauri --
A very common problem when trying to get a new system running in
stand-alone mode the first time is to overlook the requirement to either
disable, or service the watchdog correctly.
Make certain to attend to the watchdog so it is knocking your system out
of the program during startup. See the MC68HC11 "White Book" for
details.
Best wishes, Bob Smith
----- Original Message -----
From: "gaurimahajan_21" <gauri.mahajan@gaur...>
To: <m68HC11@m68H...>
Sent: Tuesday, December 13, 2005 11:59 PM
Subject: [m68HC11] Help needed for 68HC11E processor external memory
interface
> Hello,
>
> I need some help regarding the 68HC11E1 processor external memory
> interface. We are using the 614 KHz clock frequency and are using
> the processor custom chip which doesn't have internal program
> memory. We have tied the MODA and MODB pins to VCC thru pull-up
> resistors. The reset is thru external monitor chip.And we have
> interfaced flash as external memory at address above 0x8000. The
> flash interface is fine and the flash data is being read
> properly.The first problem is, even though we are giving the start
> address 8000H at FFFE and FFFF, after fetching this address, the
> processor is somehow jumping to address E000H irrespective of what
> start address we are giving. Second problem is it reads data fine
> from addresses serially upto E004H starting from E000H. But then it
> jumps to address FFFFH, then to 100AH and then it returns to E005H
> where it has left main processing. This is happening after every few
> data read cycles of flash and the diversion addresses are
> repeated.Very surprisingly, the processor doesn't seem to
understand
> the data, as it is not taking any action on the instructions read.
> We really don't know if it is working in external memory mode. Can
> anybody suggest how it could be confirmed? or What are the things in
> hardware and software (registers etc) which should be initialised to
> make processor work in expanded mode?
>
> Thank you!
> ---------------------------------- ---------- > YAHOO! GROUPS LINKS
>
> a..
> ---------------------------------- ---------- >
>