Alban wrote:

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

--- In 6..., 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.

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

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

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.

--- In 6..., 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.

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... [mailto:6...] On Behalf
Of swapna gurumani
Sent: Monday, June 11, 2007 2:31 PM
To: 6...
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...

''

''

'

'

--- In 6..., 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?

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

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