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.
Illegal Address Reset on S12X
Started by ●May 25, 2007
Reply by ●June 12, 20072007-06-12
Reply by ●June 13, 20072007-06-13
--- 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
> 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
Reply by ●June 13, 20072007-06-13
--- 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.
> 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.
Reply by ●June 13, 20072007-06-13
--- 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.
>
> 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.
Reply by ●June 14, 20072007-06-14
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..., "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.
