Sign in
Search 68hc12
Subscribe to 68hc12
68hc12 by Keywords
68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC
Sponsor
Ads
Discussion Groups
See Also
Discussion Groups | 68HC12 | Vector table?
Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
Vector table? - hc12meyer - Jul 8 9:37:00 2005
Hi,
I need to switch between two vector tables. Is it ok to do as follows:
Note: The parameter "isrtable" is used to switch between tables,
which contains the base address of the appropriate table.
#pragma abs_address:0xFF88
void (*interrupt_vectors[])() = {
/* to cast a constant, say 0xb600, use
(void (*)())0xb600
*/
(void (*)())(isrtable + 0x00),
(void (*)())(isrtable + 0x02),
(void (*)())(isrtable + 0x04),
(void (*)())(isrtable + 0x08),
..
}
Thanks,
Meyer
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
I need to switch between two vector tables. Is it ok to do as follows:
Note: The parameter "isrtable" is used to switch between tables,
which contains the base address of the appropriate table.
#pragma abs_address:0xFF88
void (*interrupt_vectors[])() = {
/* to cast a constant, say 0xb600, use
(void (*)())0xb600
*/
(void (*)())(isrtable + 0x00),
(void (*)())(isrtable + 0x02),
(void (*)())(isrtable + 0x04),
(void (*)())(isrtable + 0x08),
..
}
Thanks,
Meyer
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Vector table? - Daniel Lundin - Jul 8 10:00:00 2005
--- In 68HC12@68HC..., "hc12meyer" <hc12meyer@y...> wrote:
> Hi,
>
> I need to switch between two vector tables. Is it ok to do as
follows:
>
> Note: The parameter "isrtable" is used to switch between tables,
> which contains the base address of the appropriate table.
>
> #pragma abs_address:0xFF88
> void (*interrupt_vectors[])() = {
> /* to cast a constant, say 0xb600, use
> (void (*)())0xb600
> */
> (void (*)())(isrtable + 0x00),
> (void (*)())(isrtable + 0x02),
> (void (*)())(isrtable + 0x04),
> (void (*)())(isrtable + 0x08),
> ..
> }
>
> Thanks,
> Meyer If isrtable is declaired as
#define isrtable 0xFF88
then it should be ok in both C and C++. If isrtable is a constant
pointer (or a constant 16-bit int), then it will only work in C++
sence it isn't allowed to use constants to initialize variables in C.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
> Hi,
>
> I need to switch between two vector tables. Is it ok to do as
follows:
>
> Note: The parameter "isrtable" is used to switch between tables,
> which contains the base address of the appropriate table.
>
> #pragma abs_address:0xFF88
> void (*interrupt_vectors[])() = {
> /* to cast a constant, say 0xb600, use
> (void (*)())0xb600
> */
> (void (*)())(isrtable + 0x00),
> (void (*)())(isrtable + 0x02),
> (void (*)())(isrtable + 0x04),
> (void (*)())(isrtable + 0x08),
> ..
> }
>
> Thanks,
> Meyer If isrtable is declaired as
#define isrtable 0xFF88
then it should be ok in both C and C++. If isrtable is a constant
pointer (or a constant 16-bit int), then it will only work in C++
sence it isn't allowed to use constants to initialize variables in C.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Vector table? - hc12meyer - Jul 8 10:27:00 2005
My second table would looks like this:
#pragma interrupt_handler CopClockFail
void CopClockFail(void)
{
...
/* Reset the card */
} #pragma abs_address:0x4000
void(*interrupt_vectors[])() = {
...
CopClockFail,
_start
}
So, when I use this table, I will set the "isrtable" to be 0x4000 in
the intial table (previous message). Will I have any issues in "C"?
Thank you,
Meyer.
--- In 68HC12@68HC..., "Daniel Lundin"
<datek.development@m...> wrote:
> --- In 68HC12@68HC..., "hc12meyer" <hc12meyer@y...> wrote:
> > Hi,
> >
> > I need to switch between two vector tables. Is it ok to do as
> follows:
> >
> > Note: The parameter "isrtable" is used to switch between tables,
> > which contains the base address of the appropriate table.
> >
> > #pragma abs_address:0xFF88
> > void (*interrupt_vectors[])() = {
> > /* to cast a constant, say 0xb600, use
> > (void (*)())0xb600
> > */
> > (void (*)())(isrtable + 0x00),
> > (void (*)())(isrtable + 0x02),
> > (void (*)())(isrtable + 0x04),
> > (void (*)())(isrtable + 0x08),
> > ..
> > }
> >
> > Thanks,
> > Meyer > If isrtable is declaired as
>
> #define isrtable 0xFF88
>
> then it should be ok in both C and C++. If isrtable is a constant
> pointer (or a constant 16-bit int), then it will only work in C++
> sence it isn't allowed to use constants to initialize variables in
C.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
#pragma interrupt_handler CopClockFail
void CopClockFail(void)
{
...
/* Reset the card */
} #pragma abs_address:0x4000
void(*interrupt_vectors[])() = {
...
CopClockFail,
_start
}
So, when I use this table, I will set the "isrtable" to be 0x4000 in
the intial table (previous message). Will I have any issues in "C"?
Thank you,
Meyer.
--- In 68HC12@68HC..., "Daniel Lundin"
<datek.development@m...> wrote:
> --- In 68HC12@68HC..., "hc12meyer" <hc12meyer@y...> wrote:
> > Hi,
> >
> > I need to switch between two vector tables. Is it ok to do as
> follows:
> >
> > Note: The parameter "isrtable" is used to switch between tables,
> > which contains the base address of the appropriate table.
> >
> > #pragma abs_address:0xFF88
> > void (*interrupt_vectors[])() = {
> > /* to cast a constant, say 0xb600, use
> > (void (*)())0xb600
> > */
> > (void (*)())(isrtable + 0x00),
> > (void (*)())(isrtable + 0x02),
> > (void (*)())(isrtable + 0x04),
> > (void (*)())(isrtable + 0x08),
> > ..
> > }
> >
> > Thanks,
> > Meyer > If isrtable is declaired as
>
> #define isrtable 0xFF88
>
> then it should be ok in both C and C++. If isrtable is a constant
> pointer (or a constant 16-bit int), then it will only work in C++
> sence it isn't allowed to use constants to initialize variables in
C.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: Vector table? - Stephen Trier - Jul 8 13:20:00 2005
Meyer,
That won't work. The CPU's vector table is a list of function pointers,
two bytes each. The CPU looks up a pointer, sets the program counter
to it, and starts executing there. Each pointer in the table has to
reference valid executable code. You can't point it at another pointer.
Thus, your second table needs to be code, not an array of function
pointers. If you use assembly, you can make it a bunch of JMP
instructions. If you use C, point the first table at a bunch of C
functions, which then call the functions you want to have actually
handle the interrupt.
The typecasts you have in the first table are a sign of the problem.
You shouldn't need to do the very dangerous operation of casting integers
into function pointers if you have things set up right.
Stephen
--
Stephen Trier
Technical Development Lab
Cleveland FES Center
sct@sct@...
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
That won't work. The CPU's vector table is a list of function pointers,
two bytes each. The CPU looks up a pointer, sets the program counter
to it, and starts executing there. Each pointer in the table has to
reference valid executable code. You can't point it at another pointer.
Thus, your second table needs to be code, not an array of function
pointers. If you use assembly, you can make it a bunch of JMP
instructions. If you use C, point the first table at a bunch of C
functions, which then call the functions you want to have actually
handle the interrupt.
The typecasts you have in the first table are a sign of the problem.
You shouldn't need to do the very dangerous operation of casting integers
into function pointers if you have things set up right.
Stephen
--
Stephen Trier
Technical Development Lab
Cleveland FES Center
sct@sct@...
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: Vector table? - Doron Fael - Jul 8 16:53:00 2005
The new S12X family has improvement in this field, and allows the code to
have multiple interrupt vector tables. This is achieved using the S12X IVBR
register (Interrupt Vector Base Register), that sets the 8 MSB bits of the
16-bit address for the Interrupt Vector Table. Changing to use a different
interrupt vector table is then simply done by writing to the IVBR register
- quick, easy and useful for bootloaders and multi-tasking applications.
On HCS12 and HC12 part, this has to be done as Stephen explain - in the
more complicated and slower way.
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
At 13:20 08/07/2005 -0400, you wrote:
>Meyer,
>
>That won't work. The CPU's vector table is a list of function pointers,
>two bytes each. The CPU looks up a pointer, sets the program counter
>to it, and starts executing there. Each pointer in the table has to
>reference valid executable code. You can't point it at another pointer.
>
>Thus, your second table needs to be code, not an array of function
>pointers. If you use assembly, you can make it a bunch of JMP
>instructions. If you use C, point the first table at a bunch of C
>functions, which then call the functions you want to have actually
>handle the interrupt.
>
>The typecasts you have in the first table are a sign of the problem.
>You shouldn't need to do the very dangerous operation of casting integers
>into function pointers if you have things set up right.
>
> Stephen
>
>--
>Stephen Trier
>Technical Development Lab
>Cleveland FES Center
>sct@sct@... [Non-text portions of this message have been removed]
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Back to "special" mode? - James M. Knox - Jul 8 20:38:00 2005
They said it couldn't be done... and sometimes they are right!
Is there any way to get an HC12D60A (or most related variants) back
into special mode once it's into normal mode? What I would like to
do is set the shadow word so that Flash is protected at boot time,
but I still need a way to unprotect it so that I can alter it in the field.
With hardware, yes, I can rig something. But I'm looking for a
software solution - if there is one. Looking at the book, however, I
see no way to reset FPOPEN once it has been set in normal mode to
protect, and no way to get it out of normal mode.
jmk
-----------------------------------------------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 jknox@jkno...
-----------------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
MC33390 - DP256 BDLC problem - Rob Milne - Jul 9 14:06:00 2005
Is anyone familiar with the MC33390 J1850 transceiver and DP256 BDLC
combo? I'm using a standard J1850 simulator/monitor to test my system
and can successfully send/receive frames so I assume my BDLC driver is
constructed properly (based on HC08 code in Moto doc AN1731). What has
me baffled are the hw hacks I've had to use to make things work.
My hw design is mostly consistant with the MC33390 doc (no MOV between
the 470pf cap and the bus - Vbat comes directly from my 12V regulated
supply) but will only work if I put pullup resistors on the
BDLC/tranceiver tx-rx lines and a pull down on the bus line. When the
BDLC is enabled the bus idles at 1V and when the BDLC is disabled it
idles at 5.5V. I don't think this is kosher but it works. This
arrangement was derived after noticing that J1850 comms worked while the
CAN tranceiver traces to CAN0 were in place but not after being
severed. Since the MC33390 is non-inverting I cannot understand why I
need the pull ups (PERM and PPSM registers are not changed from reset
value).
Can anyone offer me advise (I'm a sw guy - not a J1850 phy layer expert)?
Rob Milne
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
combo? I'm using a standard J1850 simulator/monitor to test my system
and can successfully send/receive frames so I assume my BDLC driver is
constructed properly (based on HC08 code in Moto doc AN1731). What has
me baffled are the hw hacks I've had to use to make things work.
My hw design is mostly consistant with the MC33390 doc (no MOV between
the 470pf cap and the bus - Vbat comes directly from my 12V regulated
supply) but will only work if I put pullup resistors on the
BDLC/tranceiver tx-rx lines and a pull down on the bus line. When the
BDLC is enabled the bus idles at 1V and when the BDLC is disabled it
idles at 5.5V. I don't think this is kosher but it works. This
arrangement was derived after noticing that J1850 comms worked while the
CAN tranceiver traces to CAN0 were in place but not after being
severed. Since the MC33390 is non-inverting I cannot understand why I
need the pull ups (PERM and PPSM registers are not changed from reset
value).
Can anyone offer me advise (I'm a sw guy - not a J1850 phy layer expert)?
Rob Milne
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Back to "special" mode? - Doron Fael - Jul 10 7:20:00 2005
James,
Once your HC12 (or HCS12) device is in Normal operating mode, there is no
way to get it into Special or Emulation operating mode by writing to the
Mode register.
On HC12 old-generation parts (the 68HC912D60A included), the bit MODC is
write-able only when MODC is 0 (when already in a special mode), otherwise
it cannot be written.
The reasoning - is in order to protect user applications that suppose to
use only Normal modes from getting into Special modes that don't have
proper protection of write-once on many registers. (The write-once quality
that exist for many HC12 registers in normal operating modes is inserted by
Freecale to protect the applications in areas that Frescale evaluates the
application should not write more than once to a register.)
The only way to get into Special mode after already being in Normal mode is
to Reset into Special mode. A Reset can be achieved in software by starting
the COP watchdog and then writing any value other than 0x55 and 0xAA to the
ARMCOP register to provoke the Reset. (be sure to also drive the SMODN/BKGD
as well as the MODB and MODA appropriately during Reset to force the
require operating mode).
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
At 19:38 08/07/2005 -0500, you wrote:
>They said it couldn't be done... and sometimes they are right!
>
>Is there any way to get an HC12D60A (or most related variants) back
>into special mode once it's into normal mode? What I would like to
>do is set the shadow word so that Flash is protected at boot time,
>but I still need a way to unprotect it so that I can alter it in the field.
>
>With hardware, yes, I can rig something. But I'm looking for a
>software solution - if there is one. Looking at the book, however, I
>see no way to reset FPOPEN once it has been set in normal mode to
>protect, and no way to get it out of normal mode.
>
> jmk
>
>-----------------------------------------------
>James M. Knox
>TriSoft ph 512-385-0316
>1300 Koenig Lane West fax 512-371-5716
>Suite 200
>Austin, Tx 78756 jknox@jkno...
>----------------------------------------------- [Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Once your HC12 (or HCS12) device is in Normal operating mode, there is no
way to get it into Special or Emulation operating mode by writing to the
Mode register.
On HC12 old-generation parts (the 68HC912D60A included), the bit MODC is
write-able only when MODC is 0 (when already in a special mode), otherwise
it cannot be written.
The reasoning - is in order to protect user applications that suppose to
use only Normal modes from getting into Special modes that don't have
proper protection of write-once on many registers. (The write-once quality
that exist for many HC12 registers in normal operating modes is inserted by
Freecale to protect the applications in areas that Frescale evaluates the
application should not write more than once to a register.)
The only way to get into Special mode after already being in Normal mode is
to Reset into Special mode. A Reset can be achieved in software by starting
the COP watchdog and then writing any value other than 0x55 and 0xAA to the
ARMCOP register to provoke the Reset. (be sure to also drive the SMODN/BKGD
as well as the MODB and MODA appropriately during Reset to force the
require operating mode).
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
At 19:38 08/07/2005 -0500, you wrote:
>They said it couldn't be done... and sometimes they are right!
>
>Is there any way to get an HC12D60A (or most related variants) back
>into special mode once it's into normal mode? What I would like to
>do is set the shadow word so that Flash is protected at boot time,
>but I still need a way to unprotect it so that I can alter it in the field.
>
>With hardware, yes, I can rig something. But I'm looking for a
>software solution - if there is one. Looking at the book, however, I
>see no way to reset FPOPEN once it has been set in normal mode to
>protect, and no way to get it out of normal mode.
>
> jmk
>
>-----------------------------------------------
>James M. Knox
>TriSoft ph 512-385-0316
>1300 Koenig Lane West fax 512-371-5716
>Suite 200
>Austin, Tx 78756 jknox@jkno...
>----------------------------------------------- [Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Back to "special" mode? - James M. Knox - Jul 10 11:37:00 2005
At 14:20 7/10/2005 +0300, you wrote:
>James,
>
>Once your HC12 (or HCS12) device is in Normal operating mode, there is no
>way to get it into Special or Emulation operating mode by writing to the
>Mode register.
>
>The only way to get into Special mode after already being in Normal mode is
>to Reset into Special mode.
Thanks... that's what it looked like (and frankly what makes
sense). But I was hoping I had missed something. I have two
conflicting issues:
o I'm still having trouble with Flash getting erased in field units,
in spite of all the checks I have installed so far. So the last
possible SW fix is to set FPOPEN to protect all the flash, using the
shadow bit so that it is protected during the initial HW boot (before
it even gets to my code).
o But I am also required to let the user upload new application
programs into Flash, fix serial port.
Looks like the latter trumps the former requirement. I will set the
FPOPEN bit in software as soon as all the checksums verify, and hope
for the best.
Otherwise, as you suggest, it's hardware mod time to allow it to come
up in Special mode on command, but normally come up directly in Normal mode.
tnx, jmk
-----------------------------------------------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 jknox@jkno...
-----------------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
>James,
>
>Once your HC12 (or HCS12) device is in Normal operating mode, there is no
>way to get it into Special or Emulation operating mode by writing to the
>Mode register.
>
>The only way to get into Special mode after already being in Normal mode is
>to Reset into Special mode.
Thanks... that's what it looked like (and frankly what makes
sense). But I was hoping I had missed something. I have two
conflicting issues:
o I'm still having trouble with Flash getting erased in field units,
in spite of all the checks I have installed so far. So the last
possible SW fix is to set FPOPEN to protect all the flash, using the
shadow bit so that it is protected during the initial HW boot (before
it even gets to my code).
o But I am also required to let the user upload new application
programs into Flash, fix serial port.
Looks like the latter trumps the former requirement. I will set the
FPOPEN bit in software as soon as all the checksums verify, and hope
for the best.
Otherwise, as you suggest, it's hardware mod time to allow it to come
up in Special mode on command, but normally come up directly in Normal mode.
tnx, jmk
-----------------------------------------------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 jknox@jkno...
-----------------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Back to "special" mode? - Stephen Trier - Jul 11 10:03:00 2005
Doron,
Do the HCS12 devices have the same characteristic as the HC12 devices,
in that powering up in special single-chip starts execution in the BDM ROM
(BDM "ACTIVE") instead of from flash? If that's the case, even if James
arranges to power up with MODC low, he's going to be stuck. The CPU
will be running from the BDM ROM and won't execute his bootloader code
until an external BDM device tells it to do so.
Stephen
--
Stephen Trier
Technical Development Lab
Cleveland FES Center
sct@sct@...
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Do the HCS12 devices have the same characteristic as the HC12 devices,
in that powering up in special single-chip starts execution in the BDM ROM
(BDM "ACTIVE") instead of from flash? If that's the case, even if James
arranges to power up with MODC low, he's going to be stuck. The CPU
will be running from the BDM ROM and won't execute his bootloader code
until an external BDM device tells it to do so.
Stephen
--
Stephen Trier
Technical Development Lab
Cleveland FES Center
sct@sct@...
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Back to "special" mode? - Doron Fael - Jul 11 11:13:00 2005
Hi Stephen,
You are right.
Resetting into Special Single-Chip mode will not work without a BDM pod to
take the device out of the active BDM mode.
An alternative is to Reset the chip into one of the other special modes,
that don't put the device in active BDM mode out of Reset. This is no doubt
also difficult to deal with, as it involves operating in Special Test Mode,
Special Expanded Wide or Special Expanded Narrow mode.
I think maybe a better approach for James to consider is for the code to
check if a bootloader should be started right after Reset, and before
writing to any of the write-once registers.
Then if the bootloader should be started, its code can be loaded to the
device's internal RAM and start programing the Flash with new information.
If the bootloader does not need to be started, the write-once registers can
be configured for the main application, and including the establishment of
Flash protection.
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
At 10:03 11/07/2005 -0400, you wrote:
>Doron,
>
>Do the HCS12 devices have the same characteristic as the HC12 devices,
>in that powering up in special single-chip starts execution in the BDM ROM
>(BDM "ACTIVE") instead of from flash? If that's the case, even if James
>arranges to power up with MODC low, he's going to be stuck. The CPU
>will be running from the BDM ROM and won't execute his bootloader code
>until an external BDM device tells it to do so.
>
> Stephen
>
>--
>Stephen Trier
>Technical Development Lab
>Cleveland FES Center
>sct@sct@... [Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
You are right.
Resetting into Special Single-Chip mode will not work without a BDM pod to
take the device out of the active BDM mode.
An alternative is to Reset the chip into one of the other special modes,
that don't put the device in active BDM mode out of Reset. This is no doubt
also difficult to deal with, as it involves operating in Special Test Mode,
Special Expanded Wide or Special Expanded Narrow mode.
I think maybe a better approach for James to consider is for the code to
check if a bootloader should be started right after Reset, and before
writing to any of the write-once registers.
Then if the bootloader should be started, its code can be loaded to the
device's internal RAM and start programing the Flash with new information.
If the bootloader does not need to be started, the write-once registers can
be configured for the main application, and including the establishment of
Flash protection.
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
At 10:03 11/07/2005 -0400, you wrote:
>Doron,
>
>Do the HCS12 devices have the same characteristic as the HC12 devices,
>in that powering up in special single-chip starts execution in the BDM ROM
>(BDM "ACTIVE") instead of from flash? If that's the case, even if James
>arranges to power up with MODC low, he's going to be stuck. The CPU
>will be running from the BDM ROM and won't execute his bootloader code
>until an external BDM device tells it to do so.
>
> Stephen
>
>--
>Stephen Trier
>Technical Development Lab
>Cleveland FES Center
>sct@sct@... [Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Back to "special" mode? - James M. Knox - Jul 11 20:31:00 2005
At 18:13 7/11/2005 +0300, you wrote:
>I think maybe a better approach for James to consider is for the code to
>check if a bootloader should be started right after Reset, and before
>writing to any of the write-once registers.
>Then if the bootloader should be started, its code can be loaded to the
>device's internal RAM and start programing the Flash with new information.
>If the bootloader does not need to be started, the write-once registers can
>be configured for the main application, and including the establishment of
>Flash protection.
That's basically what I have now. At boot (normal, single chip mode)
a small piece of code checksums the application program and data
tables. If it passes, then the FPOPEN bit is set to protect flash
and control is passed to the application program. [This code, and
the boot loader, run in the additionally protected $E000 region.]
If the checksum does not pass, OR if it detects a special code
sequence being sent ever the serial port, then control is passed to
the boot loader.
The problem is *RARELY* we are getting reports of the machine "not
running." Analysis indicates that the flash where the application
program runs (lower 28K) is erased. The boot loader is still in
protected flash. At first I thought maybe application program was
just "jumping" into the "erase flash" section of the boot loader...
but that's VERY unlikely. There are all sorts of code checks around
that code ("How did I get here?"). And that code is in the *wrong*
space (the two flash sections are flipped), so it shouldn't run regardless.
Then I thought maybe somehow it was accidentally getting the erase
command over the serial port. I've made that a long arbitrary
string. Still happens.
So I wanted to protect the Flash without regard to ANY code - i.e. it
would take very special code to UNPROTECT the flash. That way,
hopefully, even a questionable power up, low voltage, etc. shouldn't
erase it. But... oh well.
jmk -----------------------------------------------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 jknox@jkno...
-----------------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
>I think maybe a better approach for James to consider is for the code to
>check if a bootloader should be started right after Reset, and before
>writing to any of the write-once registers.
>Then if the bootloader should be started, its code can be loaded to the
>device's internal RAM and start programing the Flash with new information.
>If the bootloader does not need to be started, the write-once registers can
>be configured for the main application, and including the establishment of
>Flash protection.
That's basically what I have now. At boot (normal, single chip mode)
a small piece of code checksums the application program and data
tables. If it passes, then the FPOPEN bit is set to protect flash
and control is passed to the application program. [This code, and
the boot loader, run in the additionally protected $E000 region.]
If the checksum does not pass, OR if it detects a special code
sequence being sent ever the serial port, then control is passed to
the boot loader.
The problem is *RARELY* we are getting reports of the machine "not
running." Analysis indicates that the flash where the application
program runs (lower 28K) is erased. The boot loader is still in
protected flash. At first I thought maybe application program was
just "jumping" into the "erase flash" section of the boot loader...
but that's VERY unlikely. There are all sorts of code checks around
that code ("How did I get here?"). And that code is in the *wrong*
space (the two flash sections are flipped), so it shouldn't run regardless.
Then I thought maybe somehow it was accidentally getting the erase
command over the serial port. I've made that a long arbitrary
string. Still happens.
So I wanted to protect the Flash without regard to ANY code - i.e. it
would take very special code to UNPROTECT the flash. That way,
hopefully, even a questionable power up, low voltage, etc. shouldn't
erase it. But... oh well.
jmk -----------------------------------------------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 jknox@jkno...
-----------------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: Back to "special" mode? - Jonathan Masters - Jul 11 20:37:00 2005
Jim,
Just a thought, but my applications are safety related and thus the
provision of code in flash to program or erase memory is not something
our design rules allow.
To solve this, the loader does not actually have flash code built into
it. It loads the flashing code over the communications link into RAM.
This code includes the specific protocol for loading bootload data over
the link and flashing memory. When it terminates, the RAM is erased with
NOPs.
Perhaps this is a way to solve your problem - even if you only load the
erase code over the link?
Jonathan.
-----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of James M. Knox
Sent: Tuesday, 12 July 2005 10:32 AM
To: 68HC12@68HC...
Subject: Re: [68HC12] Back to "special" mode?
At 18:13 7/11/2005 +0300, you wrote:
>I think maybe a better approach for James to consider is for the code
to
>check if a bootloader should be started right after Reset, and before
>writing to any of the write-once registers.
>Then if the bootloader should be started, its code can be loaded to the
>device's internal RAM and start programing the Flash with new
information.
>If the bootloader does not need to be started, the write-once registers
can
>be configured for the main application, and including the establishment
of
>Flash protection.
That's basically what I have now. At boot (normal, single chip mode)
a small piece of code checksums the application program and data
tables. If it passes, then the FPOPEN bit is set to protect flash
and control is passed to the application program. [This code, and
the boot loader, run in the additionally protected $E000 region.]
If the checksum does not pass, OR if it detects a special code
sequence being sent ever the serial port, then control is passed to
the boot loader.
The problem is *RARELY* we are getting reports of the machine "not
running." Analysis indicates that the flash where the application
program runs (lower 28K) is erased. The boot loader is still in
protected flash. At first I thought maybe application program was
just "jumping" into the "erase flash" section of the boot loader...
but that's VERY unlikely. There are all sorts of code checks around
that code ("How did I get here?"). And that code is in the *wrong*
space (the two flash sections are flipped), so it shouldn't run
regardless.
Then I thought maybe somehow it was accidentally getting the erase
command over the serial port. I've made that a long arbitrary
string. Still happens.
So I wanted to protect the Flash without regard to ANY code - i.e. it
would take very special code to UNPROTECT the flash. That way,
hopefully, even a questionable power up, low voltage, etc. shouldn't
erase it. But... oh well.
jmk -----------------------------------------------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 jknox@jkno...
-----------------------------------------------
_____
> Terms of Service.
_____
[Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Just a thought, but my applications are safety related and thus the
provision of code in flash to program or erase memory is not something
our design rules allow.
To solve this, the loader does not actually have flash code built into
it. It loads the flashing code over the communications link into RAM.
This code includes the specific protocol for loading bootload data over
the link and flashing memory. When it terminates, the RAM is erased with
NOPs.
Perhaps this is a way to solve your problem - even if you only load the
erase code over the link?
Jonathan.
-----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of James M. Knox
Sent: Tuesday, 12 July 2005 10:32 AM
To: 68HC12@68HC...
Subject: Re: [68HC12] Back to "special" mode?
At 18:13 7/11/2005 +0300, you wrote:
>I think maybe a better approach for James to consider is for the code
to
>check if a bootloader should be started right after Reset, and before
>writing to any of the write-once registers.
>Then if the bootloader should be started, its code can be loaded to the
>device's internal RAM and start programing the Flash with new
information.
>If the bootloader does not need to be started, the write-once registers
can
>be configured for the main application, and including the establishment
of
>Flash protection.
That's basically what I have now. At boot (normal, single chip mode)
a small piece of code checksums the application program and data
tables. If it passes, then the FPOPEN bit is set to protect flash
and control is passed to the application program. [This code, and
the boot loader, run in the additionally protected $E000 region.]
If the checksum does not pass, OR if it detects a special code
sequence being sent ever the serial port, then control is passed to
the boot loader.
The problem is *RARELY* we are getting reports of the machine "not
running." Analysis indicates that the flash where the application
program runs (lower 28K) is erased. The boot loader is still in
protected flash. At first I thought maybe application program was
just "jumping" into the "erase flash" section of the boot loader...
but that's VERY unlikely. There are all sorts of code checks around
that code ("How did I get here?"). And that code is in the *wrong*
space (the two flash sections are flipped), so it shouldn't run
regardless.
Then I thought maybe somehow it was accidentally getting the erase
command over the serial port. I've made that a long arbitrary
string. Still happens.
So I wanted to protect the Flash without regard to ANY code - i.e. it
would take very special code to UNPROTECT the flash. That way,
hopefully, even a questionable power up, low voltage, etc. shouldn't
erase it. But... oh well.
jmk -----------------------------------------------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 jknox@jkno...
-----------------------------------------------
_____
> Terms of Service.
_____
[Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Back to "special" mode? - Steve Russell - Jul 11 21:33:00 2005
I understand how frustrating this kind of problem can be. I have some war
stories from previous employers.
I don't have any really good ideas, but I have some far-fetched suggestions
that you have probably have already tried.
In tracking down this kind of problem, my experience is that changing
SOMETHING every time the problem is reported eventually gets enough
information to catch the problem. The change can either be more protection
from some imagined cause, or something to give more information on how to
reproduce the problem.
It ain't fast, but eventually it has worked for me.
It also helps pacify the customer, sales and management.
Unfortunately, I don't have a reference, but I do have a memory of some
reports a few years ago where there was reason to believe that spurious
flash erasing was due to power supply glitches, or an out of spec clock.
I don't see a good way to detect this happening in the field, but you could
try to provoke such things in the lab.
If you have a few sites that seem to get the problem repeatedly, you could
try adding more protection and detection to the units there.
Are you using all the hardware failure detection features? (Clock monitor
reset, Illegal Instruction Trap, detection of spurious "unimplemented" or
"reserved" interrupts that "can never happen".)
Are you filling unused flash with Illegal instructions or SWI or
BGND? (Erased flash is LDS $FFFF, or "corrupt the SP and PC, and keep
going to see what happens".)
If there is an operator interface, you might be able to determine if your
erase code is doing the dirty work by making as much noise and flashing as
many lights as you can for several minutes before actually erasing the flash.
This would slow down the field upgrade process, but it might get noticed
and reported.
Hope this helps, and you can tell us what the cause really was,
Steve Russell
Nohau
At 05:31 PM 7/11/2005, "James M. Knox" <jknox@jkno...> wrote:
>At 18:13 7/11/2005 +0300, you wrote:
>
> >I think maybe a better approach for James to consider is for the code to
> >check if a bootloader should be started right after Reset, and before
> >writing to any of the write-once registers.
> >Then if the bootloader should be started, its code can be loaded to the
> >device's internal RAM and start programing the Flash with new information.
> >If the bootloader does not need to be started, the write-once registers can
> >be configured for the main application, and including the establishment of
> >Flash protection.
>
>That's basically what I have now. At boot (normal, single chip mode)
>a small piece of code checksums the application program and data
>tables. If it passes, then the FPOPEN bit is set to protect flash
>and control is passed to the application program. [This code, and
>the boot loader, run in the additionally protected $E000 region.]
>
>If the checksum does not pass, OR if it detects a special code
>sequence being sent ever the serial port, then control is passed to
>the boot loader.
>
>The problem is *RARELY* we are getting reports of the machine "not
>running." Analysis indicates that the flash where the application
>program runs (lower 28K) is erased. The boot loader is still in
>protected flash. At first I thought maybe application program was
>just "jumping" into the "erase flash" section of the boot loader...
>but that's VERY unlikely. There are all sorts of code checks around
>that code ("How did I get here?"). And that code is in the *wrong*
>space (the two flash sections are flipped), so it shouldn't run regardless.
>
>Then I thought maybe somehow it was accidentally getting the erase
>command over the serial port. I've made that a long arbitrary
>string. Still happens.
>
>So I wanted to protect the Flash without regard to ANY code - i.e. it
>would take very special code to UNPROTECT the flash. That way,
>hopefully, even a questionable power up, low voltage, etc. shouldn't
>erase it. But... oh well.
>
> jmk >-----------------------------------------------
>James M. Knox
>TriSoft ph 512-385-0316
>1300 Koenig Lane West fax 512-371-5716
>Suite 200
>Austin, Tx 78756 jknox@jkno...
>----------------------------------------------- >
>
>Yahoo! Groups Links
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
stories from previous employers.
I don't have any really good ideas, but I have some far-fetched suggestions
that you have probably have already tried.
In tracking down this kind of problem, my experience is that changing
SOMETHING every time the problem is reported eventually gets enough
information to catch the problem. The change can either be more protection
from some imagined cause, or something to give more information on how to
reproduce the problem.
It ain't fast, but eventually it has worked for me.
It also helps pacify the customer, sales and management.
Unfortunately, I don't have a reference, but I do have a memory of some
reports a few years ago where there was reason to believe that spurious
flash erasing was due to power supply glitches, or an out of spec clock.
I don't see a good way to detect this happening in the field, but you could
try to provoke such things in the lab.
If you have a few sites that seem to get the problem repeatedly, you could
try adding more protection and detection to the units there.
Are you using all the hardware failure detection features? (Clock monitor
reset, Illegal Instruction Trap, detection of spurious "unimplemented" or
"reserved" interrupts that "can never happen".)
Are you filling unused flash with Illegal instructions or SWI or
BGND? (Erased flash is LDS $FFFF, or "corrupt the SP and PC, and keep
going to see what happens".)
If there is an operator interface, you might be able to determine if your
erase code is doing the dirty work by making as much noise and flashing as
many lights as you can for several minutes before actually erasing the flash.
This would slow down the field upgrade process, but it might get noticed
and reported.
Hope this helps, and you can tell us what the cause really was,
Steve Russell
Nohau
At 05:31 PM 7/11/2005, "James M. Knox" <jknox@jkno...> wrote:
>At 18:13 7/11/2005 +0300, you wrote:
>
> >I think maybe a better approach for James to consider is for the code to
> >check if a bootloader should be started right after Reset, and before
> >writing to any of the write-once registers.
> >Then if the bootloader should be started, its code can be loaded to the
> >device's internal RAM and start programing the Flash with new information.
> >If the bootloader does not need to be started, the write-once registers can
> >be configured for the main application, and including the establishment of
> >Flash protection.
>
>That's basically what I have now. At boot (normal, single chip mode)
>a small piece of code checksums the application program and data
>tables. If it passes, then the FPOPEN bit is set to protect flash
>and control is passed to the application program. [This code, and
>the boot loader, run in the additionally protected $E000 region.]
>
>If the checksum does not pass, OR if it detects a special code
>sequence being sent ever the serial port, then control is passed to
>the boot loader.
>
>The problem is *RARELY* we are getting reports of the machine "not
>running." Analysis indicates that the flash where the application
>program runs (lower 28K) is erased. The boot loader is still in
>protected flash. At first I thought maybe application program was
>just "jumping" into the "erase flash" section of the boot loader...
>but that's VERY unlikely. There are all sorts of code checks around
>that code ("How did I get here?"). And that code is in the *wrong*
>space (the two flash sections are flipped), so it shouldn't run regardless.
>
>Then I thought maybe somehow it was accidentally getting the erase
>command over the serial port. I've made that a long arbitrary
>string. Still happens.
>
>So I wanted to protect the Flash without regard to ANY code - i.e. it
>would take very special code to UNPROTECT the flash. That way,
>hopefully, even a questionable power up, low voltage, etc. shouldn't
>erase it. But... oh well.
>
> jmk >-----------------------------------------------
>James M. Knox
>TriSoft ph 512-385-0316
>1300 Koenig Lane West fax 512-371-5716
>Suite 200
>Austin, Tx 78756 jknox@jkno...
>----------------------------------------------- >
>
>Yahoo! Groups Links
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: Back to "special" mode? - James M. Knox - Jul 11 22:43:00 2005
At 10:37 7/12/2005 +1000, you wrote
>Perhaps this is a way to solve your problem - even if you only load the
>erase code over the link?
That's a thought that we had, and someone suggested, when the problem
first surfaced. But as best I can tell, when I tried that in a test
case, it didn't make any difference. [Part of the trouble is that it
only happens VERY rarely... hard to get any kind of convincing tests
under those circumstances.]
Frankly, I do NOT think that it is *in* the software. I think it is
some kind of "boot" condition in the processor itself. However, I've
had it happen on more than one board type. And I've checked reset,
oscillator (we have a real TTL oscillator that always starts cleanly,
and a nice motorola reset chip.
On two occasions I have even had the following happen:
o Erase Flash
o Program flash with P&E Prog12z
o Verify flash with P&E Prog12z
o exit Prog12z
o Start ICD12Z, reset -- no boot vector
o Look... flash is erased.
jmk -----------------------------------------------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 jknox@jkno...
-----------------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
>erase code over the link?
That's a thought that we had, and someone suggested, when the problem
first surfaced. But as best I can tell, when I tried that in a test
case, it didn't make any difference. [Part of the trouble is that it
only happens VERY rarely... hard to get any kind of convincing tests
under those circumstances.]
Frankly, I do NOT think that it is *in* the software. I think it is
some kind of "boot" condition in the processor itself. However, I've
had it happen on more than one board type. And I've checked reset,
oscillator (we have a real TTL oscillator that always starts cleanly,
and a nice motorola reset chip.
On two occasions I have even had the following happen:
o Erase Flash
o Program flash with P&E Prog12z
o Verify flash with P&E Prog12z
o exit Prog12z
o Start ICD12Z, reset -- no boot vector
o Look... flash is erased.
jmk -----------------------------------------------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 jknox@jkno...
-----------------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Back to "special" mode? - James M. Knox - Jul 11 22:47:00 2005
At 18:33 7/11/2005 -0700, you wrote:
>I understand how frustrating this kind of problem can be. I have some war
>stories from previous employers.
>
>I don't have any really good ideas, but I have some far-fetched suggestions
>that you have probably have already tried.
Suggestions always appreciated. This is why some of the computer
user groups have "war story" sessions. Someone else's trials may
spark an idea, or worst case, even misery loves company. <G >Unfortunately, I don't have a reference, but I do have a memory of some
>reports a few years ago where there was reason to believe that spurious
>flash erasing was due to power supply glitches, or an out of spec clock.
Wouldn't surprise me... but I sure see everything looking just perfect.
>If there is an operator interface, you might be able to determine if your
>erase code is doing the dirty work by making as much noise and flashing as
>many lights as you can for several minutes before actually erasing the flash.
As I mentioned to someone else, I don't really think it is the boot
flash erase code that's doing it. I have seen what I *think* was the
same problem, happen without executing ANY code, and without the boot
code even loaded into memory.
jmk -----------------------------------------------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 jknox@jkno...
-----------------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
>I understand how frustrating this kind of problem can be. I have some war
>stories from previous employers.
>
>I don't have any really good ideas, but I have some far-fetched suggestions
>that you have probably have already tried.
Suggestions always appreciated. This is why some of the computer
user groups have "war story" sessions. Someone else's trials may
spark an idea, or worst case, even misery loves company. <G >Unfortunately, I don't have a reference, but I do have a memory of some
>reports a few years ago where there was reason to believe that spurious
>flash erasing was due to power supply glitches, or an out of spec clock.
Wouldn't surprise me... but I sure see everything looking just perfect.
>If there is an operator interface, you might be able to determine if your
>erase code is doing the dirty work by making as much noise and flashing as
>many lights as you can for several minutes before actually erasing the flash.
As I mentioned to someone else, I don't really think it is the boot
flash erase code that's doing it. I have seen what I *think* was the
same problem, happen without executing ANY code, and without the boot
code even loaded into memory.
jmk -----------------------------------------------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 jknox@jkno...
-----------------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: Back to "special" mode? - Jonathan Masters - Jul 11 22:50:00 2005
Jim,
Unfortunately I have had two cases in about 350 installations where I
have seen completely erased EEPROM. In that product, and erasure routine
is built in. I suspect that the chip is capable of erasing all by
itself, but have absolutely no evidence to support such an accusation ;(
Jonathan.
-----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of James M. Knox
Sent: Tuesday, 12 July 2005 12:43 PM
To: 68HC12@68HC...
Subject: RE: [68HC12] Back to "special" mode?
At 10:37 7/12/2005 +1000, you wrote >Perhaps this is a way to solve your problem - even if you only load the
>erase code over the link?
That's a thought that we had, and someone suggested, when the problem
first surfaced. But as best I can tell, when I tried that in a test
case, it didn't make any difference. [Part of the trouble is that it
only happens VERY rarely... hard to get any kind of convincing tests
under those circumstances.]
Frankly, I do NOT think that it is *in* the software. I think it is
some kind of "boot" condition in the processor itself. However, I've
had it happen on more than one board type. And I've checked reset,
oscillator (we have a real TTL oscillator that always starts cleanly,
and a nice motorola reset chip.
On two occasions I have even had the following happen:
o Erase Flash
o Program flash with P&E Prog12z
o Verify flash with P&E Prog12z
o exit Prog12z
o Start ICD12Z, reset -- no boot vector
o Look... flash is erased.
jmk -----------------------------------------------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 jknox@jkno...
-----------------------------------------------
_____
> Terms of Service.
_____
[Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Unfortunately I have had two cases in about 350 installations where I
have seen completely erased EEPROM. In that product, and erasure routine
is built in. I suspect that the chip is capable of erasing all by
itself, but have absolutely no evidence to support such an accusation ;(
Jonathan.
-----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of James M. Knox
Sent: Tuesday, 12 July 2005 12:43 PM
To: 68HC12@68HC...
Subject: RE: [68HC12] Back to "special" mode?
At 10:37 7/12/2005 +1000, you wrote >Perhaps this is a way to solve your problem - even if you only load the
>erase code over the link?
That's a thought that we had, and someone suggested, when the problem
first surfaced. But as best I can tell, when I tried that in a test
case, it didn't make any difference. [Part of the trouble is that it
only happens VERY rarely... hard to get any kind of convincing tests
under those circumstances.]
Frankly, I do NOT think that it is *in* the software. I think it is
some kind of "boot" condition in the processor itself. However, I've
had it happen on more than one board type. And I've checked reset,
oscillator (we have a real TTL oscillator that always starts cleanly,
and a nice motorola reset chip.
On two occasions I have even had the following happen:
o Erase Flash
o Program flash with P&E Prog12z
o Verify flash with P&E Prog12z
o exit Prog12z
o Start ICD12Z, reset -- no boot vector
o Look... flash is erased.
jmk -----------------------------------------------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 jknox@jkno...
-----------------------------------------------
_____
> Terms of Service.
_____
[Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Back to "special" mode? - theobee00 - Jul 12 18:59:00 2005
--- In 68HC12@68HC..., "Jonathan Masters" <jon@j...> wrote:
> Jim,
>
> Unfortunately I have had two cases in about 350 installations where I
> have seen completely erased EEPROM. In that product, and erasure routine
> is built in. I suspect that the chip is capable of erasing all by
> itself, but have absolutely no evidence to support such an accusation ;(
I have no flash erase routines built in and have never encountered erased flash.
I do remeber that somewhere in the ap notes it suggests not to leave unsused flash in FF condition, a runaway program would keep going through memory, replace code in unused area with something definite like SWI and trap this.
Cheers,
Theo
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
> Jim,
>
> Unfortunately I have had two cases in about 350 installations where I
> have seen completely erased EEPROM. In that product, and erasure routine
> is built in. I suspect that the chip is capable of erasing all by
> itself, but have absolutely no evidence to support such an accusation ;(
I have no flash erase routines built in and have never encountered erased flash.
I do remeber that somewhere in the ap notes it suggests not to leave unsused flash in FF condition, a runaway program would keep going through memory, replace code in unused area with something definite like SWI and trap this.
Cheers,
Theo
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: Re: Back to "special" mode? - Jonathan Masters - Jul 12 19:12:00 2005
Flash has never been a problem. EEPROM has. My own stupidity sometimes
accounts for the erasure of all sorts of memory - including my own :-)
-----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of theobee00
Sent: Wednesday, 13 July 2005 9:00 AM
To: 68HC12@68HC...
Subject: [68HC12] Re: Back to "special" mode?
--- In 68HC12@68HC..., "Jonathan Masters" <jon@j...> wrote:
> Jim,
>
> Unfortunately I have had two cases in about 350 installations where I
> have seen completely erased EEPROM. In that product, and erasure
routine
> is built in. I suspect that the chip is capable of erasing all by
> itself, but have absolutely no evidence to support such an accusation
;(
I have no flash erase routines built in and have never encountered
erased flash.
I do remeber that somewhere in the ap notes it suggests not to leave
unsused flash in FF condition, a runaway program would keep going
through memory, replace code in unused area with something definite like
SWI and trap this.
Cheers,
Theo
_____
> Terms of Service.
_____
[Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
accounts for the erasure of all sorts of memory - including my own :-)
-----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of theobee00
Sent: Wednesday, 13 July 2005 9:00 AM
To: 68HC12@68HC...
Subject: [68HC12] Re: Back to "special" mode?
--- In 68HC12@68HC..., "Jonathan Masters" <jon@j...> wrote:
> Jim,
>
> Unfortunately I have had two cases in about 350 installations where I
> have seen completely erased EEPROM. In that product, and erasure
routine
> is built in. I suspect that the chip is capable of erasing all by
> itself, but have absolutely no evidence to support such an accusation
;(
I have no flash erase routines built in and have never encountered
erased flash.
I do remeber that somewhere in the ap notes it suggests not to leave
unsused flash in FF condition, a runaway program would keep going
through memory, replace code in unused area with something definite like
SWI and trap this.
Cheers,
Theo
_____
> Terms of Service.
_____
[Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Back to "special" mode? - Jefferson Smith - Jul 12 19:19:00 2005
I don't remember all the details in the past, but I think you still
need to find out what's causing your problem before you spend any more
time trying to fix it.
In case you still want to guess, the big problem I see is that you
seem to have the 'fbulk' routine just waiting to be executed. It is so
easy to execute code accidently just by some other bug in the program.
What I think you need is a resident routine that only downloads a
small routine to RAM and executes it. Then your upgrade utility would
have to first sent the routine to the system which does the Bulk
erase. Then it can load the upgrade. If nothing else, at least when
you get back the non-working product you can test it to see if any
bits really were corrupted in Flash.
I think it is a fair guess also if some Flash has been corrupted, thus
causing your desired affect (bulk erase). I can picture this under
harsh conditions (radiation, temperature, shock).
In any case, it is a safe bet that the system is doing something you
did not expect it to do, so keep that in mind. And the more unlikely
the event, the less likely it is what is happening. --- In 68HC12@68HC..., "James M. Knox" <jknox@t...> wrote:
...
>
> That's basically what I have now. At boot (normal, single chip mode)
> a small piece of code checksums the application program and data
> tables. If it passes, then the FPOPEN bit is set to protect flash
> and control is passed to the application program. [This code, and
> the boot loader, run in the additionally protected $E000 region.]
>
> If the checksum does not pass, OR if it detects a special code
> sequence being sent ever the serial port, then control is passed to
> the boot loader.
>
> The problem is *RARELY* we are getting reports of the machine "not
> running." Analysis indicates that the flash where the application
> program runs (lower 28K) is erased. The boot loader is still in
> protected flash. At first I thought maybe application program was
> just "jumping" into the "erase flash" section of the boot loader...
> but that's VERY unlikely. There are all sorts of code checks around
> that code ("How did I get here?"). And that code is in the *wrong*
> space (the two flash sections are flipped), so it shouldn't run
regardless.
>
> Then I thought maybe somehow it was accidentally getting the erase
> command over the serial port. I've made that a long arbitrary
> string. Still happens.
>
> So I wanted to protect the Flash without regard to ANY code - i.e. it
> would take very special code to UNPROTECT the flash. That way,
> hopefully, even a questionable power up, low voltage, etc. shouldn't
> erase it. But... oh well.
>
> jmk > -----------------------------------------------
> James M. Knox
> TriSoft ph 512-385-0316
> 1300 Koenig Lane West fax 512-371-5716
> Suite 200
> Austin, Tx 78756 jknox@t...
> -----------------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
need to find out what's causing your problem before you spend any more
time trying to fix it.
In case you still want to guess, the big problem I see is that you
seem to have the 'fbulk' routine just waiting to be executed. It is so
easy to execute code accidently just by some other bug in the program.
What I think you need is a resident routine that only downloads a
small routine to RAM and executes it. Then your upgrade utility would
have to first sent the routine to the system which does the Bulk
erase. Then it can load the upgrade. If nothing else, at least when
you get back the non-working product you can test it to see if any
bits really were corrupted in Flash.
I think it is a fair guess also if some Flash has been corrupted, thus
causing your desired affect (bulk erase). I can picture this under
harsh conditions (radiation, temperature, shock).
In any case, it is a safe bet that the system is doing something you
did not expect it to do, so keep that in mind. And the more unlikely
the event, the less likely it is what is happening. --- In 68HC12@68HC..., "James M. Knox" <jknox@t...> wrote:
...
>
> That's basically what I have now. At boot (normal, single chip mode)
> a small piece of code checksums the application program and data
> tables. If it passes, then the FPOPEN bit is set to protect flash
> and control is passed to the application program. [This code, and
> the boot loader, run in the additionally protected $E000 region.]
>
> If the checksum does not pass, OR if it detects a special code
> sequence being sent ever the serial port, then control is passed to
> the boot loader.
>
> The problem is *RARELY* we are getting reports of the machine "not
> running." Analysis indicates that the flash where the application
> program runs (lower 28K) is erased. The boot loader is still in
> protected flash. At first I thought maybe application program was
> just "jumping" into the "erase flash" section of the boot loader...
> but that's VERY unlikely. There are all sorts of code checks around
> that code ("How did I get here?"). And that code is in the *wrong*
> space (the two flash sections are flipped), so it shouldn't run
regardless.
>
> Then I thought maybe somehow it was accidentally getting the erase
> command over the serial port. I've made that a long arbitrary
> string. Still happens.
>
> So I wanted to protect the Flash without regard to ANY code - i.e. it
> would take very special code to UNPROTECT the flash. That way,
> hopefully, even a questionable power up, low voltage, etc. shouldn't
> erase it. But... oh well.
>
> jmk > -----------------------------------------------
> James M. Knox
> TriSoft ph 512-385-0316
> 1300 Koenig Lane West fax 512-371-5716
> Suite 200
> Austin, Tx 78756 jknox@t...
> -----------------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Vector table? - hc12meyer - Jul 13 9:23:00 2005
Would this work: (Trying jump to secondary table )
primary vector table:
=================
/* Vector table*/
#pragma abs_address:0xFF88
void (*interrupt_vectors[])() = {
INT_VECTOR_01, /* 0xFF88 - 0xFF89: PWM - Emergency Shutdown */
INT_VECTOR_02, /* 0xFF8A - 0xFF8B: VREG LVI */
......
void INT_VECTOR_01(void) { CallInt(0x00) }
void INT_VECTOR_02(void) { CallInt(0x02) }
ISR routine:
============
void CallIsr(offset) {
/* itable parameter contains the secondary table starting address
i.e. itable = 0xFC00 */
asm("jmp [itable + offset]");
} Seconary table:
===============
#pragma abs_address:0xFC00
const void *Pwm = IntPwm;
const void *Vreg = IntVreg;
...
#pragma end_abs_address
void IntPwm(void) {
/* handle the ISR */
}
--- In 68HC12@68HC..., "Stephen Trier" <sct@p...> wrote:
> Meyer,
>
> That won't work. The CPU's vector table is a list of function
pointers,
> two bytes each. The CPU looks up a pointer, sets the program
counter
> to it, and starts executing there. Each pointer in the table has to
> reference valid executable code. You can't point it at another
pointer.
>
> Thus, your second table needs to be code, not an array of function
> pointers. If you use assembly, you can make it a bunch of JMP
> instructions. If you use C, point the first table at a bunch of C
> functions, which then call the functions you want to have actually
> handle the interrupt.
>
> The typecasts you have in the first table are a sign of the problem.
> You shouldn't need to do the very dangerous operation of casting
integers
> into function pointers if you have things set up right.
>
> Stephen
>
> --
> Stephen Trier
> Technical Development Lab
> Cleveland FES Center
> sct@p...
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
primary vector table:
=================
/* Vector table*/
#pragma abs_address:0xFF88
void (*interrupt_vectors[])() = {
INT_VECTOR_01, /* 0xFF88 - 0xFF89: PWM - Emergency Shutdown */
INT_VECTOR_02, /* 0xFF8A - 0xFF8B: VREG LVI */
......
void INT_VECTOR_01(void) { CallInt(0x00) }
void INT_VECTOR_02(void) { CallInt(0x02) }
ISR routine:
============
void CallIsr(offset) {
/* itable parameter contains the secondary table starting address
i.e. itable = 0xFC00 */
asm("jmp [itable + offset]");
} Seconary table:
===============
#pragma abs_address:0xFC00
const void *Pwm = IntPwm;
const void *Vreg = IntVreg;
...
#pragma end_abs_address
void IntPwm(void) {
/* handle the ISR */
}
--- In 68HC12@68HC..., "Stephen Trier" <sct@p...> wrote:
> Meyer,
>
> That won't work. The CPU's vector table is a list of function
pointers,
> two bytes each. The CPU looks up a pointer, sets the program
counter
> to it, and starts executing there. Each pointer in the table has to
> reference valid executable code. You can't point it at another
pointer.
>
> Thus, your second table needs to be code, not an array of function
> pointers. If you use assembly, you can make it a bunch of JMP
> instructions. If you use C, point the first table at a bunch of C
> functions, which then call the functions you want to have actually
> handle the interrupt.
>
> The typecasts you have in the first table are a sign of the problem.
> You shouldn't need to do the very dangerous operation of casting
integers
> into function pointers if you have things set up right.
>
> Stephen
>
> --
> Stephen Trier
> Technical Development Lab
> Cleveland FES Center
> sct@p...
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )