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...
'
'
'
'
'
'
''
Illegal Address Reset on S12X
Started by ●May 25, 2007
Reply by ●May 31, 20072007-05-31
Reply by ●May 31, 20072007-05-31
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... [mailto:6...]
> 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
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... [mailto:6...]
> 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
Reply by ●May 31, 20072007-05-31
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... [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...
''
'
'
'
'
> 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... [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...
''
'
'
'
'
Reply by ●June 6, 20072007-06-06
--- In 6..., 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.
>
> 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.
Reply by ●June 6, 20072007-06-06
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
> 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
Reply by ●June 11, 20072007-06-11
--- 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.
>
> 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.
Reply by ●June 11, 20072007-06-11
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.
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.
Reply by ●June 12, 20072007-06-12
--- 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?
This is a 2-way serial port. You can send and receive with the same
port. What are you trying to receive?
Reply by ●June 12, 20072007-06-12
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...
''
''
'
'
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...
''
''
'
'
Reply by ●June 12, 20072007-06-12
--- 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.
>
> 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.
