I think I figured out the problem. The bootloader
code runs from RAM and uses the INITRM register to
overlay the flash bootblock with RAM. Apparently,
a COP reset will not make INITRM revert to its
default value. Only a hard reset will ?? I can't
find this documented anywhere. It was my
understanding that a COP reset would have the same
effect as a hard reset - but it appears it doesn't.
Jeff
Jeff McKnight wrote:
> >
> >
> > --- In 6...
'
Reading FLASH after programming
Started by ●July 25, 2007
Reply by ●August 6, 20072007-08-06
Reply by ●August 6, 20072007-08-06
Jeff,
No, COP reset should reset almost everything. The exception should be just a
couple of reset source related bits like PORF. I hardly believe you are
facing INITRM refusing to reset on COP.
Could it be that on COP your part selects not COP vector but vector at FFFE?
Do you have big enough capacitor on /RESET pin or some odd reset chip with
pushbutton similar to DS1813? If so then COP vector could be defeated. Check
CRG block docs, (if CRGv4 then) chapter 5.2 Description of Reset Operation.
On COP reset chip pulls /RESET low, then releases it and samples after
64cycles to see if it can use COP vector (internal one) or not. Too big cap
can make part using always FFFE vector.
Regards
Edward
----- Original Message -----
From: "Jeff McKnight"
To: <6...>
Sent: Monday, August 06, 2007 19:51
Subject: Re: [68HC12] Re: Reading FLASH after programming
>I think I figured out the problem. The bootloader
> code runs from RAM and uses the INITRM register to
> overlay the flash bootblock with RAM. Apparently,
> a COP reset will not make INITRM revert to its
> default value. Only a hard reset will ?? I can't
> find this documented anywhere. It was my
> understanding that a COP reset would have the same
> effect as a hard reset - but it appears it doesn't.
>
> Jeff
> Jeff McKnight wrote:
>> >
>> >
>> > --- In 6...
'
No, COP reset should reset almost everything. The exception should be just a
couple of reset source related bits like PORF. I hardly believe you are
facing INITRM refusing to reset on COP.
Could it be that on COP your part selects not COP vector but vector at FFFE?
Do you have big enough capacitor on /RESET pin or some odd reset chip with
pushbutton similar to DS1813? If so then COP vector could be defeated. Check
CRG block docs, (if CRGv4 then) chapter 5.2 Description of Reset Operation.
On COP reset chip pulls /RESET low, then releases it and samples after
64cycles to see if it can use COP vector (internal one) or not. Too big cap
can make part using always FFFE vector.
Regards
Edward
----- Original Message -----
From: "Jeff McKnight"
To: <6...>
Sent: Monday, August 06, 2007 19:51
Subject: Re: [68HC12] Re: Reading FLASH after programming
>I think I figured out the problem. The bootloader
> code runs from RAM and uses the INITRM register to
> overlay the flash bootblock with RAM. Apparently,
> a COP reset will not make INITRM revert to its
> default value. Only a hard reset will ?? I can't
> find this documented anywhere. It was my
> understanding that a COP reset would have the same
> effect as a hard reset - but it appears it doesn't.
>
> Jeff
> Jeff McKnight wrote:
>> >
>> >
>> > --- In 6...
'
Reply by ●August 7, 20072007-08-07
--- In 6..., "Edward Karpicz" wrote:
>
> Jeff,
>
> No, COP reset should reset almost everything. The exception should
> be just a couple of reset source related bits like PORF. I hardly
> believe you are facing INITRM refusing to reset on COP.
I don't believe either that it has to do with COP and INITRM, but I
think we are losing sight of the actual problem.
What does INITRM have to do with whether or not the Flash can be read
after programming, before a reset?
I will modify my simple example, and then will be convinced whether or
not the bootloader is just leaving registers in a bad state. I
apologize for being uncomfortable with this illogical method of
troubleshooting, where people are simply guessing solutions without
finding what the problem is.
>
> Jeff,
>
> No, COP reset should reset almost everything. The exception should
> be just a couple of reset source related bits like PORF. I hardly
> believe you are facing INITRM refusing to reset on COP.
I don't believe either that it has to do with COP and INITRM, but I
think we are losing sight of the actual problem.
What does INITRM have to do with whether or not the Flash can be read
after programming, before a reset?
I will modify my simple example, and then will be convinced whether or
not the bootloader is just leaving registers in a bad state. I
apologize for being uncomfortable with this illogical method of
troubleshooting, where people are simply guessing solutions without
finding what the problem is.
Reply by ●August 7, 20072007-08-07
--- In 6..., "Edward Karpicz" wrote:
>
> Jeff,
>
> No, COP reset should reset almost everything. The exception should
> be just a couple of reset source related bits like PORF. I
> hardly believe you are facing INITRM refusing to reset on COP.
Concerning the question why INITRM might be related:
Perhaps the difference is that you are making it "work" by writing to
INITRM after the COP reset? I didn't think I missed anything in the
conversation, but I did not see if you've done anything that makes it
work.
My thought was that maybe you just need a certain delay (even a few
cycles) before trying to verify the new Flash contents. Have you tried
that?
If you are now troubleshooting because the COP reset loses control
(runaway CPU), then where is the COP vector pointing... into RAM? What
are the specific steps taken when attempting to relocate this RAM in
that case?
>
> Jeff,
>
> No, COP reset should reset almost everything. The exception should
> be just a couple of reset source related bits like PORF. I
> hardly believe you are facing INITRM refusing to reset on COP.
Concerning the question why INITRM might be related:
Perhaps the difference is that you are making it "work" by writing to
INITRM after the COP reset? I didn't think I missed anything in the
conversation, but I did not see if you've done anything that makes it
work.
My thought was that maybe you just need a certain delay (even a few
cycles) before trying to verify the new Flash contents. Have you tried
that?
If you are now troubleshooting because the COP reset loses control
(runaway CPU), then where is the COP vector pointing... into RAM? What
are the specific steps taken when attempting to relocate this RAM in
that case?
Reply by ●August 7, 20072007-08-07
--- In 6..., Jeff McKnight wrote:
>
> Hello All,
> I am using the 9s12DG256. After I have successfully programmed Flash
> using a bootloader I try to read some of the memory locations.
> They do not show the correct value until I do a hard reset with the
> reset pin. Is this to be expected ? Jeff
>
That example that I uploaded (ee.asm) will work well to test your
device's ability to read Flash right after it is programmed. Use your
debugger for testing, and check the written word which is loaded into
accumulator D when the example completes.
To make it work for Flash, on the latest rev I uploaded, I only
changed two equates:
RBASE equ $100 (instead of $110)
ADDR equ $FFFE (or whatever address in Flash)
I proved writing Flash using MC9S12D32. I wrote $400 to $FFFE, and
then erased and rewrote.
WARNING:
This example automatically erases the containing SECTOR of the word to
program, if that word is not erased (all bits '1'). As a result,
erasing the sector of $FFFE also erased $FF0F, which secured my
device. Be prepared to unsecure it (normally by erasing all Flash) if
this happens.
>
> Hello All,
> I am using the 9s12DG256. After I have successfully programmed Flash
> using a bootloader I try to read some of the memory locations.
> They do not show the correct value until I do a hard reset with the
> reset pin. Is this to be expected ? Jeff
>
That example that I uploaded (ee.asm) will work well to test your
device's ability to read Flash right after it is programmed. Use your
debugger for testing, and check the written word which is loaded into
accumulator D when the example completes.
To make it work for Flash, on the latest rev I uploaded, I only
changed two equates:
RBASE equ $100 (instead of $110)
ADDR equ $FFFE (or whatever address in Flash)
I proved writing Flash using MC9S12D32. I wrote $400 to $FFFE, and
then erased and rewrote.
WARNING:
This example automatically erases the containing SECTOR of the word to
program, if that word is not erased (all bits '1'). As a result,
erasing the sector of $FFFE also erased $FF0F, which secured my
device. Be prepared to unsecure it (normally by erasing all Flash) if
this happens.
Reply by ●August 8, 20072007-08-08
Jeff Smith wrote:
>
> My thought was that maybe you just need a certain delay (even a few
> cycles) before trying to verify the new Flash contents. Have you tried
> that?
>
No. Jeff M wrote in one of messages that he waits for CCIF set. => no delays
are necessary.
> If you are now troubleshooting because the COP reset loses control
> (runaway CPU), then where is the COP vector pointing... into RAM? What
> are the specific steps taken when attempting to relocate this RAM in
> that case?
>
Don't know what to answer to this, request not understood, sorry. Why are
you so complicating the things. Jeff M said he thinks it's INITRM not reset.
I said what I think, primarily about INITRM. Maybe let Jeff M say if my
guess was applicable or not? Would be simple and would save your and my
time.
Regards
Edward
>
> My thought was that maybe you just need a certain delay (even a few
> cycles) before trying to verify the new Flash contents. Have you tried
> that?
>
No. Jeff M wrote in one of messages that he waits for CCIF set. => no delays
are necessary.
> If you are now troubleshooting because the COP reset loses control
> (runaway CPU), then where is the COP vector pointing... into RAM? What
> are the specific steps taken when attempting to relocate this RAM in
> that case?
>
Don't know what to answer to this, request not understood, sorry. Why are
you so complicating the things. Jeff M said he thinks it's INITRM not reset.
I said what I think, primarily about INITRM. Maybe let Jeff M say if my
guess was applicable or not? Would be simple and would save your and my
time.
Regards
Edward
Reply by ●August 8, 20072007-08-08
Jeff Smith wrote:
> --- In 6..., "Edward Karpicz" wrote:
>>
>> Jeff,
>>
>> No, COP reset should reset almost everything. The exception should
>> be just a couple of reset source related bits like PORF. I hardly
>> believe you are facing INITRM refusing to reset on COP.
>
> I don't believe either that it has to do with COP and INITRM, but I
> think we are losing sight of the actual problem.
>
> What does INITRM have to do with whether or not the Flash can be read
> after programming, before a reset?
You should ask Jeff M about this, not me.
I was wondering how did he notice (and I believe wrongly assumed) that
INITRM seems to be not reset. Since he is copying bootloaders code to RAM
and remapping then RAM to vector area, also !using COP reset to start user
application! I thought maybe he just defeated COP vector with large cap or
something on /RESET line. BTW this could explain why he *seemd to be unable
to read what he wrote to flash*. Wrong reset vector - wrong result.
Assumptions could leed to dead end. But that's only guess.
>
> I will modify my simple example, and then will be convinced whether or
> not the bootloader is just leaving registers in a bad state. I
> apologize for being uncomfortable with this illogical method of
> troubleshooting, where people are simply guessing solutions without
> finding what the problem is.
>
Yeah, illogical method.
Edward
> --- In 6..., "Edward Karpicz" wrote:
>>
>> Jeff,
>>
>> No, COP reset should reset almost everything. The exception should
>> be just a couple of reset source related bits like PORF. I hardly
>> believe you are facing INITRM refusing to reset on COP.
>
> I don't believe either that it has to do with COP and INITRM, but I
> think we are losing sight of the actual problem.
>
> What does INITRM have to do with whether or not the Flash can be read
> after programming, before a reset?
You should ask Jeff M about this, not me.
I was wondering how did he notice (and I believe wrongly assumed) that
INITRM seems to be not reset. Since he is copying bootloaders code to RAM
and remapping then RAM to vector area, also !using COP reset to start user
application! I thought maybe he just defeated COP vector with large cap or
something on /RESET line. BTW this could explain why he *seemd to be unable
to read what he wrote to flash*. Wrong reset vector - wrong result.
Assumptions could leed to dead end. But that's only guess.
>
> I will modify my simple example, and then will be convinced whether or
> not the bootloader is just leaving registers in a bad state. I
> apologize for being uncomfortable with this illogical method of
> troubleshooting, where people are simply guessing solutions without
> finding what the problem is.
>
Yeah, illogical method.
Edward
Reply by ●August 8, 20072007-08-08
OK - sorry if there has been some confusion.
Previously I said that INITRM was not getting
reset out of a COP reset. It appears now that
this was an incorrect statement. I don't think it
was "illogical" - just a mistake. It is difficult
to debug because when the MCU resets, the NoICE
debugger loses communications.
This is the problem that I still can't figure out :
I am using the 9S12DG256. I am using the
bootloader from Motorola AN2153. I am using it
with very little modification. It works - and has
worked for me - for several years. The reset
vector points to the bootloader. The first thing
the bootloader does is look at the last byte of
the secondary interrupt vector table in the user
application code area ($efff). If the byte is
programmed (indicating valid code) - it jumps to
the start of the code. If it is not programmed -
it continues running the bootloader. So - after
the user code is programmed - a power cycle is
required to make it jump to the user code.
Again - this all has worked for several years. I
came across this problem when I decided I wanted
to make the bootloader automatically jump to the
user code after the Flash was programmed - without
power cycling. I thought this would be easy to
just force a COP reset after the Flash was
programmed. When I do this - what happens is the
bootloader doesn't read the correct value at $efff
after the COP reset so it just runs the bootloader
again. Note - the MCU doesn't "runaway" it just
doesn't read the expected value at $efff so it
just continues on in the bootloader instead of
jumping to the application code. But I know the
Flash has been programmed because if I just do a
power cycle - it correctly jumps to the
application code and works fine. This is why I
say it SEEMS there is some difference between a
COP reset and a hard reset.
Also if I put a breakpoint immediately after the
Flash is programmed - and then refresh and read
the memory in NoICE, I do NOT see the correct
values. But, as soon as I do a reset with NoICE,
I see the correct values. I don't know if this is
related to the problem - or just a quirk of NoICE.
Thanks to all who have commented. Sorry again for
the confusion.
Jeff M.
Edward Karpicz wrote:
> Jeff Smith wrote:
>
> >
> > My thought was that maybe you just need a certain delay (even a few
> > cycles) before trying to verify the new Flash contents. Have you tried
> > that?
> > No. Jeff M wrote in one of messages that he waits for CCIF set. => no
> delays
> are necessary.
>
> > If you are now troubleshooting because the COP reset loses control
> > (runaway CPU), then where is the COP vector pointing... into RAM? What
> > are the specific steps taken when attempting to relocate this RAM in
> > that case?
> > Don't know what to answer to this, request not understood, sorry. Why are
> you so complicating the things. Jeff M said he thinks it's INITRM not
> reset.
> I said what I think, primarily about INITRM. Maybe let Jeff M say if my
> guess was applicable or not? Would be simple and would save your and my
> time.
>
> Regards
> Edward
>
Previously I said that INITRM was not getting
reset out of a COP reset. It appears now that
this was an incorrect statement. I don't think it
was "illogical" - just a mistake. It is difficult
to debug because when the MCU resets, the NoICE
debugger loses communications.
This is the problem that I still can't figure out :
I am using the 9S12DG256. I am using the
bootloader from Motorola AN2153. I am using it
with very little modification. It works - and has
worked for me - for several years. The reset
vector points to the bootloader. The first thing
the bootloader does is look at the last byte of
the secondary interrupt vector table in the user
application code area ($efff). If the byte is
programmed (indicating valid code) - it jumps to
the start of the code. If it is not programmed -
it continues running the bootloader. So - after
the user code is programmed - a power cycle is
required to make it jump to the user code.
Again - this all has worked for several years. I
came across this problem when I decided I wanted
to make the bootloader automatically jump to the
user code after the Flash was programmed - without
power cycling. I thought this would be easy to
just force a COP reset after the Flash was
programmed. When I do this - what happens is the
bootloader doesn't read the correct value at $efff
after the COP reset so it just runs the bootloader
again. Note - the MCU doesn't "runaway" it just
doesn't read the expected value at $efff so it
just continues on in the bootloader instead of
jumping to the application code. But I know the
Flash has been programmed because if I just do a
power cycle - it correctly jumps to the
application code and works fine. This is why I
say it SEEMS there is some difference between a
COP reset and a hard reset.
Also if I put a breakpoint immediately after the
Flash is programmed - and then refresh and read
the memory in NoICE, I do NOT see the correct
values. But, as soon as I do a reset with NoICE,
I see the correct values. I don't know if this is
related to the problem - or just a quirk of NoICE.
Thanks to all who have commented. Sorry again for
the confusion.
Jeff M.
Edward Karpicz wrote:
> Jeff Smith wrote:
>
> >
> > My thought was that maybe you just need a certain delay (even a few
> > cycles) before trying to verify the new Flash contents. Have you tried
> > that?
> > No. Jeff M wrote in one of messages that he waits for CCIF set. => no
> delays
> are necessary.
>
> > If you are now troubleshooting because the COP reset loses control
> > (runaway CPU), then where is the COP vector pointing... into RAM? What
> > are the specific steps taken when attempting to relocate this RAM in
> > that case?
> > Don't know what to answer to this, request not understood, sorry. Why are
> you so complicating the things. Jeff M said he thinks it's INITRM not
> reset.
> I said what I think, primarily about INITRM. Maybe let Jeff M say if my
> guess was applicable or not? Would be simple and would save your and my
> time.
>
> Regards
> Edward
>
Reply by ●August 8, 20072007-08-08
--- In 6..., "Edward Karpicz" wrote:
>
> Jeff Smith wrote:
[...]
> > What does INITRM have to do with whether or not the Flash can
> > be read after programming, before a reset?
>
> You should ask Jeff M about this, not me.
Don't worry, I'm with you on that one. That is why I posted to the
group (but I thought in context, things I would say are most relevant
to your post so I replied to yours, and asked the question for anyone
including Jeff M who might know what INITRM could affect).
>
> Jeff Smith wrote:
[...]
> > What does INITRM have to do with whether or not the Flash can
> > be read after programming, before a reset?
>
> You should ask Jeff M about this, not me.
Don't worry, I'm with you on that one. That is why I posted to the
group (but I thought in context, things I would say are most relevant
to your post so I replied to yours, and asked the question for anyone
including Jeff M who might know what INITRM could affect).
Reply by ●August 8, 20072007-08-08
DG256 has more than 4k of RAM (F000..FFFF). Remapping so big RAM to vector
area makes RAM overlapping flash far below than EFFE.
With remapped to vectors RAM, bootloader must flashing locations near EFFE
setting PPAGE to $3F and programming flash in the page window. So without
reset and with RAM in vector area you should not check if $EFFE:$EFFF is
programmed but set PPAGE to $3F and check if $AFFE:$AFFF is programmed.
Regards
Edward
----- Original Message -----
From: "Jeff McKnight"
To: <6...>
Sent: Wednesday, August 08, 2007 18:05
Subject: Re: [68HC12] Re: Reading FLASH after programming
> OK - sorry if there has been some confusion.
> Previously I said that INITRM was not getting
> reset out of a COP reset. It appears now that
> this was an incorrect statement. I don't think it
> was "illogical" - just a mistake. It is difficult
> to debug because when the MCU resets, the NoICE
> debugger loses communications.
>
> This is the problem that I still can't figure out :
>
> I am using the 9S12DG256. I am using the
> bootloader from Motorola AN2153. I am using it
> with very little modification. It works - and has
> worked for me - for several years. The reset
> vector points to the bootloader. The first thing
> the bootloader does is look at the last byte of
> the secondary interrupt vector table in the user
> application code area ($efff). If the byte is
> programmed (indicating valid code) - it jumps to
> the start of the code. If it is not programmed -
> it continues running the bootloader. So - after
> the user code is programmed - a power cycle is
> required to make it jump to the user code.
>
> Again - this all has worked for several years. I
> came across this problem when I decided I wanted
> to make the bootloader automatically jump to the
> user code after the Flash was programmed - without
> power cycling. I thought this would be easy to
> just force a COP reset after the Flash was
> programmed. When I do this - what happens is the
> bootloader doesn't read the correct value at $efff
> after the COP reset so it just runs the bootloader
> again. Note - the MCU doesn't "runaway" it just
> doesn't read the expected value at $efff so it
> just continues on in the bootloader instead of
> jumping to the application code. But I know the
> Flash has been programmed because if I just do a
> power cycle - it correctly jumps to the
> application code and works fine. This is why I
> say it SEEMS there is some difference between a
> COP reset and a hard reset.
>
> Also if I put a breakpoint immediately after the
> Flash is programmed - and then refresh and read
> the memory in NoICE, I do NOT see the correct
> values. But, as soon as I do a reset with NoICE,
> I see the correct values. I don't know if this is
> related to the problem - or just a quirk of NoICE.
>
> Thanks to all who have commented. Sorry again for
> the confusion.
> Jeff M.
> Edward Karpicz wrote:
>> Jeff Smith wrote:
>>
>>
>>
>> >
>> > My thought was that maybe you just need a certain delay (even a few
>> > cycles) before trying to verify the new Flash contents. Have you tried
>> > that?
>> >
>>
>> No. Jeff M wrote in one of messages that he waits for CCIF set. => no
>> delays
>> are necessary.
>>
>> > If you are now troubleshooting because the COP reset loses control
>> > (runaway CPU), then where is the COP vector pointing... into RAM? What
>> > are the specific steps taken when attempting to relocate this RAM in
>> > that case?
>> >
>>
>> Don't know what to answer to this, request not understood, sorry. Why are
>> you so complicating the things. Jeff M said he thinks it's INITRM not
>> reset.
>> I said what I think, primarily about INITRM. Maybe let Jeff M say if my
>> guess was applicable or not? Would be simple and would save your and my
>> time.
>>
>> Regards
>> Edward
>> Yahoo! Groups Links
area makes RAM overlapping flash far below than EFFE.
With remapped to vectors RAM, bootloader must flashing locations near EFFE
setting PPAGE to $3F and programming flash in the page window. So without
reset and with RAM in vector area you should not check if $EFFE:$EFFF is
programmed but set PPAGE to $3F and check if $AFFE:$AFFF is programmed.
Regards
Edward
----- Original Message -----
From: "Jeff McKnight"
To: <6...>
Sent: Wednesday, August 08, 2007 18:05
Subject: Re: [68HC12] Re: Reading FLASH after programming
> OK - sorry if there has been some confusion.
> Previously I said that INITRM was not getting
> reset out of a COP reset. It appears now that
> this was an incorrect statement. I don't think it
> was "illogical" - just a mistake. It is difficult
> to debug because when the MCU resets, the NoICE
> debugger loses communications.
>
> This is the problem that I still can't figure out :
>
> I am using the 9S12DG256. I am using the
> bootloader from Motorola AN2153. I am using it
> with very little modification. It works - and has
> worked for me - for several years. The reset
> vector points to the bootloader. The first thing
> the bootloader does is look at the last byte of
> the secondary interrupt vector table in the user
> application code area ($efff). If the byte is
> programmed (indicating valid code) - it jumps to
> the start of the code. If it is not programmed -
> it continues running the bootloader. So - after
> the user code is programmed - a power cycle is
> required to make it jump to the user code.
>
> Again - this all has worked for several years. I
> came across this problem when I decided I wanted
> to make the bootloader automatically jump to the
> user code after the Flash was programmed - without
> power cycling. I thought this would be easy to
> just force a COP reset after the Flash was
> programmed. When I do this - what happens is the
> bootloader doesn't read the correct value at $efff
> after the COP reset so it just runs the bootloader
> again. Note - the MCU doesn't "runaway" it just
> doesn't read the expected value at $efff so it
> just continues on in the bootloader instead of
> jumping to the application code. But I know the
> Flash has been programmed because if I just do a
> power cycle - it correctly jumps to the
> application code and works fine. This is why I
> say it SEEMS there is some difference between a
> COP reset and a hard reset.
>
> Also if I put a breakpoint immediately after the
> Flash is programmed - and then refresh and read
> the memory in NoICE, I do NOT see the correct
> values. But, as soon as I do a reset with NoICE,
> I see the correct values. I don't know if this is
> related to the problem - or just a quirk of NoICE.
>
> Thanks to all who have commented. Sorry again for
> the confusion.
> Jeff M.
> Edward Karpicz wrote:
>> Jeff Smith wrote:
>>
>>
>>
>> >
>> > My thought was that maybe you just need a certain delay (even a few
>> > cycles) before trying to verify the new Flash contents. Have you tried
>> > that?
>> >
>>
>> No. Jeff M wrote in one of messages that he waits for CCIF set. => no
>> delays
>> are necessary.
>>
>> > If you are now troubleshooting because the COP reset loses control
>> > (runaway CPU), then where is the COP vector pointing... into RAM? What
>> > are the specific steps taken when attempting to relocate this RAM in
>> > that case?
>> >
>>
>> Don't know what to answer to this, request not understood, sorry. Why are
>> you so complicating the things. Jeff M said he thinks it's INITRM not
>> reset.
>> I said what I think, primarily about INITRM. Maybe let Jeff M say if my
>> guess was applicable or not? Would be simple and would save your and my
>> time.
>>
>> Regards
>> Edward
>> Yahoo! Groups Links
