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
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
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
