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
Reading FLASH after programming
Started by ●July 25, 2007
Reply by ●July 25, 20072007-07-25
When you are done programming, what do you leave in the ppage register?
Dave
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
>
Dave
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
>
Reply by ●July 25, 20072007-07-25
--- 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
>
What are you trying to read flash with (your code or a BDM tool)? I
can't really answer your question, but you might get more help with
that info.
What I can offer is a suggestion that would also remedy your situation.
When the bootloader is done programming flash, I would cause a reset
(with the COP wdog or other means). This will clear any flash settings
that might allow flash to be unintentially written but also clears all
other register settings in case your new application needs to set any
of the write-once registers to a new value.
>
> 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
>
What are you trying to read flash with (your code or a BDM tool)? I
can't really answer your question, but you might get more help with
that info.
What I can offer is a suggestion that would also remedy your situation.
When the bootloader is done programming flash, I would cause a reset
(with the COP wdog or other means). This will clear any flash settings
that might allow flash to be unintentially written but also clears all
other register settings in case your new application needs to set any
of the write-once registers to a new value.
Reply by ●July 25, 20072007-07-25
Dr. David A. Perreault wrote:
> When you are done programming, what do you leave in the ppage register?
$3F. And I am trying to read from $EFFF
>
> Dave
>
> 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
> >
> >
> >
> When you are done programming, what do you leave in the ppage register?
$3F. And I am trying to read from $EFFF
>
> Dave
>
> 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
> >
> >
> >
Reply by ●July 25, 20072007-07-25
> --- 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
> > What are you trying to read flash with (your code or a BDM tool)? I
> can't really answer your question, but you might get more help with
> that info.
Both. My code does not read the correct value and this is also what
appears in my BDM tool (NoICE). In the code, right after the Flash was
programmed I try to read from the Flash. I set a breakpoint here and
the value that is read is not what I expected. I use NoICE to read the
same memory and it also confirms that the value is not as expected. If
I then use NoICE to reset the processor and then read the memory, It
shows what I expect it to show.
>
> What I can offer is a suggestion that would also remedy your situation.
> When the bootloader is done programming flash, I would cause a reset
> (with the COP wdog or other means).
This is exactly what I wanted to do. I am trying to get the application
code to start as soon as it has been programmed. So I force a COP reset
with the COP vector pointing to the bootloader.
The first thing the bootloader does is read from a memory location where
the application code should be. If it finds what it expected, it jumps
to the application code, if not, it stays in the bootloader.
What is happening is, after the COP reset, the bootloader does not read
the expected value in Flash. But I know it is there because if I do a
hard reset - either with the reset pin or power cycle - it correctly
jumps to the application code.
I am using the bootloader based on AN2153. It works fine and has worked
for me for a long time. I only have a problem when I tried to add this
new feature. (Previously I always made the user power cycle the device
after a firmware update).
This will clear any flash settings
> that might allow flash to be unintentially written but also clears all
> other register settings in case your new application needs to set any
> of the write-once registers to a new value.
>
> 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
> > What are you trying to read flash with (your code or a BDM tool)? I
> can't really answer your question, but you might get more help with
> that info.
Both. My code does not read the correct value and this is also what
appears in my BDM tool (NoICE). In the code, right after the Flash was
programmed I try to read from the Flash. I set a breakpoint here and
the value that is read is not what I expected. I use NoICE to read the
same memory and it also confirms that the value is not as expected. If
I then use NoICE to reset the processor and then read the memory, It
shows what I expect it to show.
>
> What I can offer is a suggestion that would also remedy your situation.
> When the bootloader is done programming flash, I would cause a reset
> (with the COP wdog or other means).
This is exactly what I wanted to do. I am trying to get the application
code to start as soon as it has been programmed. So I force a COP reset
with the COP vector pointing to the bootloader.
The first thing the bootloader does is read from a memory location where
the application code should be. If it finds what it expected, it jumps
to the application code, if not, it stays in the bootloader.
What is happening is, after the COP reset, the bootloader does not read
the expected value in Flash. But I know it is there because if I do a
hard reset - either with the reset pin or power cycle - it correctly
jumps to the application code.
I am using the bootloader based on AN2153. It works fine and has worked
for me for a long time. I only have a problem when I tried to add this
new feature. (Previously I always made the user power cycle the device
after a firmware update).
This will clear any flash settings
> that might allow flash to be unintentially written but also clears all
> other register settings in case your new application needs to set any
> of the write-once registers to a new value.
>
Reply by ●July 25, 20072007-07-25
--- In 6..., Jeff McKnight wrote:
> Both. My code does not read the correct value and this is also what
> appears in my BDM tool (NoICE). In the code, right after the Flash
> was programmed I try to read from the Flash. I set a breakpoint
> here and the value that is read is not what I expected. I use
> NoICE to read the same memory and it also confirms that the value
> is not as expected. If I then use NoICE to reset the processor
> and then read the memory, It shows what I expect it to show.
Don't know if this changes anything but does NoICE read same wrong
value as your program did? (what values?)
First thing I think of is the fact that the Flash cannot be read while
programming procedure is still activated. A common error has been to
wait for CBEIF and then try to run. Definately we must wait for CCIF
instead. I have no trouble verifying what I just wrote, as long as I
wait for CCIF and there was no error.
Would it be easy to show us a dump of the Flash control registers
[0x100..0x10f] at the time of the incorrect contents? Maybe someone
could see how it is in a wrong state.
> Both. My code does not read the correct value and this is also what
> appears in my BDM tool (NoICE). In the code, right after the Flash
> was programmed I try to read from the Flash. I set a breakpoint
> here and the value that is read is not what I expected. I use
> NoICE to read the same memory and it also confirms that the value
> is not as expected. If I then use NoICE to reset the processor
> and then read the memory, It shows what I expect it to show.
Don't know if this changes anything but does NoICE read same wrong
value as your program did? (what values?)
First thing I think of is the fact that the Flash cannot be read while
programming procedure is still activated. A common error has been to
wait for CBEIF and then try to run. Definately we must wait for CCIF
instead. I have no trouble verifying what I just wrote, as long as I
wait for CCIF and there was no error.
Would it be easy to show us a dump of the Flash control registers
[0x100..0x10f] at the time of the incorrect contents? Maybe someone
could see how it is in a wrong state.
Reply by ●July 26, 20072007-07-26
Jeff Smith wrote:
> --- In 6... , Jeff
> McKnight wrote:
> > Both. My code does not read the correct value and this is also what
> > appears in my BDM tool (NoICE). In the code, right after the Flash
> > was programmed I try to read from the Flash. I set a breakpoint
> > here and the value that is read is not what I expected. I use
> > NoICE to read the same memory and it also confirms that the value
> > is not as expected. If I then use NoICE to reset the processor
> > and then read the memory, It shows what I expect it to show.
>
> Don't know if this changes anything but does NoICE read same wrong
> value as your program did? (what values?)
Yes. I don't know exactly what the values are -
just some bogus values.
>
> First thing I think of is the fact that the Flash cannot be read while
> programming procedure is still activated. A common error has been to
> wait for CBEIF and then try to run. Definately we must wait for CCIF
> instead. I have no trouble verifying what I just wrote, as long as I
> wait for CCIF and there was no error.
I am waiting for CCIF to be set.
>
> Would it be easy to show us a dump of the Flash control registers
> [0x100..0x10f] at the time of the incorrect contents? Maybe someone
> could see how it is in a wrong state.
It boils down to this. I go through a flash
programming sequence in the bootloader. I know
the flash programming was successful because the
bootloader does checks and verifications as it
programs each block. After it is all complete, I
try to read the last memory location that I
programmed - which is $efff - and I get some bogus
value. The flash status registers are as follows:
0100 CA FE 00 00 CF C1 20 00 77 FF 40 00 00 00 00
Now I simply do a reset (with NoICE). The first
thing I do after reset is read the same memory
location ($efff). Now I get the expected value.
The flash status registers at this point are as
follows :
0100 00 FE 00 00 CF C1 00 00 00 00 00 00 00 00 00
>
> --- In 6... , Jeff
> McKnight wrote:
> > Both. My code does not read the correct value and this is also what
> > appears in my BDM tool (NoICE). In the code, right after the Flash
> > was programmed I try to read from the Flash. I set a breakpoint
> > here and the value that is read is not what I expected. I use
> > NoICE to read the same memory and it also confirms that the value
> > is not as expected. If I then use NoICE to reset the processor
> > and then read the memory, It shows what I expect it to show.
>
> Don't know if this changes anything but does NoICE read same wrong
> value as your program did? (what values?)
Yes. I don't know exactly what the values are -
just some bogus values.
>
> First thing I think of is the fact that the Flash cannot be read while
> programming procedure is still activated. A common error has been to
> wait for CBEIF and then try to run. Definately we must wait for CCIF
> instead. I have no trouble verifying what I just wrote, as long as I
> wait for CCIF and there was no error.
I am waiting for CCIF to be set.
>
> Would it be easy to show us a dump of the Flash control registers
> [0x100..0x10f] at the time of the incorrect contents? Maybe someone
> could see how it is in a wrong state.
It boils down to this. I go through a flash
programming sequence in the bootloader. I know
the flash programming was successful because the
bootloader does checks and verifications as it
programs each block. After it is all complete, I
try to read the last memory location that I
programmed - which is $efff - and I get some bogus
value. The flash status registers are as follows:
0100 CA FE 00 00 CF C1 20 00 77 FF 40 00 00 00 00
Now I simply do a reset (with NoICE). The first
thing I do after reset is read the same memory
location ($efff). Now I get the expected value.
The flash status registers at this point are as
follows :
0100 00 FE 00 00 CF C1 00 00 00 00 00 00 00 00 00
>
Reply by ●July 27, 20072007-07-27
--- In 6..., Jeff McKnight wrote:
> It boils down to this. I go through a flash
> programming sequence in the bootloader. I know
> the flash programming was successful because the
> bootloader does checks and verifications as it
> programs each block. After it is all complete, I
> try to read the last memory location that I
> programmed - which is $efff - and I get some bogus
> value. The flash status registers are as follows:
>
> 0100 CA FE 00 00 CF C1 20 00 77 FF 40 00 00 00 00
>
> Now I simply do a reset (with NoICE). The first
> thing I do after reset is read the same memory
> location ($efff). Now I get the expected value.
> The flash status registers at this point are as
> follows :
>
> 0100 00 FE 00 00 CF C1 00 00 00 00 00 00 00 00 00
It all seems like it should work, but I'll try to find my notes when I
got it working. I wrote a routine in assembly that just writes one
word wherever I want it, then I was able to read the change without
resetting. I believe I verified both in app and with NoICE. I use
D-Bug12 with NoICE, but I know some other debugger might have
different characteristics. Knowing that, I would rely first on just
having my application verifying the flash. It should be no problem
though to use NoICE to trace that program. Once it traces a line such
as `ldx 0xfffe`, then you should see the correct contents of flash
from NoICE in the X register.
> It boils down to this. I go through a flash
> programming sequence in the bootloader. I know
> the flash programming was successful because the
> bootloader does checks and verifications as it
> programs each block. After it is all complete, I
> try to read the last memory location that I
> programmed - which is $efff - and I get some bogus
> value. The flash status registers are as follows:
>
> 0100 CA FE 00 00 CF C1 20 00 77 FF 40 00 00 00 00
>
> Now I simply do a reset (with NoICE). The first
> thing I do after reset is read the same memory
> location ($efff). Now I get the expected value.
> The flash status registers at this point are as
> follows :
>
> 0100 00 FE 00 00 CF C1 00 00 00 00 00 00 00 00 00
It all seems like it should work, but I'll try to find my notes when I
got it working. I wrote a routine in assembly that just writes one
word wherever I want it, then I was able to read the change without
resetting. I believe I verified both in app and with NoICE. I use
D-Bug12 with NoICE, but I know some other debugger might have
different characteristics. Knowing that, I would rely first on just
having my application verifying the flash. It should be no problem
though to use NoICE to trace that program. Once it traces a line such
as `ldx 0xfffe`, then you should see the correct contents of flash
from NoICE in the X register.
Reply by ●July 28, 20072007-07-28
--- In 6..., "Jeff Smith" wrote:
>
> --- In 6..., Jeff McKnight wrote:
> > It boils down to this. I go through a flash
> > programming sequence in the bootloader. I know
> > the flash programming was successful because the
> > bootloader does checks and verifications as it
> > programs each block. After it is all complete, I
> > try to read the last memory location that I
> > programmed - which is $efff - and I get some bogus
> > value. The flash status registers are as follows:
> >
> > 0100 CA FE 00 00 CF C1 20 00 77 FF 40 00 00 00 00
> >
> > Now I simply do a reset (with NoICE). The first
> > thing I do after reset is read the same memory
> > location ($efff). Now I get the expected value.
> > The flash status registers at this point are as
> > follows :
> >
> > 0100 00 FE 00 00 CF C1 00 00 00 00 00 00 00 00 00
>
> It all seems like it should work, but I'll try to find my notes when I
> got it working. I wrote a routine in assembly that just writes one
> word wherever I want it, then I was able to read the change without
> resetting. I believe I verified both in app and with NoICE. I use
> D-Bug12 with NoICE, but I know some other debugger might have
> different characteristics. Knowing that, I would rely first on just
> having my application verifying the flash. It should be no problem
> though to use NoICE to trace that program. Once it traces a line such
> as `ldx 0xfffe`, then you should see the correct contents of flash
> from NoICE in the X register.
Nothing like the flash gets relocated to default on reset?
Anybody likes to post the flash programming code into the files area when done?
Might save somebody some grief, I recall at some stage there was a debate on encrypting/decrypting the S1-S9 stream, did that get posted?
All sorts of general purpuse stuff that seems to be done over and over by everoby coming past here.
Cheers,
Theo
>
> --- In 6..., Jeff McKnight wrote:
> > It boils down to this. I go through a flash
> > programming sequence in the bootloader. I know
> > the flash programming was successful because the
> > bootloader does checks and verifications as it
> > programs each block. After it is all complete, I
> > try to read the last memory location that I
> > programmed - which is $efff - and I get some bogus
> > value. The flash status registers are as follows:
> >
> > 0100 CA FE 00 00 CF C1 20 00 77 FF 40 00 00 00 00
> >
> > Now I simply do a reset (with NoICE). The first
> > thing I do after reset is read the same memory
> > location ($efff). Now I get the expected value.
> > The flash status registers at this point are as
> > follows :
> >
> > 0100 00 FE 00 00 CF C1 00 00 00 00 00 00 00 00 00
>
> It all seems like it should work, but I'll try to find my notes when I
> got it working. I wrote a routine in assembly that just writes one
> word wherever I want it, then I was able to read the change without
> resetting. I believe I verified both in app and with NoICE. I use
> D-Bug12 with NoICE, but I know some other debugger might have
> different characteristics. Knowing that, I would rely first on just
> having my application verifying the flash. It should be no problem
> though to use NoICE to trace that program. Once it traces a line such
> as `ldx 0xfffe`, then you should see the correct contents of flash
> from NoICE in the X register.
Nothing like the flash gets relocated to default on reset?
Anybody likes to post the flash programming code into the files area when done?
Might save somebody some grief, I recall at some stage there was a debate on encrypting/decrypting the S1-S9 stream, did that get posted?
All sorts of general purpuse stuff that seems to be done over and over by everoby coming past here.
Cheers,
Theo
Reply by ●July 29, 20072007-07-29
Jeff McKnight wrote:
[...]
> Both. My code does not read the correct value and this is also what
> appears in my BDM tool (NoICE). In the code, right after the Flash was
NoICE caches Flash ROM contents by default, you have to disable
"cache Flash contents" when debugging Flash modifying code.
Oliver
--
Oliver Betz, Muenchen
[...]
> Both. My code does not read the correct value and this is also what
> appears in my BDM tool (NoICE). In the code, right after the Flash was
NoICE caches Flash ROM contents by default, you have to disable
"cache Flash contents" when debugging Flash modifying code.
Oliver
--
Oliver Betz, Muenchen
