Reply by Gilles Blanquin ●October 14, 20032003-10-14
Hi Andy.

Thanks for all details.
If you can, please send me directly your project or an extract of your
project in order to reproduce the problem on my side.

Regards,
Gilles At 12:04 AM 10/14/2003, you wrote:

>OK, I have wrestled this down to the following minimal scenario:
>
>1. My code is running normally. Debugger is operating normally.
>
>2. I open a Command window within the True-Time debugger. The
>Command
>window waits patiently with an "in>" prompt.
>
>3. I have my code jump to the following tight loop:
>
>loop:
> ldab #$55 ;clear ARMCOP
> stab $3F
> aslb
> stab $3F
> bra loop ;loop forever
>
>4. Sometime after the code hits this loop, the debugger Command
>window
>begins filling with error messages. Following is an excerpt:
>
><START EXCERPT>
>read_status()
> => 0x8
>preset_communication_speed(40)
>set_speed_no_reset()
>read_status()
> => 0xff
>preset_communication_speed(39)
>set_speed_no_reset()
>preset_communication_speed(38)
>set_speed_no_reset()
>preset_communication_speed(37)
>set_speed_no_reset()
>preset_communication_speed(36)
>set_speed_no_reset()
>preset_communication_speed(35)
>set_speed_no_reset()
>preset_communication_speed(34)
>set_speed_no_reset()
>preset_communication_speed(33)
>set_speed_no_reset()
>preset_communication_speed(32)
>set_speed_no_reset()
>preset_communication_speed(31)
>set_speed_no_reset()
>preset_communication_speed(30)
>set_speed_no_reset()
>preset_communication_speed(29)
>set_speed_no_reset()
>preset_communication_speed(28)
>set_speed_no_reset()
>preset_communication_speed(27)
>set_speed_no_reset()
>preset_communication_speed(26)
>set_speed_no_reset()
>preset_communication_speed(25)
>set_speed_no_reset()
>preset_communication_speed(24)
>set_speed_no_reset()
>preset_communication_speed(23)
>set_speed_no_reset()
>preset_communication_speed(22)
>set_speed_no_reset()
>preset_communication_speed(21)
>set_speed_no_reset()
>preset_communication_speed(20)
>set_speed_no_reset()
>preset_communication_speed(19)
>set_speed_no_reset()
>preset_communication_speed(18)
>set_speed_no_reset()
>preset_communication_speed(17)
>set_speed_no_reset()
>preset_communication_speed(16)
>set_speed_no_reset()
>preset_communication_speed(15)
>set_speed_no_reset()
>preset_communication_speed(14)
>set_speed_no_reset()
>preset_communication_speed(13)
>set_speed_no_reset()
>preset_communication_speed(12)
>set_speed_no_reset()
>preset_communication_speed(11)
>set_speed_no_reset()
>preset_communication_speed(10)
>set_speed_no_reset()
>preset_communication_speed(9)
>set_speed_no_reset()
>preset_communication_speed(8)
>set_speed_no_reset()
>preset_communication_speed(7)
>set_speed_no_reset()
>preset_communication_speed(6)
>set_speed_no_reset()
>preset_communication_speed(5)
>set_speed_no_reset()
>preset_communication_speed(4)
>set_speed_no_reset()
>read_status()
> => 0xd6
>preset_communication_speed(3)
>set_speed_no_reset()
>read_status()
> => 0x84
>preset_communication_speed(2)
>set_speed_no_reset()
>read_status()
> => 0xff
>preset_communication_speed(1)
>set_speed_no_reset()
>preset_communication_speed(3)
>set_speed_no_reset()
>read_status()
> => 0x8
>preset_communication_speed(2)
>set_speed_no_reset()
>read_status()
> => 0xff
>preset_communication_speed(1)
>set_speed_no_reset()
>Frequency change detected, reconnect using io_delay_cnt: "0"
>(CheckStatusWithCLKSW() & 0x40 != 0) => 1
>read_bd_byte(0xFF07)
> => 0xFF
>read_bd_byte(0xFF08)
> => 0xFF
>get_cpu_values() => FFFF, FFFF, FFFF, FFFF, FF, FF, FF
>Other BGND FFFF
>read_bd_byte(0xFF07)
> => 0xFF
>read_bd_byte(0xFF08)
> => 0xFF
>get_cpu_values() => FFFF, FFFF, FFFF, FFFF, FF, FF, FF
>ILLEGAL_BP
>get_cpu_values() => FFFF, FFFF, FFFF, FFFF, FF, FF, FF
>read_data_byte/word((FFFF..FFFF) [1] => FF
>read_data_byte/word((FFC0..FFF1) [50] => FFFF FFFF FFFF FFFF FFFF
>FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
>FFFF FFFF FFFF FFFF FFFF FFFF
>read_data_byte/word((FFF2..FFFF) [14] => FFFF FFFF FFFF FFFF FFFF
>FFFF FFFF
>preset_communication_speed(40)
>set_speed_no_reset()
>preset_communication_speed(39)
>set_speed_no_reset()
>preset_communication_speed(38)
>set_speed_no_reset()
>preset_communication_speed(37)
>set_speed_no_reset()
>preset_communication_speed(36)
>set_speed_no_reset()
>preset_communication_speed(35)
>set_speed_no_reset()
>preset_communication_speed(34)
>set_speed_no_reset()
>preset_communication_speed(33)
>set_speed_no_reset()
>preset_communication_speed(32)
>set_speed_no_reset()
>preset_communication_speed(31)
>set_speed_no_reset()
>preset_communication_speed(30)
>set_speed_no_reset()
>preset_communication_speed(29)
>set_speed_no_reset()
>preset_communication_speed(28)
>set_speed_no_reset()
>preset_communication_speed(27)
>set_speed_no_reset()
>preset_communication_speed(26)
>set_speed_no_reset()
>preset_communication_speed(25)
>set_speed_no_reset()
>preset_communication_speed(24)
>set_speed_no_reset()
>preset_communication_speed(23)
>set_speed_no_reset()
>preset_communication_speed(22)
>set_speed_no_reset()
>preset_communication_speed(21)
>set_speed_no_reset()
>preset_communication_speed(20)
>set_speed_no_reset()
>preset_communication_speed(19)
>set_speed_no_reset()
>preset_communication_speed(18)
>set_speed_no_reset()
>preset_communication_speed(17)
>set_speed_no_reset()
>preset_communication_speed(16)
>set_speed_no_reset()
>preset_communication_speed(15)
>set_speed_no_reset()
>preset_communication_speed(14)
>set_speed_no_reset()
>preset_communication_speed(13)
>set_speed_no_reset()
>preset_communication_speed(12)
>set_speed_no_reset()
>preset_communication_speed(11)
>set_speed_no_reset()
>preset_communication_speed(10)
>set_speed_no_reset()
>preset_communication_speed(9)
>set_speed_no_reset()
>preset_communication_speed(8)
>set_speed_no_reset()
>preset_communication_speed(7)
>set_speed_no_reset()
>preset_communication_speed(6)
>set_speed_no_reset()
>preset_communication_speed(5)
>set_speed_no_reset()
>preset_communication_speed(4)
>set_speed_no_reset()
>read_status()
> => 0xd4
>preset_communication_speed(3)
>set_speed_no_reset()
>read_status()
> => 0x8
>preset_communication_speed(2)
>set_speed_no_reset()
>read_status()
> => 0xff
>preset_communication_speed(1)
>set_speed_no_reset()
>preset_communication_speed(4)
>set_speed_no_reset()
>read_status()
> => 0xc6
>preset_communication_speed(3)
>set_speed_no_reset()
>read_status()
> => 0x8
>preset_communication_speed(2)
>set_speed_no_reset()
>read_status()
> => 0xff
>preset_communication_speed(1)
>set_speed_no_reset()
>Frequency change detected, reconnect using io_delay_cnt: "0"
>write_data_byte/word(0028..0029) [2] => 0000
>preset_communication_speed(11)
>set_speed() => 1
>read_data_byte/word((FFFE..FFFF) [2] => 4000
>get_cpu_values() => 4A4D, 0, 0, 0, D8, 0, 0
>read_data_byte/word((0035..0035) [1] => 00
>put_cpu_values(4000, 0, 0, 0, D8, 0, 0)
>Reset Command File execution: C:\Documents and Settings\asifferm\My
>Documents\Projects\ffsensor\code\cmd\p&e_reset.cmd
>executing C:\Documents and Settings\asifferm\My
>Documents\Projects\ffsensor\code\cmd\p&e_reset.cmd
>
>!// After reset the commands written below will be executed
>read_status()
> => 0xc0
>write_control()
>!
>read_status()
> => 0xc4
>!
>done C:\Documents and Settings\asifferm\My
>Documents\Projects\ffsensor\code\cmd\p&e_reset.cmd
>
>Reset command file correctly executed.
>read_bd_byte(0xFF07)
> => 0x0
>read_bd_byte(0xFF08)
> => 0x0
>write_data_byte/word(0028..0029) [2] => 0000
>get_cpu_values() => 4000, 0, 0, 0, D8, 0, 0
>read_data_byte/word((0035..0035) [1] => 00
>RESET
>get_cpu_values() => 4000, 0, 0, 0, D8, 0, 0
>read_data_byte/word((0035..0035) [1] => 00
>read_data_byte/word((4000..402F) [48] => 7900 11C6 085B 1286 205A
>101E 401D 0203 FF40 214A 59C0 004B FB00 0320 EE00 C000 003F FE00 0140
>3571 4400 0040 3900 0040
>read_data_byte/word((0000..0031) [50] => 0000 0000 0000 0000 0F00
>0000 9000 0100 0900 010D 000F 0010 0000 0100 1380 40F2 0000 0000 0000
>0000 0000 0000 0000 0000 0000
>read_data_byte/word((FFC0..FFF1) [50] => 45A4 45A2 45A0 459E 459C
>459A 4598 4596 4594 4592 4590 57E0 458E 458C 458A 4588 4586 4584 4582
>4580 457E 457C 5729 5454 457A
>read_data_byte/word((FFF2..FFFF) [14] => 4578 4576 4574 4572 4570
>456E 4000
>
>in>
><END EXCERPT>
>
>5. (Note that in the above excerpt, I clicked on the Reset button in
>the debugger immediately after instructing my code to jump to the
>tight loop.)
>
>6. The above happens regardless of whether interrupts are enabled or
>disabled prior to entering the tight loop.
>
>7. My hardware is a MC9S12DG128BCFU, mask set 0L85D. I do have a PLL
>loop filter installed.
>
>8. I have also tried this on the Motorola EVB, which has a
>MC9S12DP256B, mask set 1K79X. Same behavior as on my hardware.
>
>9. In my initialization code, I set the PLL to use REFDV,
>SYNR#,
>with a 16MHz crystal to yield a 24 MHz bus clock. This is done once
>only.
>
>10. The "set CLKSW bit in BDM control register (MC9S12 only)"
>checkbox
>is checked.
>
>11. Typing "ver" in the command window produces the following:
>
>HI-WAVE 6.1.40
>HI-WAVE Engine 6.1.66
>Assembly 6.1.18
>Procedure 6.1.11
>Register 6.1.18
>Memory 6.1.28
>Data 6.1.35
>Data 6.1.35
>ICD-12 Target 6.1.7
>version() => '68HC12 Interface Libraries Version 2.29 (http://www.
>pemicro.com)'
> 68HC12 Interface Libraries Version 2.29 (http://www.pemicro.com)
>get_cable_version()
> => 406d
> Cable version: 4.6
>ElfLoader 6.1.28
>HC12 CPU 6.1.13
>Source 6.1.25
>Command Line 6.1.22
>
>Thanks for your help.
>
>Andy >--- In , Gilles Blanquin <gblanquin@m...> wrote:
> > Hi Andy.
> >
> > Thanks for isolating this problem. All points after "point 2" are
>"normal",
> > resulting from a loss of communication.
> > This is a "hardware" problem. It seems to be something bound to bus
>speed
> > change via onchip PLL, implying also a BDM communication speed
>change and
> > loss of communication/synchronization between the chip and the
>Multilink.
> >
> > If your application changes (even only once) the bus speed via PLL:
> > -make sure a PLL Loop Filter is installed.
> > -check the "set CLKSW bit in BDM control register (MC9S12 only)"
>checkbox
> > in the "Communication Device Specification" dialog (menu: "ICD-12"
>then
> > "Connect...").
> >
> > If you open a "Command" component, speed variation detections by
>the
>cable
> > should be reported there.
> >
> > Andy, you can send me your program/project directly. Please specify
>also
> > the MC9S12DG128B silicon mask, the Multilink cable revision, and
>also your
> > Metrowerks CodeWarrior version. Typing "ver" in the "Command"
>window
>gives
> > directly a list of DLL versions. Any other info like schematics is
>also
> > welcome.
> >
> > Thanks for all your help.
> >
> > Regards,
> > Gilles
> >
> >
> > At 11:39 PM 10/6/2003, you wrote:
> >
> > >OK, now the problem seems to have morphed into something
>repeatable.
> > >I wrote some test code to solve another problem, that repeatedly
>calls
> > >one routine to read data from a proprietary input port, and
>transmit
> > >that data to a serial output port for viewing with Hyperterminal.
> > >This code appears to work fine. But, the debugger does the
>following.
> > >(Note: I am using MC9S12DG128B, P&E BDM Multilink, and Metrowerks
> > >True-Time debugger.)
> > >
> > >1. I click Start in the True-Time debugger, which starts up my
>code
>at
> > >the Reset vector, using the BDM-Multilink. The target program
>starts
> > >to run correctly, and I start seeing data appearing on
>Hyperterminal.
> > >
> > >2. After a second or so, the debugger appears to halt on the BGND
> > >instruction in the service routine for Unimplemented ISR 63, whose
> > >vector is mapped to address 0xFF80. However, the program
>continues
>to
> > >run properly on the target. Only the debugger has stopped. The
>Halt
> > >button on the debugger toolbar is grayed-out and not available.
> > >
> > >3. If I click on the Start button in the toolbar, nothing appears
>to
> > >happen. The program continues to run on the target.
> > >
> > >4. If I scroll through memory within the debugger while the
>program
>is
> > >running and the debugger is in this halted state, it all reads FF.
> > >All of the HC12 registers read FF, too, as does the CCR.
> > >
> > >5. If I click on the Reset Target button on the toolbar, the
>program
> > >in the target halts, and the debugger returns to its normal state.
>
>I
> > >can then see the actual memory in the target, and the actual state
>of
> > >the registers.
> > >
> > >Any clues, I'd appreciate your ideas.
> > >
> > >Thanks everyone.
> > >
> > >Andy
> > >
> > >------------------------------
> > >--- In , "Sifferman" <asifferm@a...> wrote:
> > > >
> > > > Gilles -
> > > >
> > > > Good idea. The next time this happens, I will check the I bit
>and
> > > > the
> > > > stack, which might yield further clues as to what is happening.
> > > >
> > > > But I don't think a runaway processor would halt if it tried to
> > > > execute the contents of 0xFF80 - this location would contain the
> > > > address of the Unimplemented ISR service routine, and not the
>BGND
> > > > instruction itself. The service routine for Unimplemented ISR
>63
> > > > occurs in memory AFTER all of the other Unimplemented ISR
>routines
> > > > (all of which contain simply a single BGND instruction) - this
>is
> > >the
> > > > last BGND instruction, not the first. Therefore, it seems
>unlikely
> > > > to
> > > > me that the processor was executing runaway code and "happened"
>upon
> > > > the BGND instruction. Though it is plausible that there might
>be a
> > > > jump to that location.
> > > >
> > > > Thanks for the reply.
> > > >
> > > > Andy
> > > >
> > > > ----------------------------
> > > > --- In , Gilles Blanquin <gblanquin@m...>
> > >wrote:
> > > > > Hi Andy.
> > > > >
> > > > > Can you make sure that when the debugger halts, the I bit is
>set?
> > > > > I mean that the debugger will halt on any BGND instruction
> > > > execution. A
> > > > > jump to this address would do the same thing. But only an
> > >interrupt
> > > > will set I.
> > > > >
> > > > > I can imaging that the PC has "quitted" the program and
> > >incremented
> > > > till
> > > > > reaching address FF80 and halted the debugger this way.
> > > > >
> > > > > Typically, the debugger is able to read the program call
>chain
>on
> > > > the
> > > > > device stack and display it in the Procedure window: If an
> > > > interrupt
> > > > > occurs, you should be able to find latest procedure called.
> > > > >
> > > > >
> > > > > Best regards,
> > > > > Gilles
> > > > >
> > > > >
> > > > > At 11:10 PM 8/22/2003, you wrote:
> > > > >
> > > > > >Hello everyone -
> > > > > >
> > > > > >I am using the MC9S12DG128B with the P&E BDM-Multilink,
> > >controlled
> > > > by the
> > > > > >Metrowerks True-Time debugger. I have been developing code
>for a
> > > > few
> > > > > >months now.
> > > > > >
> > > > > >Most of the time everything works fine. But every now and
>then
> > > > (between
> > > > > >several minutes to a few hours), the processor simply halts.
>
>In
> > > > every case
> > > > > >the True-Time debugger indicates that the processor has
>halted on
> > > > the BGND
> > > > > >instruction in the Unimplemented ISR trap.
> > > > > >
> > > > > >I modified the isr_vectors.c file to produce a unique (but
> > > > identical)
> > > > > >routine for each of the 64 vectors. This allowed me to
>identify
> > > > that the
> > > > > >trap occurs on Unimplemented ISR 63, whose vector is mapped
>to
> > > > address 0xFF80.
> > > > > >
> > > > > >The MC9S12DT128B Device User Guide indicates that the vector
>at
> > > > address
> > > > > >0xFF80 is "Reserved." It is not assigned to any documented
> > > > > >function. Therefore, I would expect that this vector would
>never
> > > > be seen.
> > > > > >
> > > > > >I have only seen this behavior with the BDM-Multilink
>connected
> > >to
> > > > my
> > > > > >target. I don't know if it will happen when the target is
> > >running
> > > > > >standalone. The problem occurs so infrequently that I really
> > > > can't
> > > > just
> > > > > >sit around and wait for it to happen.
> > > > > >
> > > > > >Of course with an in-circuit emulator, I could set up a
>trace
>to
> > > > see the
> > > > > >executed instructions leading up to the interrupt. But
>alas,
>all
> > > > I
> > > > have is
> > > > > >the humble BDM-Multilink.
> > > > > >
> > > > > >Anyone have any ideas about why this might be happening, or
>how I
> > > > might
> > > > > >debug it?
> > > > > >
> > > > > >Thanks.
> > > > > >
> > > > > >Andy
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >--------------------
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > >
> > >
> > >
> > >--------------------
> > >
> > >
> > >
> > >
>-------------------- >
>">http://docs.yahoo.com/info/terms/




Reply by Sifferman ●October 13, 20032003-10-13

OK, I have wrestled this down to the following minimal scenario:

1. My code is running normally. Debugger is operating normally.

2. I open a Command window within the True-Time debugger. The
Command
window waits patiently with an "in>" prompt.

3. I have my code jump to the following tight loop:

loop:
ldab #$55 ;clear ARMCOP
stab $3F
aslb
stab $3F
bra loop ;loop forever

4. Sometime after the code hits this loop, the debugger Command
window
begins filling with error messages. Following is an excerpt:

<START EXCERPT>
read_status()
=> 0x8
preset_communication_speed(40)
set_speed_no_reset()
read_status()
=> 0xff
preset_communication_speed(39)
set_speed_no_reset()
preset_communication_speed(38)
set_speed_no_reset()
preset_communication_speed(37)
set_speed_no_reset()
preset_communication_speed(36)
set_speed_no_reset()
preset_communication_speed(35)
set_speed_no_reset()
preset_communication_speed(34)
set_speed_no_reset()
preset_communication_speed(33)
set_speed_no_reset()
preset_communication_speed(32)
set_speed_no_reset()
preset_communication_speed(31)
set_speed_no_reset()
preset_communication_speed(30)
set_speed_no_reset()
preset_communication_speed(29)
set_speed_no_reset()
preset_communication_speed(28)
set_speed_no_reset()
preset_communication_speed(27)
set_speed_no_reset()
preset_communication_speed(26)
set_speed_no_reset()
preset_communication_speed(25)
set_speed_no_reset()
preset_communication_speed(24)
set_speed_no_reset()
preset_communication_speed(23)
set_speed_no_reset()
preset_communication_speed(22)
set_speed_no_reset()
preset_communication_speed(21)
set_speed_no_reset()
preset_communication_speed(20)
set_speed_no_reset()
preset_communication_speed(19)
set_speed_no_reset()
preset_communication_speed(18)
set_speed_no_reset()
preset_communication_speed(17)
set_speed_no_reset()
preset_communication_speed(16)
set_speed_no_reset()
preset_communication_speed(15)
set_speed_no_reset()
preset_communication_speed(14)
set_speed_no_reset()
preset_communication_speed(13)
set_speed_no_reset()
preset_communication_speed(12)
set_speed_no_reset()
preset_communication_speed(11)
set_speed_no_reset()
preset_communication_speed(10)
set_speed_no_reset()
preset_communication_speed(9)
set_speed_no_reset()
preset_communication_speed(8)
set_speed_no_reset()
preset_communication_speed(7)
set_speed_no_reset()
preset_communication_speed(6)
set_speed_no_reset()
preset_communication_speed(5)
set_speed_no_reset()
preset_communication_speed(4)
set_speed_no_reset()
read_status()
=> 0xd6
preset_communication_speed(3)
set_speed_no_reset()
read_status()
=> 0x84
preset_communication_speed(2)
set_speed_no_reset()
read_status()
=> 0xff
preset_communication_speed(1)
set_speed_no_reset()
preset_communication_speed(3)
set_speed_no_reset()
read_status()
=> 0x8
preset_communication_speed(2)
set_speed_no_reset()
read_status()
=> 0xff
preset_communication_speed(1)
set_speed_no_reset()
Frequency change detected, reconnect using io_delay_cnt: "0"
(CheckStatusWithCLKSW() & 0x40 != 0) => 1
read_bd_byte(0xFF07)
=> 0xFF
read_bd_byte(0xFF08)
=> 0xFF
get_cpu_values() => FFFF, FFFF, FFFF, FFFF, FF, FF, FF
Other BGND FFFF
read_bd_byte(0xFF07)
=> 0xFF
read_bd_byte(0xFF08)
=> 0xFF
get_cpu_values() => FFFF, FFFF, FFFF, FFFF, FF, FF, FF
ILLEGAL_BP
get_cpu_values() => FFFF, FFFF, FFFF, FFFF, FF, FF, FF
read_data_byte/word((FFFF..FFFF) [1] => FF
read_data_byte/word((FFC0..FFF1) [50] => FFFF FFFF FFFF FFFF FFFF
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
FFFF FFFF FFFF FFFF FFFF FFFF
read_data_byte/word((FFF2..FFFF) [14] => FFFF FFFF FFFF FFFF FFFF
FFFF FFFF
preset_communication_speed(40)
set_speed_no_reset()
preset_communication_speed(39)
set_speed_no_reset()
preset_communication_speed(38)
set_speed_no_reset()
preset_communication_speed(37)
set_speed_no_reset()
preset_communication_speed(36)
set_speed_no_reset()
preset_communication_speed(35)
set_speed_no_reset()
preset_communication_speed(34)
set_speed_no_reset()
preset_communication_speed(33)
set_speed_no_reset()
preset_communication_speed(32)
set_speed_no_reset()
preset_communication_speed(31)
set_speed_no_reset()
preset_communication_speed(30)
set_speed_no_reset()
preset_communication_speed(29)
set_speed_no_reset()
preset_communication_speed(28)
set_speed_no_reset()
preset_communication_speed(27)
set_speed_no_reset()
preset_communication_speed(26)
set_speed_no_reset()
preset_communication_speed(25)
set_speed_no_reset()
preset_communication_speed(24)
set_speed_no_reset()
preset_communication_speed(23)
set_speed_no_reset()
preset_communication_speed(22)
set_speed_no_reset()
preset_communication_speed(21)
set_speed_no_reset()
preset_communication_speed(20)
set_speed_no_reset()
preset_communication_speed(19)
set_speed_no_reset()
preset_communication_speed(18)
set_speed_no_reset()
preset_communication_speed(17)
set_speed_no_reset()
preset_communication_speed(16)
set_speed_no_reset()
preset_communication_speed(15)
set_speed_no_reset()
preset_communication_speed(14)
set_speed_no_reset()
preset_communication_speed(13)
set_speed_no_reset()
preset_communication_speed(12)
set_speed_no_reset()
preset_communication_speed(11)
set_speed_no_reset()
preset_communication_speed(10)
set_speed_no_reset()
preset_communication_speed(9)
set_speed_no_reset()
preset_communication_speed(8)
set_speed_no_reset()
preset_communication_speed(7)
set_speed_no_reset()
preset_communication_speed(6)
set_speed_no_reset()
preset_communication_speed(5)
set_speed_no_reset()
preset_communication_speed(4)
set_speed_no_reset()
read_status()
=> 0xd4
preset_communication_speed(3)
set_speed_no_reset()
read_status()
=> 0x8
preset_communication_speed(2)
set_speed_no_reset()
read_status()
=> 0xff
preset_communication_speed(1)
set_speed_no_reset()
preset_communication_speed(4)
set_speed_no_reset()
read_status()
=> 0xc6
preset_communication_speed(3)
set_speed_no_reset()
read_status()
=> 0x8
preset_communication_speed(2)
set_speed_no_reset()
read_status()
=> 0xff
preset_communication_speed(1)
set_speed_no_reset()
Frequency change detected, reconnect using io_delay_cnt: "0"
write_data_byte/word(0028..0029) [2] => 0000
preset_communication_speed(11)
set_speed() => 1
read_data_byte/word((FFFE..FFFF) [2] => 4000
get_cpu_values() => 4A4D, 0, 0, 0, D8, 0, 0
read_data_byte/word((0035..0035) [1] => 00
put_cpu_values(4000, 0, 0, 0, D8, 0, 0)
Reset Command File execution: C:\Documents and Settings\asifferm\My
Documents\Projects\ffsensor\code\cmd\p&e_reset.cmd
executing C:\Documents and Settings\asifferm\My
Documents\Projects\ffsensor\code\cmd\p&e_reset.cmd

!// After reset the commands written below will be executed
read_status()
=> 0xc0
write_control()
!
read_status()
=> 0xc4
!
done C:\Documents and Settings\asifferm\My
Documents\Projects\ffsensor\code\cmd\p&e_reset.cmd

Reset command file correctly executed.
read_bd_byte(0xFF07)
=> 0x0
read_bd_byte(0xFF08)
=> 0x0
write_data_byte/word(0028..0029) [2] => 0000
get_cpu_values() => 4000, 0, 0, 0, D8, 0, 0
read_data_byte/word((0035..0035) [1] => 00
RESET
get_cpu_values() => 4000, 0, 0, 0, D8, 0, 0
read_data_byte/word((0035..0035) [1] => 00
read_data_byte/word((4000..402F) [48] => 7900 11C6 085B 1286 205A
101E 401D 0203 FF40 214A 59C0 004B FB00 0320 EE00 C000 003F FE00 0140
3571 4400 0040 3900 0040
read_data_byte/word((0000..0031) [50] => 0000 0000 0000 0000 0F00
0000 9000 0100 0900 010D 000F 0010 0000 0100 1380 40F2 0000 0000 0000
0000 0000 0000 0000 0000 0000
read_data_byte/word((FFC0..FFF1) [50] => 45A4 45A2 45A0 459E 459C
459A 4598 4596 4594 4592 4590 57E0 458E 458C 458A 4588 4586 4584 4582
4580 457E 457C 5729 5454 457A
read_data_byte/word((FFF2..FFFF) [14] => 4578 4576 4574 4572 4570
456E 4000

in>
<END EXCERPT>

5. (Note that in the above excerpt, I clicked on the Reset button in
the debugger immediately after instructing my code to jump to the
tight loop.)

6. The above happens regardless of whether interrupts are enabled or
disabled prior to entering the tight loop.

7. My hardware is a MC9S12DG128BCFU, mask set 0L85D. I do have a PLL
loop filter installed.

8. I have also tried this on the Motorola EVB, which has a
MC9S12DP256B, mask set 1K79X. Same behavior as on my hardware.

9. In my initialization code, I set the PLL to use REFDV,
SYNR#,
with a 16MHz crystal to yield a 24 MHz bus clock. This is done once
only.

10. The "set CLKSW bit in BDM control register (MC9S12 only)"
checkbox
is checked.

11. Typing "ver" in the command window produces the following:

HI-WAVE 6.1.40
HI-WAVE Engine 6.1.66
Assembly 6.1.18
Procedure 6.1.11
Register 6.1.18
Memory 6.1.28
Data 6.1.35
Data 6.1.35
ICD-12 Target 6.1.7
version() => '68HC12 Interface Libraries Version 2.29 (http://www.
pemicro.com)'
68HC12 Interface Libraries Version 2.29 (http://www.pemicro.com)
get_cable_version()
=> 406d
Cable version: 4.6
ElfLoader 6.1.28
HC12 CPU 6.1.13
Source 6.1.25
Command Line 6.1.22

Thanks for your help.

Andy --- In , Gilles Blanquin <gblanquin@m...> wrote:
> Hi Andy.
>
> Thanks for isolating this problem. All points after "point 2" are
"normal",
> resulting from a loss of communication.
> This is a "hardware" problem. It seems to be something bound to bus
speed
> change via onchip PLL, implying also a BDM communication speed
change and
> loss of communication/synchronization between the chip and the
Multilink.
>
> If your application changes (even only once) the bus speed via PLL:
> -make sure a PLL Loop Filter is installed.
> -check the "set CLKSW bit in BDM control register (MC9S12 only)"
checkbox
> in the "Communication Device Specification" dialog (menu: "ICD-12"
then
> "Connect...").
>
> If you open a "Command" component, speed variation detections by
the
cable
> should be reported there.
>
> Andy, you can send me your program/project directly. Please specify
also
> the MC9S12DG128B silicon mask, the Multilink cable revision, and
also your
> Metrowerks CodeWarrior version. Typing "ver" in the "Command"
window
gives
> directly a list of DLL versions. Any other info like schematics is
also
> welcome.
>
> Thanks for all your help.
>
> Regards,
> Gilles > At 11:39 PM 10/6/2003, you wrote:
>
> >OK, now the problem seems to have morphed into something
repeatable.
> >I wrote some test code to solve another problem, that repeatedly
calls
> >one routine to read data from a proprietary input port, and
transmit
> >that data to a serial output port for viewing with Hyperterminal.
> >This code appears to work fine. But, the debugger does the
following.
> >(Note: I am using MC9S12DG128B, P&E BDM Multilink, and Metrowerks
> >True-Time debugger.)
> >
> >1. I click Start in the True-Time debugger, which starts up my
code
at
> >the Reset vector, using the BDM-Multilink. The target program
starts
> >to run correctly, and I start seeing data appearing on
Hyperterminal.
> >
> >2. After a second or so, the debugger appears to halt on the BGND
> >instruction in the service routine for Unimplemented ISR 63, whose
> >vector is mapped to address 0xFF80. However, the program
continues
to
> >run properly on the target. Only the debugger has stopped. The
Halt
> >button on the debugger toolbar is grayed-out and not available.
> >
> >3. If I click on the Start button in the toolbar, nothing appears
to
> >happen. The program continues to run on the target.
> >
> >4. If I scroll through memory within the debugger while the
program
is
> >running and the debugger is in this halted state, it all reads FF.
> >All of the HC12 registers read FF, too, as does the CCR.
> >
> >5. If I click on the Reset Target button on the toolbar, the
program
> >in the target halts, and the debugger returns to its normal state.

I
> >can then see the actual memory in the target, and the actual state
of
> >the registers.
> >
> >Any clues, I'd appreciate your ideas.
> >
> >Thanks everyone.
> >
> >Andy
> >
> >------------------------------
> >--- In , "Sifferman" <asifferm@a...> wrote:
> > >
> > > Gilles -
> > >
> > > Good idea. The next time this happens, I will check the I bit
and
> > > the
> > > stack, which might yield further clues as to what is happening.
> > >
> > > But I don't think a runaway processor would halt if it tried to
> > > execute the contents of 0xFF80 - this location would contain the
> > > address of the Unimplemented ISR service routine, and not the
BGND
> > > instruction itself. The service routine for Unimplemented ISR
63
> > > occurs in memory AFTER all of the other Unimplemented ISR
routines
> > > (all of which contain simply a single BGND instruction) - this
is
> >the
> > > last BGND instruction, not the first. Therefore, it seems
unlikely
> > > to
> > > me that the processor was executing runaway code and "happened"
upon
> > > the BGND instruction. Though it is plausible that there might
be a
> > > jump to that location.
> > >
> > > Thanks for the reply.
> > >
> > > Andy
> > >
> > > ----------------------------
> > > --- In , Gilles Blanquin <gblanquin@m...>
> >wrote:
> > > > Hi Andy.
> > > >
> > > > Can you make sure that when the debugger halts, the I bit is
set?
> > > > I mean that the debugger will halt on any BGND instruction
> > > execution. A
> > > > jump to this address would do the same thing. But only an
> >interrupt
> > > will set I.
> > > >
> > > > I can imaging that the PC has "quitted" the program and
> >incremented
> > > till
> > > > reaching address FF80 and halted the debugger this way.
> > > >
> > > > Typically, the debugger is able to read the program call
chain
on
> > > the
> > > > device stack and display it in the Procedure window: If an
> > > interrupt
> > > > occurs, you should be able to find latest procedure called.
> > > >
> > > >
> > > > Best regards,
> > > > Gilles
> > > >
> > > >
> > > > At 11:10 PM 8/22/2003, you wrote:
> > > >
> > > > >Hello everyone -
> > > > >
> > > > >I am using the MC9S12DG128B with the P&E BDM-Multilink,
> >controlled
> > > by the
> > > > >Metrowerks True-Time debugger. I have been developing code
for a
> > > few
> > > > >months now.
> > > > >
> > > > >Most of the time everything works fine. But every now and
then
> > > (between
> > > > >several minutes to a few hours), the processor simply halts.

In
> > > every case
> > > > >the True-Time debugger indicates that the processor has
halted on
> > > the BGND
> > > > >instruction in the Unimplemented ISR trap.
> > > > >
> > > > >I modified the isr_vectors.c file to produce a unique (but
> > > identical)
> > > > >routine for each of the 64 vectors. This allowed me to
identify
> > > that the
> > > > >trap occurs on Unimplemented ISR 63, whose vector is mapped
to
> > > address 0xFF80.
> > > > >
> > > > >The MC9S12DT128B Device User Guide indicates that the vector
at
> > > address
> > > > >0xFF80 is "Reserved." It is not assigned to any documented
> > > > >function. Therefore, I would expect that this vector would
never
> > > be seen.
> > > > >
> > > > >I have only seen this behavior with the BDM-Multilink
connected
> >to
> > > my
> > > > >target. I don't know if it will happen when the target is
> >running
> > > > >standalone. The problem occurs so infrequently that I really
> > > can't
> > > just
> > > > >sit around and wait for it to happen.
> > > > >
> > > > >Of course with an in-circuit emulator, I could set up a
trace
to
> > > see the
> > > > >executed instructions leading up to the interrupt. But
alas,
all
> > > I
> > > have is
> > > > >the humble BDM-Multilink.
> > > > >
> > > > >Anyone have any ideas about why this might be happening, or
how I
> > > might
> > > > >debug it?
> > > > >
> > > > >Thanks.
> > > > >
> > > > >Andy
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >--------------------
> > > > >
> > > > >
> > > > >
> > > > >
> >
> >
> >
> >--------------------
> >
> >
> >
>


Reply by theobee00 ●October 12, 20032003-10-12
--- In , Doron Fael <doronf@n...> wrote:

Hi Doron,

Thanks for that, hadn't come accross the name.
Steep learning curve from 6800 to HC12:-)

Regards,

Theo

> The PLL Loop Filter is the name of a network of 2 capacitors and one
> resistors that should be connected to the Xfc pin of your HC12 / HCS12, if
> you want to activate and use the internal HC12 PLL.
>
> In order to calculate the values of the capacitors and resistor for the
> HCS12 parts, you can download and use the following program from the Nohau
> web-site:
> http://www.nohau.com/s12calc/pll_302.html
>
> Hope this helps,
> Doron
> Nohau Corporation
> HC12 In-Circuit Emulators
> www.nohau.com/emul12pc.html
>
> At 19:49 10/10/2003 +0000, you wrote:
> >--- In , Gilles Blanquin <gblanquin@m...> wrote:
> >
> >Hi Giles,
> >
> > > If your application changes (even only once) the bus speed via PLL:
> > > -make sure a PLL Loop Filter is installed.
> >
> >What is?
> >
> >Hardware? Sodtware?
> >
> >
> >Regards,
> >
> >Theo >




Reply by Doron Fael ●October 12, 20032003-10-12
Theo,

The PLL Loop Filter is the name of a network of 2 capacitors and one
resistors that should be connected to the Xfc pin of your HC12 / HCS12, if
you want to activate and use the internal HC12 PLL.

In order to calculate the values of the capacitors and resistor for the
HCS12 parts, you can download and use the following program from the Nohau
web-site:
http://www.nohau.com/s12calc/pll_302.html

Hope this helps,
Doron
Nohau Corporation
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html

At 19:49 10/10/2003 +0000, you wrote:
>--- In , Gilles Blanquin <gblanquin@m...> wrote:
>
>Hi Giles,
>
> > If your application changes (even only once) the bus speed via PLL:
> > -make sure a PLL Loop Filter is installed.
>
>What is?
>
>Hardware? Sodtware? >Regards,
>
>Theo




Reply by theobee00 ●October 10, 20032003-10-10
--- In , Gilles Blanquin <gblanquin@m...> wrote:

Hi Giles,

> If your application changes (even only once) the bus speed via PLL:
> -make sure a PLL Loop Filter is installed.

What is?

Hardware? Sodtware? Regards,

Theo




Reply by Gilles Blanquin ●October 7, 20032003-10-07
Hi Andy.

Thanks for isolating this problem. All points after "point 2" are "normal",
resulting from a loss of communication.
This is a "hardware" problem. It seems to be something bound to bus speed
change via onchip PLL, implying also a BDM communication speed change and
loss of communication/synchronization between the chip and the Multilink.

If your application changes (even only once) the bus speed via PLL:
-make sure a PLL Loop Filter is installed.
-check the "set CLKSW bit in BDM control register (MC9S12 only)" checkbox
in the "Communication Device Specification" dialog (menu: "ICD-12" then
"Connect...").

If you open a "Command" component, speed variation detections by the cable
should be reported there.

Andy, you can send me your program/project directly. Please specify also
the MC9S12DG128B silicon mask, the Multilink cable revision, and also your
Metrowerks CodeWarrior version. Typing "ver" in the "Command" window gives
directly a list of DLL versions. Any other info like schematics is also
welcome.

Thanks for all your help.

Regards,
Gilles At 11:39 PM 10/6/2003, you wrote:

>OK, now the problem seems to have morphed into something repeatable.
>I wrote some test code to solve another problem, that repeatedly calls
>one routine to read data from a proprietary input port, and transmit
>that data to a serial output port for viewing with Hyperterminal.
>This code appears to work fine. But, the debugger does the following.
>(Note: I am using MC9S12DG128B, P&E BDM Multilink, and Metrowerks
>True-Time debugger.)
>
>1. I click Start in the True-Time debugger, which starts up my code at
>the Reset vector, using the BDM-Multilink. The target program starts
>to run correctly, and I start seeing data appearing on Hyperterminal.
>
>2. After a second or so, the debugger appears to halt on the BGND
>instruction in the service routine for Unimplemented ISR 63, whose
>vector is mapped to address 0xFF80. However, the program continues to
>run properly on the target. Only the debugger has stopped. The Halt
>button on the debugger toolbar is grayed-out and not available.
>
>3. If I click on the Start button in the toolbar, nothing appears to
>happen. The program continues to run on the target.
>
>4. If I scroll through memory within the debugger while the program is
>running and the debugger is in this halted state, it all reads FF.
>All of the HC12 registers read FF, too, as does the CCR.
>
>5. If I click on the Reset Target button on the toolbar, the program
>in the target halts, and the debugger returns to its normal state. I
>can then see the actual memory in the target, and the actual state of
>the registers.
>
>Any clues, I'd appreciate your ideas.
>
>Thanks everyone.
>
>Andy
>
>------------------------------
>--- In , "Sifferman" <asifferm@a...> wrote:
> >
> > Gilles -
> >
> > Good idea. The next time this happens, I will check the I bit and
> > the
> > stack, which might yield further clues as to what is happening.
> >
> > But I don't think a runaway processor would halt if it tried to
> > execute the contents of 0xFF80 - this location would contain the
> > address of the Unimplemented ISR service routine, and not the BGND
> > instruction itself. The service routine for Unimplemented ISR 63
> > occurs in memory AFTER all of the other Unimplemented ISR routines
> > (all of which contain simply a single BGND instruction) - this is
>the
> > last BGND instruction, not the first. Therefore, it seems unlikely
> > to
> > me that the processor was executing runaway code and "happened" upon
> > the BGND instruction. Though it is plausible that there might be a
> > jump to that location.
> >
> > Thanks for the reply.
> >
> > Andy
> >
> > ----------------------------
> > --- In , Gilles Blanquin <gblanquin@m...>
>wrote:
> > > Hi Andy.
> > >
> > > Can you make sure that when the debugger halts, the I bit is set?
> > > I mean that the debugger will halt on any BGND instruction
> > execution. A
> > > jump to this address would do the same thing. But only an
>interrupt
> > will set I.
> > >
> > > I can imaging that the PC has "quitted" the program and
>incremented
> > till
> > > reaching address FF80 and halted the debugger this way.
> > >
> > > Typically, the debugger is able to read the program call chain on
> > the
> > > device stack and display it in the Procedure window: If an
> > interrupt
> > > occurs, you should be able to find latest procedure called.
> > >
> > >
> > > Best regards,
> > > Gilles
> > >
> > >
> > > At 11:10 PM 8/22/2003, you wrote:
> > >
> > > >Hello everyone -
> > > >
> > > >I am using the MC9S12DG128B with the P&E BDM-Multilink,
>controlled
> > by the
> > > >Metrowerks True-Time debugger. I have been developing code for a
> > few
> > > >months now.
> > > >
> > > >Most of the time everything works fine. But every now and then
> > (between
> > > >several minutes to a few hours), the processor simply halts. In
> > every case
> > > >the True-Time debugger indicates that the processor has halted on
> > the BGND
> > > >instruction in the Unimplemented ISR trap.
> > > >
> > > >I modified the isr_vectors.c file to produce a unique (but
> > identical)
> > > >routine for each of the 64 vectors. This allowed me to identify
> > that the
> > > >trap occurs on Unimplemented ISR 63, whose vector is mapped to
> > address 0xFF80.
> > > >
> > > >The MC9S12DT128B Device User Guide indicates that the vector at
> > address
> > > >0xFF80 is "Reserved." It is not assigned to any documented
> > > >function. Therefore, I would expect that this vector would never
> > be seen.
> > > >
> > > >I have only seen this behavior with the BDM-Multilink connected
>to
> > my
> > > >target. I don't know if it will happen when the target is
>running
> > > >standalone. The problem occurs so infrequently that I really
> > can't
> > just
> > > >sit around and wait for it to happen.
> > > >
> > > >Of course with an in-circuit emulator, I could set up a trace to
> > see the
> > > >executed instructions leading up to the interrupt. But alas, all
> > I
> > have is
> > > >the humble BDM-Multilink.
> > > >
> > > >Anyone have any ideas about why this might be happening, or how I
> > might
> > > >debug it?
> > > >
> > > >Thanks.
> > > >
> > > >Andy
> > > >
> > > >
> > > >
> > > >
> > > >--------------------
> > > >
> > > >
> > > >
> > > >
>-------------------- >
>">http://docs.yahoo.com/info/terms/
Reply by Sifferman ●October 6, 20032003-10-06

OK, now the problem seems to have morphed into something repeatable.
I wrote some test code to solve another problem, that repeatedly calls
one routine to read data from a proprietary input port, and transmit
that data to a serial output port for viewing with Hyperterminal.
This code appears to work fine. But, the debugger does the following.
(Note: I am using MC9S12DG128B, P&E BDM Multilink, and Metrowerks
True-Time debugger.)

1. I click Start in the True-Time debugger, which starts up my code at
the Reset vector, using the BDM-Multilink. The target program starts
to run correctly, and I start seeing data appearing on Hyperterminal.

2. After a second or so, the debugger appears to halt on the BGND
instruction in the service routine for Unimplemented ISR 63, whose
vector is mapped to address 0xFF80. However, the program continues to
run properly on the target. Only the debugger has stopped. The Halt
button on the debugger toolbar is grayed-out and not available.

3. If I click on the Start button in the toolbar, nothing appears to
happen. The program continues to run on the target.

4. If I scroll through memory within the debugger while the program is
running and the debugger is in this halted state, it all reads FF.
All of the HC12 registers read FF, too, as does the CCR.

5. If I click on the Reset Target button on the toolbar, the program
in the target halts, and the debugger returns to its normal state. I
can then see the actual memory in the target, and the actual state of
the registers.

Any clues, I'd appreciate your ideas.

Thanks everyone.

Andy

------------------------------
--- In , "Sifferman" <asifferm@a...> wrote:
>
> Gilles -
>
> Good idea. The next time this happens, I will check the I bit and
> the
> stack, which might yield further clues as to what is happening.
>
> But I don't think a runaway processor would halt if it tried to
> execute the contents of 0xFF80 - this location would contain the
> address of the Unimplemented ISR service routine, and not the BGND
> instruction itself. The service routine for Unimplemented ISR 63
> occurs in memory AFTER all of the other Unimplemented ISR routines
> (all of which contain simply a single BGND instruction) - this is
the
> last BGND instruction, not the first. Therefore, it seems unlikely
> to
> me that the processor was executing runaway code and "happened" upon
> the BGND instruction. Though it is plausible that there might be a
> jump to that location.
>
> Thanks for the reply.
>
> Andy
>
> ----------------------------
> --- In , Gilles Blanquin <gblanquin@m...>
wrote:
> > Hi Andy.
> >
> > Can you make sure that when the debugger halts, the I bit is set?
> > I mean that the debugger will halt on any BGND instruction
> execution. A
> > jump to this address would do the same thing. But only an
interrupt
> will set I.
> >
> > I can imaging that the PC has "quitted" the program and
incremented
> till
> > reaching address FF80 and halted the debugger this way.
> >
> > Typically, the debugger is able to read the program call chain on
> the
> > device stack and display it in the Procedure window: If an
> interrupt
> > occurs, you should be able to find latest procedure called.
> >
> >
> > Best regards,
> > Gilles
> >
> >
> > At 11:10 PM 8/22/2003, you wrote:
> >
> > >Hello everyone -
> > >
> > >I am using the MC9S12DG128B with the P&E BDM-Multilink,
controlled
> by the
> > >Metrowerks True-Time debugger. I have been developing code for a
> few
> > >months now.
> > >
> > >Most of the time everything works fine. But every now and then
> (between
> > >several minutes to a few hours), the processor simply halts. In
> every case
> > >the True-Time debugger indicates that the processor has halted on
> the BGND
> > >instruction in the Unimplemented ISR trap.
> > >
> > >I modified the isr_vectors.c file to produce a unique (but
> identical)
> > >routine for each of the 64 vectors. This allowed me to identify
> that the
> > >trap occurs on Unimplemented ISR 63, whose vector is mapped to
> address 0xFF80.
> > >
> > >The MC9S12DT128B Device User Guide indicates that the vector at
> address
> > >0xFF80 is "Reserved." It is not assigned to any documented
> > >function. Therefore, I would expect that this vector would never
> be seen.
> > >
> > >I have only seen this behavior with the BDM-Multilink connected
to
> my
> > >target. I don't know if it will happen when the target is
running
> > >standalone. The problem occurs so infrequently that I really
> can't
> just
> > >sit around and wait for it to happen.
> > >
> > >Of course with an in-circuit emulator, I could set up a trace to
> see the
> > >executed instructions leading up to the interrupt. But alas, all
> I
> have is
> > >the humble BDM-Multilink.
> > >
> > >Anyone have any ideas about why this might be happening, or how I
> might
> > >debug it?
> > >
> > >Thanks.
> > >
> > >Andy
> > >
> > >
> > >
> > >
> > >--------------------
> > >
> > >
> > >
> > >
Reply by Gilles Blanquin ●September 5, 20032003-09-05

Hi Andy!

Oops! Sorry for this hilarious suggestion. I might have been seriously
tired that day. For sure, above 0xFF7F, there might be only vectors, no
BNGD and no trap ISRs.

An emulator would be nice to debug this. Also if you could port/test your
code on an MC9S12 "E" part (or any device featuring the DBG module),

http://e-www.motorola.com/webapp/sps/site/prod_summary.jsp?code=MC9S12E128&n
odeIdt3ZGpnLn8636K100

it features the DBG12 module i.e advanced triggers + "change-of-flow" trace
buffer.

http://e-www.motorola.com/files/microcontrollers/doc/ref_manual/S12DBGV1.pdf

Best regards,
Gilles

At 07:18 PM 9/4/2003, you wrote:

>Gilles -
>
>Good idea. The next time this happens, I will check the I bit and
>the
>stack, which might yield further clues as to what is happening.
>
>But I don't think a runaway processor would halt if it tried to
>execute the contents of 0xFF80 - this location would contain the
>address of the Unimplemented ISR service routine, and not the BGND
>instruction itself. The service routine for Unimplemented ISR 63
>occurs in memory AFTER all of the other Unimplemented ISR routines
>(all of which contain simply a single BGND instruction) - this is the
>last BGND instruction, not the first. Therefore, it seems unlikely
>to
>me that the processor was executing runaway code and "happened" upon
>the BGND instruction. Though it is plausible that there might be a
>jump to that location.
>
>Thanks for the reply.
>
>Andy
>
>----------------------------
>--- In , Gilles Blanquin <gblanquin@m...> wrote:
> > Hi Andy.
> >
> > Can you make sure that when the debugger halts, the I bit is set?
> > I mean that the debugger will halt on any BGND instruction
>execution. A
> > jump to this address would do the same thing. But only an interrupt
>will set I.
> >
> > I can imaging that the PC has "quitted" the program and incremented
>till
> > reaching address FF80 and halted the debugger this way.
> >
> > Typically, the debugger is able to read the program call chain on
>the
> > device stack and display it in the Procedure window: If an
>interrupt
> > occurs, you should be able to find latest procedure called.
> >
> >
> > Best regards,
> > Gilles
> >
> >
> > At 11:10 PM 8/22/2003, you wrote:
> >
> > >Hello everyone -
> > >
> > >I am using the MC9S12DG128B with the P&E BDM-Multilink, controlled
>by the
> > >Metrowerks True-Time debugger. I have been developing code for a
>few
> > >months now.
> > >
> > >Most of the time everything works fine. But every now and then
>(between
> > >several minutes to a few hours), the processor simply halts. In
>every case
> > >the True-Time debugger indicates that the processor has halted on
>the BGND
> > >instruction in the Unimplemented ISR trap.
> > >
> > >I modified the isr_vectors.c file to produce a unique (but
>identical)
> > >routine for each of the 64 vectors. This allowed me to identify
>that the
> > >trap occurs on Unimplemented ISR 63, whose vector is mapped to
>address 0xFF80.
> > >
> > >The MC9S12DT128B Device User Guide indicates that the vector at
>address
> > >0xFF80 is "Reserved." It is not assigned to any documented
> > >function. Therefore, I would expect that this vector would never
>be seen.
> > >
> > >I have only seen this behavior with the BDM-Multilink connected to
>my
> > >target. I don't know if it will happen when the target is running
> > >standalone. The problem occurs so infrequently that I really
>can't
>just
> > >sit around and wait for it to happen.
> > >
> > >Of course with an in-circuit emulator, I could set up a trace to
>see the
> > >executed instructions leading up to the interrupt. But alas, all
>I
>have is
> > >the humble BDM-Multilink.
> > >
> > >Anyone have any ideas about why this might be happening, or how I
>might
> > >debug it?
> > >
> > >Thanks.
> > >
> > >Andy
> > >
> > >
> > >
> > >
> > >--------------------
> > >
> > >
> > >
> > >
>-------------------- >
>">http://docs.yahoo.com/info/terms/




Reply by Sifferman ●September 4, 20032003-09-04

Gilles -

Good idea. The next time this happens, I will check the I bit and
the
stack, which might yield further clues as to what is happening.

But I don't think a runaway processor would halt if it tried to
execute the contents of 0xFF80 - this location would contain the
address of the Unimplemented ISR service routine, and not the BGND
instruction itself. The service routine for Unimplemented ISR 63
occurs in memory AFTER all of the other Unimplemented ISR routines
(all of which contain simply a single BGND instruction) - this is the
last BGND instruction, not the first. Therefore, it seems unlikely
to
me that the processor was executing runaway code and "happened" upon
the BGND instruction. Though it is plausible that there might be a
jump to that location.

Thanks for the reply.

Andy

----------------------------
--- In , Gilles Blanquin <gblanquin@m...> wrote:
> Hi Andy.
>
> Can you make sure that when the debugger halts, the I bit is set?
> I mean that the debugger will halt on any BGND instruction
execution. A
> jump to this address would do the same thing. But only an interrupt
will set I.
>
> I can imaging that the PC has "quitted" the program and incremented
till
> reaching address FF80 and halted the debugger this way.
>
> Typically, the debugger is able to read the program call chain on
the
> device stack and display it in the Procedure window: If an
interrupt
> occurs, you should be able to find latest procedure called. > Best regards,
> Gilles > At 11:10 PM 8/22/2003, you wrote:
>
> >Hello everyone -
> >
> >I am using the MC9S12DG128B with the P&E BDM-Multilink, controlled
by the
> >Metrowerks True-Time debugger. I have been developing code for a
few
> >months now.
> >
> >Most of the time everything works fine. But every now and then
(between
> >several minutes to a few hours), the processor simply halts. In
every case
> >the True-Time debugger indicates that the processor has halted on
the BGND
> >instruction in the Unimplemented ISR trap.
> >
> >I modified the isr_vectors.c file to produce a unique (but
identical)
> >routine for each of the 64 vectors. This allowed me to identify
that the
> >trap occurs on Unimplemented ISR 63, whose vector is mapped to
address 0xFF80.
> >
> >The MC9S12DT128B Device User Guide indicates that the vector at
address
> >0xFF80 is "Reserved." It is not assigned to any documented
> >function. Therefore, I would expect that this vector would never
be seen.
> >
> >I have only seen this behavior with the BDM-Multilink connected to
my
> >target. I don't know if it will happen when the target is running
> >standalone. The problem occurs so infrequently that I really
can't
just
> >sit around and wait for it to happen.
> >
> >Of course with an in-circuit emulator, I could set up a trace to
see the
> >executed instructions leading up to the interrupt. But alas, all
I
have is
> >the humble BDM-Multilink.
> >
> >Anyone have any ideas about why this might be happening, or how I
might
> >debug it?
> >
> >Thanks.
> >
> >Andy
> >
> >
> >
> >
> >--------------------
> >
> >
> >
>


Reply by Gilles Blanquin ●August 25, 20032003-08-25
Hi Andy.

Can you make sure that when the debugger halts, the I bit is set?
I mean that the debugger will halt on any BGND instruction execution. A
jump to this address would do the same thing. But only an interrupt will set I.

I can imaging that the PC has "quitted" the program and incremented till
reaching address FF80 and halted the debugger this way.

Typically, the debugger is able to read the program call chain on the
device stack and display it in the Procedure window: If an interrupt
occurs, you should be able to find latest procedure called. Best regards,
Gilles At 11:10 PM 8/22/2003, you wrote:

>Hello everyone -
>
>I am using the MC9S12DG128B with the P&E BDM-Multilink, controlled by the
>Metrowerks True-Time debugger. I have been developing code for a few
>months now.
>
>Most of the time everything works fine. But every now and then (between
>several minutes to a few hours), the processor simply halts. In every case
>the True-Time debugger indicates that the processor has halted on the BGND
>instruction in the Unimplemented ISR trap.
>
>I modified the isr_vectors.c file to produce a unique (but identical)
>routine for each of the 64 vectors. This allowed me to identify that the
>trap occurs on Unimplemented ISR 63, whose vector is mapped to address 0xFF80.
>
>The MC9S12DT128B Device User Guide indicates that the vector at address
>0xFF80 is "Reserved." It is not assigned to any documented
>function. Therefore, I would expect that this vector would never be seen.
>
>I have only seen this behavior with the BDM-Multilink connected to my
>target. I don't know if it will happen when the target is running
>standalone. The problem occurs so infrequently that I really can't just
>sit around and wait for it to happen.
>
>Of course with an in-circuit emulator, I could set up a trace to see the
>executed instructions leading up to the interrupt. But alas, all I have is
>the humble BDM-Multilink.
>
>Anyone have any ideas about why this might be happening, or how I might
>debug it?
>
>Thanks.
>
>Andy >
>
>-------------------- >
>">http://docs.yahoo.com/info/terms/