Illegal Address Reset on S12X

I use an S12X in SingleChip mode, and my application occasionally
resets. After long hours of investigation, it could be established that
(a) it's an illegal address reset, and (b) it happens on a specific RTC
instruction. I introduced some debug code that allowed me to know the SP
contents at that instruction, however, the stack pointer correctly
points to the return address (1 byte page plus 2 bytes address). So I
see no reason for the illegal address reset.

To be clear : the RTC instruction runs correctly several hundred times
over, but after 10-15 minutes, the reset occurs.

Does anybody have experience with this? Or other suggestions?

Thanks in advance,
Georg Start a New Thread

Whatcompiler are you using? Also do you have the PPAGE register enabled in thecompiler options? What chip is it? And lastly check that you are not blowingthe stack away or over running it (Make sure it is large enough for all thereturn addresses). Is the program small enough to post on here so others canlook / try to duplicate?

Tim

-----Original Message-----
From: 6...[mailto:6...] On Behalf Of Profos,Georg
Sent: Friday, May 25, 2007 11:31AM
To: 6...
Subject: [68HC12] Illegal AddressReset on S12X

I use an S12X in SingleChip mode, and my applicationoccasionally
resets. After long hours of investigation, it could be established that
(a) it's an illegal address reset, and (b) it happens on a specific RTC
instruction. I introduced some debug code that allowed me to know the SP
contents at that instruction, however, the stack pointer correctly
points to the return address (1 byte page plus 2 bytes address). So I
see no reason for the illegal address reset.

To be clear : the RTC instruction runs correctly several hundred times
over, but after 10-15 minutes, the reset occurs.

Does anybody have experience with this? Or other suggestions?

Thanks in advance,
Georg

---------------------------------
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list. Start a New Thread

Profos, Georg wrote:

>I use an S12X in SingleChip mode, and my application occasionally
> resets. After long hours of investigation, it could be established that
> (a) it's an illegal address reset, and (b) it happens on a specific RTC
> instruction. I introduced some debug code that allowed me to know the SP
> contents at that instruction, however, the stack pointer correctly
> points to the return address (1 byte page plus 2 bytes address). So I
> see no reason for the illegal address reset.
>

S12X illegal address reset in single chip mode happens when CPU makes an
read or write access to notimplemented locations. It could be RAM page set
to not available RAM page or EPAGE set to not available eeprom page. Also it
could be something wrong with GPAGE accesses, wrong GPAGE or good GPAGE but
bad glxx instruction ofset pointing to not existing location below the RAM
or EEPROM. BTW if both, main thread and interrupts are using global
addressing mode and do change the GPAGE then it's obvious that interrupts
should save-restore GPAGE. The same may apply to preemptive RTOSes.

Edward
> To be clear : the RTC instruction runs correctly several hundred times
> over, but after 10-15 minutes, the reset occurs.

> Does anybody have experience with this? Or other suggestions?
>
> Thanks in advance,
> Georg
>
> Yahoo! Groups Links Start a New Thread

Hi,

As per your information i understand that your
application is gets reset but it doesnot crash,if you
doubt it as illegal address reset then you can confirm
that if controller has any register which stores the
status which caused the reset,or dont program the
vector for "illegal address reset" so if that is the
source of reset your application should crash or use
LEDs for debugging and program that module address as
the vector..,one more thing to check for would be
Watchdog timer, also verify all the sources of reset
in the controller data sheet.

Have a nice day..

Thanks,
Sreedhar.K
--- "Profos, Georg" wrote:

> I use an S12X in SingleChip mode, and my application
> occasionally
> resets. After long hours of investigation, it could
> be established that
> (a) it's an illegal address reset, and (b) it
> happens on a specific RTC
> instruction. I introduced some debug code that
> allowed me to know the SP
> contents at that instruction, however, the stack
> pointer correctly
> points to the return address (1 byte page plus 2
> bytes address). So I
> see no reason for the illegal address reset.
>
> To be clear : the RTC instruction runs correctly
> several hundred times
> over, but after 10-15 minutes, the reset occurs.
>
> Does anybody have experience with this? Or other
> suggestions?
>
> Thanks in advance,
> Georg
>

____________________________________________________________________________________
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265 Start a New Thread

kundella sreedhar wrote:

> Hi,
>
> As per your information i understand that your
> application is gets reset but it doesnot crash,if you
> doubt it as illegal address reset then you can confirm
> that if controller has any register which stores the
> status which caused the reset,or dont program the
> vector for "illegal address reset" so if that is the

There's no separate vector for "illegal address reset". It's the same famous
vector at FFFE that is used also for power on reset and external reset .

Oh, there's ILAF (illegal address reset flag) bit in CRGINT register in XD
family and ILAF bit in CRGFLG register in XE family. It should say if it was
illegal address reset or not.

Edward
> source of reset your application should crash or use
> LEDs for debugging and program that module address as
> the vector..,one more thing to check for would be
> Watchdog timer, also verify all the sources of reset
> in the controller data sheet.
>
> Have a nice day..
>
> Thanks,
> Sreedhar.K
> --- "Profos, Georg" wrote:
>
>> I use an S12X in SingleChip mode, and my application
>> occasionally
>> resets. After long hours of investigation, it could
>> be established that
>> (a) it's an illegal address reset, and (b) it
>> happens on a specific RTC
>> instruction. I introduced some debug code that
>> allowed me to know the SP
>> contents at that instruction, however, the stack
>> pointer correctly
>> points to the return address (1 byte page plus 2
>> bytes address). So I
>> see no reason for the illegal address reset.
>>
>> To be clear : the RTC instruction runs correctly
>> several hundred times
>> over, but after 10-15 minutes, the reset occurs.
>>
>> Does anybody have experience with this? Or other
>> suggestions?
>>
>> Thanks in advance,
>> Georg
>>
> ____________________________________________________________________________________
> We won't tell. Get more on shows you hate to love
> (and love to hate): Yahoo! TV's Guilty Pleasures list.
> http://tv.yahoo.com/collections/265
>
> Yahoo! Groups Links Start a New Thread

Many thanks for your numerous comments. Indeed, I think Edward might
have a point when he suggests GPAGE to be saved/restored during my ISR.
But that is hardly what causes my problem, the problem occurs at an RTC
instruciton which does not relate to global addressing, as far as I
know.

What I did is :
1. I changed the reset vector so that any reset runs into an endless
loop, so RAM is not modified after the reset.
2. Since I know where the reset occurs (a specific RTC instruction), I
store the stack pointer to a location in RAM just before that
instruction, so I know where the SP was before the RTC instruction that
is giving problems.
3. Now I wait for the reset to occur, which I can see from a terminal
that's connected to the board. I am using the FREESCALE S12X Demo board
by the way, and CodeWarrior 4.5.
4. The reset comes, and I see that indeed ILAF is set to 1.
5. Now I look at the Stack Pointer (the saved one, I mean, since the
reset sets SP to 0) and see that it points to a perfectly legal three
byte address (that is, PPAGE and 16 bit local) : FE 8C C4, 0xFE being
the page reg I suppose, and 8C C4 pointing to the correct location where
i would want my RTC to jump back to. BTW The SP was at 0x24F6, and the
SP high limit is at 0x2500, so all ok.
6. So I really see no reason why the RTC should go wrong...?

I think it must relate to PPAGE since RTC only modifies PPAGE, not EPAGE
and not RPAGE. But I simply can't see any illegal access :-()

Any further suggestions are welcome!

Once again many thanks for your contributions!

Georg

________________________________

Von: 6... [mailto:6...] Im Auftrag
von Edward Karpicz
Gesendet: Samstag, 26. Mai 2007 07:11
An: 6...
Betreff: Re: [68HC12] Illegal Address Reset on S12X

kundella sreedhar wrote:

> Hi,
>
> As per your information i understand that your
> application is gets reset but it doesnot crash,if you
> doubt it as illegal address reset then you can confirm
> that if controller has any register which stores the
> status which caused the reset,or dont program the
> vector for "illegal address reset" so if that is the

There's no separate vector for "illegal address reset". It's the same
famous
vector at FFFE that is used also for power on reset and external reset .

Oh, there's ILAF (illegal address reset flag) bit in CRGINT register in
XD
family and ILAF bit in CRGFLG register in XE family. It should say if it
was
illegal address reset or not.

Edward

> source of reset your application should crash or use
> LEDs for debugging and program that module address as
> the vector..,one more thing to check for would be
> Watchdog timer, also verify all the sources of reset
> in the controller data sheet.
>
> Have a nice day..
>
> Thanks,
> Sreedhar.K
> --- "Profos, Georg" > wrote:
>
>> I use an S12X in SingleChip mode, and my application
>> occasionally
>> resets. After long hours of investigation, it could
>> be established that
>> (a) it's an illegal address reset, and (b) it
>> happens on a specific RTC
>> instruction. I introduced some debug code that
>> allowed me to know the SP
>> contents at that instruction, however, the stack
>> pointer correctly
>> points to the return address (1 byte page plus 2
>> bytes address). So I
>> see no reason for the illegal address reset.
>>
>> To be clear : the RTC instruction runs correctly
>> several hundred times
>> over, but after 10-15 minutes, the reset occurs.
>>
>> Does anybody have experience with this? Or other
>> suggestions?
>>
>> Thanks in advance,
>> Georg
>>
> __________________________________________________________
> We won't tell. Get more on shows you hate to love
> (and love to hate): Yahoo! TV's Guilty Pleasures list.
> http://tv.yahoo.com/collections/265
Yahoo! Groups Links Start a New Thread

Profos, Georg wrote:

> Many thanks for your numerous comments. Indeed, I think Edward might
> have a point when he suggests GPAGE to be saved/restored during my ISR.
> But that is hardly what causes my problem, the problem occurs at an RTC
> instruciton which does not relate to global addressing, as far as I
> know.

That's right, RTC doeesn't relate to GPAGE.

>
> What I did is :
> 1. I changed the reset vector so that any reset runs into an endless
> loop, so RAM is not modified after the reset.
> 2. Since I know where the reset occurs (a specific RTC instruction), I
> store the stack pointer to a location in RAM just before that
> instruction, so I know where the SP was before the RTC instruction that
> is giving problems.
Did you try to single step through this RTC? If RTC causes ILAF reset then
you should see bad bahaviour also in special single chip mode.
> 3. Now I wait for the reset to occur, which I can see from a terminal
> that's connected to the board. I am using the FREESCALE S12X Demo board
> by the way, and CodeWarrior 4.5.
> 4. The reset comes, and I see that indeed ILAF is set to 1.
> 5. Now I look at the Stack Pointer (the saved one, I mean, since the
> reset sets SP to 0) and see that it points to a perfectly legal three
> byte address (that is, PPAGE and 16 bit local) : FE 8C C4, 0xFE being
> the page reg I suppose, and 8C C4 pointing to the correct location where
> i would want my RTC to jump back to. BTW The SP was at 0x24F6, and the
> SP high limit is at 0x2500, so all ok.
> 6. So I really see no reason why the RTC should go wrong...?
>
> I think it must relate to PPAGE since RTC only modifies PPAGE, not EPAGE
> and not RPAGE. But I simply can't see any illegal access :-()
>

XDP512 datasheet v2.15, on page 636 there are listed the cases of ILAF
reset. If you are not touching RPAGE and EPAGE and also aren't using global
addressing then maybe this one:
"Misaligned word accesses to the last location (top address) of the on-chip
RAM by the CPU is ignored in expanded modes (read of undefined data). In
single-chip modes these accesses result in an illegal access reset (except
firmware commands)."
This means you can't read/write the word from/to 0x3FFF:0x4000. Could this
take place in your code?

Also there's:

"Misaligned word accesses to the last location (Top address) of any of the
on-chip resource blocks (except RAM) by the CPU is performed in expanded
modes. In single-chip modes these accesses (except Flash) result in an
illegal access reset (except firmware commands)."
I can confirm ILAF is generated by reading a word from 3FFF:4000 (misaligned
access to the top of RAM), but I can't confirm ILAF reset happening when
reading the word from the registers-EEPROM and EEPROM-RAM boundary. Hm,
weird

> Any further suggestions are welcome!
Reduce your code to something not "copy-sensitive" but still showing the
problem and post it here.
Oh, I gues you have interrupts enabled? Do you have proper handler for
spurious interrupt?

Edward

>
> Once again many thanks for your contributions!
>
> Georg
>
> ________________________________
>
> Von: 6... [mailto:6...] Im Auftrag
> von Edward Karpicz
> Gesendet: Samstag, 26. Mai 2007 07:11
> An: 6...
> Betreff: Re: [68HC12] Illegal Address Reset on S12X
>
> kundella sreedhar wrote:
>
>> Hi,
>>
>> As per your information i understand that your
>> application is gets reset but it doesnot crash,if you
>> doubt it as illegal address reset then you can confirm
>> that if controller has any register which stores the
>> status which caused the reset,or dont program the
>> vector for "illegal address reset" so if that is the
>
> There's no separate vector for "illegal address reset". It's the same
> famous
> vector at FFFE that is used also for power on reset and external reset .
>
> Oh, there's ILAF (illegal address reset flag) bit in CRGINT register in
> XD
> family and ILAF bit in CRGFLG register in XE family. It should say if it
> was
> illegal address reset or not.
>
> Edward
>
>> source of reset your application should crash or use
>> LEDs for debugging and program that module address as
>> the vector..,one more thing to check for would be
>> Watchdog timer, also verify all the sources of reset
>> in the controller data sheet.
>>
>> Have a nice day..
>>
>> Thanks,
>> Sreedhar.K
>> --- "Profos, Georg" > > wrote:
>>
>>> I use an S12X in SingleChip mode, and my application
>>> occasionally
>>> resets. After long hours of investigation, it could
>>> be established that
>>> (a) it's an illegal address reset, and (b) it
>>> happens on a specific RTC
>>> instruction. I introduced some debug code that
>>> allowed me to know the SP
>>> contents at that instruction, however, the stack
>>> pointer correctly
>>> points to the return address (1 byte page plus 2
>>> bytes address). So I
>>> see no reason for the illegal address reset.
>>>
>>> To be clear : the RTC instruction runs correctly
>>> several hundred times
>>> over, but after 10-15 minutes, the reset occurs.
>>>
>>> Does anybody have experience with this? Or other
>>> suggestions?
>>>
>>> Thanks in advance,
>>> Georg
>>>
>> __________________________________________________________
>> We won't tell. Get more on shows you hate to love
>> (and love to hate): Yahoo! TV's Guilty Pleasures list.
>> http://tv.yahoo.com/collections/265
>
>>
>> Yahoo! Groups Links
>
> Yahoo! Groups Links Start a New Thread

Many thanks, again.

1. I did another test in the mean time, by setting my board to "expanded
mode". The software ran, and ran, and ran... of course, we suppress the
illegal access interrupt like this, but if there _really_ is an illegal
access, one would expect the software to malfunction, right? But this
did not happen, so I'm somewhat in doubt whether I should really believe
that there was an illegal access...
2. Is the illegal access reset by an access on the main CPU only, or can
it also come from an access on the XGATE?
3. Since I don't know in advance when my RTC will crash, I can't single
step it - as I said, it works correctly hundreds of times, but
suddenly...
4. Yes, Interrupts are indeed enabled, and I'm adding a spurious
interrupt vector now @FF10 now, I had forgotten that. Some interrupts
are handled on XGATE, some on the main CPU.

Is there a debug option (in the truetime debugger) to break on illegal
access, or something like that? I use CW Standard edition, 4.5. Program
is done in C language.

regards,
Georg

________________________________

Von: 6... [mailto:6...] Im Auftrag
von Edward Karpicz
Gesendet: Dienstag, 29. Mai 2007 14:38
An: 6...
Betreff: Re: [68HC12] Illegal Address Reset on S12X

Profos, Georg wrote:

> Many thanks for your numerous comments. Indeed, I think Edward might
> have a point when he suggests GPAGE to be saved/restored during my
ISR.
> But that is hardly what causes my problem, the problem occurs at an
RTC
> instruciton which does not relate to global addressing, as far as I
> know.

That's right, RTC doeesn't relate to GPAGE.

>
> What I did is :
> 1. I changed the reset vector so that any reset runs into an endless
> loop, so RAM is not modified after the reset.
> 2. Since I know where the reset occurs (a specific RTC instruction), I
> store the stack pointer to a location in RAM just before that
> instruction, so I know where the SP was before the RTC instruction
that
> is giving problems.

Did you try to single step through this RTC? If RTC causes ILAF reset
then
you should see bad bahaviour also in special single chip mode.

> 3. Now I wait for the reset to occur, which I can see from a terminal
> that's connected to the board. I am using the FREESCALE S12X Demo
board
> by the way, and CodeWarrior 4.5.
> 4. The reset comes, and I see that indeed ILAF is set to 1.
> 5. Now I look at the Stack Pointer (the saved one, I mean, since the
> reset sets SP to 0) and see that it points to a perfectly legal three
> byte address (that is, PPAGE and 16 bit local) : FE 8C C4, 0xFE being
> the page reg I suppose, and 8C C4 pointing to the correct location
where
> i would want my RTC to jump back to. BTW The SP was at 0x24F6, and the
> SP high limit is at 0x2500, so all ok.
> 6. So I really see no reason why the RTC should go wrong...?
>
> I think it must relate to PPAGE since RTC only modifies PPAGE, not
EPAGE
> and not RPAGE. But I simply can't see any illegal access :-()
>

XDP512 datasheet v2.15, on page 636 there are listed the cases of ILAF
reset. If you are not touching RPAGE and EPAGE and also aren't using
global
addressing then maybe this one:
"Misaligned word accesses to the last location (top address) of the
on-chip
RAM by the CPU is ignored in expanded modes (read of undefined data). In

single-chip modes these accesses result in an illegal access reset
(except
firmware commands)."

This means you can't read/write the word from/to 0x3FFF:0x4000. Could
this
take place in your code?

Also there's:

"Misaligned word accesses to the last location (Top address) of any of
the
on-chip resource blocks (except RAM) by the CPU is performed in expanded

modes. In single-chip modes these accesses (except Flash) result in an
illegal access reset (except firmware commands)."

I can confirm ILAF is generated by reading a word from 3FFF:4000
(misaligned
access to the top of RAM), but I can't confirm ILAF reset happening when

reading the word from the registers-EEPROM and EEPROM-RAM boundary. Hm,
weird

> Any further suggestions are welcome!

Reduce your code to something not "copy-sensitive" but still showing the

problem and post it here.
Oh, I gues you have interrupts enabled? Do you have proper handler for
spurious interrupt?

Edward

>
> Once again many thanks for your contributions!
>
> Georg
>
> ________________________________
>
> Von: 6...


















''




'


























'




















'
'






Start a New Thread

--- In 6..., "Profos, Georg" wrote:
> 1. I did another test in the mean time, by setting my board to
> "expanded mode". The software ran, and ran, and ran... of course, we
> suppress the illegal access interrupt like this, but if there
> _really_ is an illegal access, one would expect the software to
> malfunction, right? But this did not happen, so I'm somewhat in
> doubt whether I should really believe that there was an illegal
> access...

I can't see where you mentioned what might be different between your
test in single-chip and in expanded mode. I can see many scenareos
where something you didn't think of would change, so you may not be
getting good clues by the test. I don't see whether you are using an
external ROM for your program, an emulation board, or what.

But nevermind that; I certainly would say that the problem I've had
many times using FreeRTOS was exactly this problem, though using an
RTOS made it even more complicated to troubleshoot. It is obvious to
me that something has overwritten your program stack. The result is,
at the time of overwrite (which is usually not very often), the return
address was lost, so the next RTC, RTS, RTI, etc. will fail because it
will return to a seemingly random address (whatever value was just
written in it's place).

My solution was to monitor stack size(s) before the failure. I always
found that a stack was either overflowed already, or almost
overflowed. If I were a betting man (which I'm not), I'd bet you need
more stack space, or to use less. Start a New Thread

Many thanks for your contributions.

1. The problem is definitely not in the stack, because, as I wrote, I
saved the stack pointer to RAM before the instruction that fails, so I
can see where it pointed. Also, the reset vector points into an endless
loop, so on reset the RAM contents is fully preserved for "post mortem"
analysis. SP pointed to the correct return address (1 byte page plus 2
bytes address) in all cases.
2. I use the Freescale HCS12X Demo Board, which has no external memory.
So using single chip mode would be the natural choice - I used expanded
mode just as a test, because the illegal-access reset does not exist in
that mode. I found the software to function perfectly - which I took as
an indicator that there really isn't any illegal access taking place
(but that judgement of mine might have been premature...).
3. In the meantime, I removed a piece of code from my software,
_absolutely nowhere near the instruction which fails_ (!!) and the
problem disappeared... interesting...

==> Is there some kind of latency time in the illegal-access reset? I
mean, how much time elapses between the illegal access and the reset? Is
it possible, that after the illegal access, the CPU continues to execute
quite a number of instructions before the illegal access reset?

regards,
Georg

________________________________

Von: 6... [mailto:6...] Im Auftrag
von Jefferson Smith
Gesendet: Donnerstag, 31. Mai 2007 00:25
An: 6...
Betreff: [68HC12] Re: Illegal Address Reset on S12X

--- In 6...





'



'

'
'


'






'



''
Start a New Thread