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

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



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

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...@yahoogroups.com[mailto:6...@yahoogroups.com] On Behalf Of Profos,Georg
Sent: Friday, May 25, 2007 11:31AM
To: 6...@yahoogroups.com
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.

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

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



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

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



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

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



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

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...@yahoogroups.com [mailto:6...@yahoogroups.com] Im Auftrag
von Edward Karpicz
Gesendet: Samstag, 26. Mai 2007 07:11
An: 6...@yahoogroups.com
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

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

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...@yahoogroups.com [mailto:6...@yahoogroups.com] Im Auftrag
> von Edward Karpicz
> Gesendet: Samstag, 26. Mai 2007 07:11
> An: 6...@yahoogroups.com
> 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
> [Non-text portions of this message have been removed]
> Yahoo! Groups Links



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

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...@yahoogroups.com [mailto:6...@yahoogroups.com] Im Auftrag
von Edward Karpicz
Gesendet: Dienstag, 29. Mai 2007 14:38
An: 6...@yahoogroups.com
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...@yahoogroups.com
[mailto:6...@yahoogroups.com ] Im
Auftrag
> von Edward Karpicz
> Gesendet: Samstag, 26. Mai 2007 07:11
> An: 6...@yahoogroups.com
> 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
> [Non-text portions of this message have been removed]
> Yahoo! Groups Links

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

--- In 6...@yahoogroups.com, "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.



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

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...@yahoogroups.com [mailto:6...@yahoogroups.com] Im Auftrag
von Jefferson Smith
Gesendet: Donnerstag, 31. Mai 2007 00:25
An: 6...@yahoogroups.com
Betreff: [68HC12] Re: Illegal Address Reset on S12X

--- In 6...@yahoogroups.com ,
"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.

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

Hi,
Did you disassambled the file and checked out the .asm code, before and
after removing that piece of code ?
I had similar problems in CW, solved only by introducing dummy code
line between two others !
Regards,
Yoan

Profos, Georg wrote:
>
> 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...@yahoogroups.com
> [mailto:6...@yahoogroups.com ] Im
> Auftrag
> von Jefferson Smith
> Gesendet: Donnerstag, 31. Mai 2007 00:25
> An: 6...@yahoogroups.com
> Betreff: [68HC12] Re: Illegal Address Reset on S12X
>
> --- In 6...@yahoogroups.com
> ,
> "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.
>
> [Non-text portions of this message have been removed]
>
>
[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 )

Hi Georg,

Just in case you haven't already checked, have you checked
to make sure your power supply is ok ?

Regards,
Darren
> -----Original Message-----
> From: 6...@yahoogroups.com [mailto:6...@yahoogroups.com]
> On Behalf Of Profos, Georg
>
> 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


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Profos, Georg wrote:

> 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

Reads of random addresses usually aren't destructive. Also you may write
(not program) something to flash/ROM/EEPROM as often as you want without any
damage. Writes to rarely used RAM variables also can be difficult to notice.
Murphy's laws
> 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?

AFAIK only CPU12X can cause illegal access reset. XGATE is treated as
peripheral and (again AFAIK) its misaligned word accesses or attempt to run
the code in the register space (oops) should generate XGATE software error
interrupt. This interrupt is to be handled by CPU12X only. XGATE should
freeze on its illegal accesses. Note that Demos12xdt512 has 32k of RAM and
there is no single unimplemented word in the XGATE memory space.

It's bad that CPU12X illegal access behaviour is fixed to reset only. Option
to interrupt on it would be much better. And since it's fixed to reset
only - you are pushed a bit to try to run your code in simulator or use full
featured but costly emulator.

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

Too bad. Could it be some uninitialized pointer variable on stack?

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

How can it break on reset? After reset all context is lost, no PC, no SP (as
you know SP gets zeroed on reset). Debugger could tell you it's illegal
address reset (by reading ILAF bit :-) but can't tell you what caused it
and were.

Edward

>
> regards,
> Georg
>
> ________________________________
>
> Von: 6...@yahoogroups.com [mailto:6...@yahoogroups.com] Im Auftrag
> von Edward Karpicz
> Gesendet: Dienstag, 29. Mai 2007 14:38
> An: 6...@yahoogroups.com
> 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...@yahoogroups.com
> [mailto:6...@yahoogroups.com ] Im
> Auftrag
>> von Edward Karpicz
>> Gesendet: Samstag, 26. Mai 2007 07:11
>> An: 6...@yahoogroups.com
>> 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
>>>
>>>
>>>
>>>
>> [Non-text portions of this message have been removed]
>> Yahoo! Groups Links
> [Non-text portions of this message have been removed]
> Yahoo! Groups Links



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, Ioan Petrescu wrote:
>
> Hi,
> Did you disassambled the file and checked out the .asm code, before and
> after removing that piece of code ?
> I had similar problems in CW, solved only by introducing dummy code
> line between two others !
> Regards,
> Yoan

Hello,

1.Looking at the ASM is indeed a good idea to make sure the compiler
did its job properly.

2.You can also check in the Memory window of the debugger that the
Software in the MCU memory matches what you programmed to rule out any
flash cell worn out.

3. Reset is immediate and 'resets' most registers but not all. As you
know where the fault occurs, you can trigger the Debug module to trace
the execution.
A reset does 'reset' the configuration of the Debug module, however it
keeps the content of the trace to allow tracing through Reset.

4. What memory model are you using and when you remove the piece of
code, does it change the compilation of the code which fails.

5. Please confirm you have assigned ALL CPU interrupt vectors to a
valid program address.

I like when things are weird.

Regards,
Alban.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Alban wrote:

> 3. Reset is immediate and 'resets' most registers but not all. As you
> know where the fault occurs, you can trigger the Debug module to trace
> the execution.
> A reset does 'reset' the configuration of the Debug module, however it
> keeps the content of the trace to allow tracing through Reset.
>

Is there some HOWTO or AN describing how to trace through reset with CW 4.5
and USB Multilink? After I hit reset or do intentional illegal access
reset - I see trace emptied. I don't see any option in multilink or in
trigger settings that could help tracing through reset. Is CW 4.6 better at
this?

Thanks
Edward



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, "Edward Karpicz" wrote:
>
> Alban wrote:
>
> > 3. Reset is immediate and 'resets' most registers but not all. As you
> > know where the fault occurs, you can trigger the Debug module to trace
> > the execution.
> > A reset does 'reset' the configuration of the Debug module, however it
> > keeps the content of the trace to allow tracing through Reset.
> > Is there some HOWTO or AN describing how to trace through reset with
CW 4.5
> and USB Multilink? After I hit reset or do intentional illegal access
> reset - I see trace emptied. I don't see any option in multilink or in
> trigger settings that could help tracing through reset. Is CW 4.6
better at
> this?
>
> Thanks
> Edward

Hi Edward,
Not that I know of.
The registers will be emptied/reseted.
However the buffer itself is not affected by a illegal address reset.

May be you need to reconfigure the module as it was before the reset
to access the trace. I cannot assure it.
I know the principle works but have not tried myself yet.

Alban.



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

i know that the SC0 port of the dragon 12 board is being used for RS232 interface. But i Desperately need to use it for reception. is there any way around for my problem?

regards
swapna

Alban wrote: --- In 6...@yahoogroups.com, "Edward Karpicz" wrote:
>
> Alban wrote:
>
> > 3. Reset is immediate and 'resets' most registers but not all. As you
> > know where the fault occurs, you can trigger the Debug module to trace
> > the execution.
> > A reset does 'reset' the configuration of the Debug module, however it
> > keeps the content of the trace to allow tracing through Reset.
> >
>
> Is there some HOWTO or AN describing how to trace through reset with
CW 4.5
> and USB Multilink? After I hit reset or do intentional illegal access
> reset - I see trace emptied. I don't see any option in multilink or in
> trigger settings that could help tracing through reset. Is CW 4.6
better at
> this?
>
> Thanks
> Edward

Hi Edward,
Not that I know of.
The registers will be emptied/reseted.
However the buffer itself is not affected by a illegal address reset.

May be you need to reconfigure the module as it was before the reset
to access the trace. I cannot assure it.
I know the principle works but have not tried myself yet.

Alban.

---------------------------------
Don't get soaked. Take a quick peak at the forecast
with theYahoo! Search weather shortcut.

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

--- In 6...@yahoogroups.com, swapna gurumani wrote:
>
> i know that the SC0 port of the dragon 12 board is being used for
RS232 interface. But i Desperately need to use it for reception. is
there any way around for my problem?

This is a 2-way serial port. You can send and receive with the same
port. What are you trying to receive?


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Hello Everyone,
I'm trying to use the I2C on the 9S12XDP512, to communicate with an
FRAM, RTC/processor companion chip.
I have initialized the I2C registers, set the priority of the interrupt,
and yet the interrupt does not go off.
What am I missing, any suggestions are welcomed.
Thanks in advance.
Michael Burgess
[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 )

The SC0 port is used by the D-Bug12 monitor to communicate. Remove it
and both SC0 and SC1 are yours to utilize.

Henry W. Bayer IIII

DeVry University

407-355-4780

h...@orl.devry.edu

________________________________

From: 6...@yahoogroups.com [mailto:6...@yahoogroups.com] On Behalf
Of swapna gurumani
Sent: Monday, June 11, 2007 2:31 PM
To: 6...@yahoogroups.com
Subject: [68HC12] receive on SC0 of Dragon12 board

i know that the SC0 port of the dragon 12 board is being used for RS232
interface. But i Desperately need to use it for reception. is there any
way around for my problem?

regards
swapna

Alban > wrote: --- In
6...@yahoogroups.com , "Edward
Karpicz" wrote:
>
> Alban wrote:
>
> > 3. Reset is immediate and 'resets' most registers but not all. As
you
> > know where the fault occurs, you can trigger the Debug module to
trace
> > the execution.
> > A reset does 'reset' the configuration of the Debug module, however
it
> > keeps the content of the trace to allow tracing through Reset.
> > Is there some HOWTO or AN describing how to trace through reset with
CW 4.5
> and USB Multilink? After I hit reset or do intentional illegal access
> reset - I see trace emptied. I don't see any option in multilink or in

> trigger settings that could help tracing through reset. Is CW 4.6
better at
> this?
>
> Thanks
> Edward

Hi Edward,
Not that I know of.
The registers will be emptied/reseted.
However the buffer itself is not affected by a illegal address reset.

May be you need to reconfigure the module as it was before the reset
to access the trace. I cannot assure it.
I know the principle works but have not tried myself yet.

Alban.

---------------------------------
Don't get soaked. Take a quick peak at the forecast
with theYahoo! Search weather shortcut.

[Non-text portions of this message have been removed]

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

--- In 6...@yahoogroups.com, swapna gurumani wrote:
>
> i know that the SC0 port of the dragon 12 board is being used
> for RS232 interface. But i Desperately need to use it for
> reception. is there any way around for my problem?

In case the other answers don't help, here's my advice:

The very best answer is, use a BDM debugger! They are wonderful, and
could be low-cost.

If you must use the resident D-Bug12 monitor for debugging, it is
still possible. Keep in mind that although db12 needs SCI0 before and
after the user app runs, it generally does not use it while the user
program is running. If you are willing to limit your application to
the same SCI register settings, it can be used by both. If use db12
only to load and start your app (a bootstrap), you can even
reconfigure SCI0 such as use a different baud rate. I have used SCI0
in polling mode. You wouldn't be able to use interrupts because db12
takes over the SCI0 vector.

There is actually some D-Bug12 utility functions such as printf which
are intended to be available to the user (Appendix C of the Reference
Guide). So they wanted you to use that serial port :)

One tip is to add a delay when starting up your app. It seemed that
SCI0 didn't work right if I started sending too soon.



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

i figured out how to download the program in the EEPROM using DBUG12. Is the SC0 interrupt unavailable even in the EEPROM mode as in the EVB mode??

swapna

---------------------------------
Get the free Yahoo! toolbar and rest assured with the added security of spyware protection.

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

--- In 6...@yahoogroups.com, "Jefferson Smith" wrote:
> although db12 needs SCI0 before and
> after the user app runs, it generally does not use it
> while the user program is running.

This is my thought also. You can't do any debugging with d-bug12 while
the user program is in the active run state, so I'm guessing you can
grab both serial ports.

If you'll be working with the hc12 devices a lot you'll definitely
want a BDM device. These let you take control of the processor even
while the user program is running, and you won't lose any serial
ports. But there's a learning curve the first time you try them...

Eric


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, "Eric Engler" wrote:
> If you'll be working with the hc12 devices a lot you'll definitely
> want a BDM device. These let you take control of the processor even
> while the user program is running, and you won't lose any serial
> ports. But there's a learning curve the first time you try them...
>
> Eric

Yep.
LOL, there's a "learning curve" to *everything*, yet for most, BDM is
the *easiest* one to learn and use.



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, swapna gurumani wrote:
>
> i figured out how to download the program in the EEPROM using
> DBUG12. Is the SC0 interrupt unavailable even in the EEPROM mode
> as in the EVB mode??
>
> swapna

Maybe what you figured out was to use the D-Bug12 bootloader which
would still be in Flash, [f000..ffff]. The interrupt vectors are in
there, so the possiblilities are still the same. You would not use
interrupts for SCI0.

Maybe what you figured out was to use 'load' but put the program in
the EEPROM memory locations. These two options would not directly
affect anything about whether you can use SCI0 (why do you call it SC0?).

To load the app more permenantly, one good thing about using the
bootloader is that you can also erase the D-Bug12 monitor from Flash.
Then you can use the bootloader (which remains), and load your
application in Flash, for a more real ROM implementation. Of course
that way you could not debug with D-Bug12 until you erase your app and
replace the D-Bug12 monitor. When the app is in Flash (all Flash
available except [f000..ffff], then you put your user vector table in
[ef80..efff]. You'll want to read more about all this in your
documentation.



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Alban wrote:

> --- In 6...@yahoogroups.com, "Edward Karpicz" wrote:
>>
>> Alban wrote:
>>
>> > 3. Reset is immediate and 'resets' most registers but not all. As you
>> > know where the fault occurs, you can trigger the Debug module to trace
>> > the execution.
>> > A reset does 'reset' the configuration of the Debug module, however it
>> > keeps the content of the trace to allow tracing through Reset.
>> >
>>
>> Is there some HOWTO or AN describing how to trace through reset with
> CW 4.5
>> and USB Multilink? After I hit reset or do intentional illegal access
>> reset - I see trace emptied. I don't see any option in multilink or in
>> trigger settings that could help tracing through reset. Is CW 4.6
> better at
>> this?
>>
>> Thanks
>> Edward
>
> Hi Edward,
> Not that I know of.
> The registers will be emptied/reseted.
> However the buffer itself is not affected by a illegal address reset.
Hi,

Indeed you are right that trace buffer is not emptied. Ant not only buffer
contents but also DBGCNT (count of trace records) register isn't reset by
reset. But this seems being not helpful to find the place in the program
where illegal access reset could take place.

>
> May be you need to reconfigure the module as it was before the reset
> to access the trace. I cannot assure it.

Maybe. But CW should reconfigure module for me if it configures the module
before the reset. And after looking at S12XDBG registers I think indeed
reconfigures S12XDBG after every reset. But I'm not sure. I also played
around C32 trace buffer and I think C32's DBG is less fuzzy than XDT256
DBG. I somehow managed to catch the place in the C32 program where I write
non$AA/$55 to ARMCOP. The same didn't work in XDT512, trace buffer contained
garbage after illegal access or COP resets, it didn't conform to any of
following configs: trace S12X only/ trace XGATE only or trace both cores,
neither detail or loop. Also I did some code to play around my own trace
arming, reading and decoding. I can be all wrong, but I have an impression,
that S12X trace buffer, after dearming, is reformatted from the same trace
buffer, or from the 2nd hidden buffer, to format specified by trace mode
bits. Trace buffer contents looks good if dearming occurs before reset, and
trace buffer seems containing garbage if reset occures while trace is armed.
But all these experiments took longer then I should afford, maybe I'll back
to them later.

Edward

> I know the principle works but have not tried myself yet.
>
> Alban.



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )