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 > > > > > > > > > > > > > > > > > > > > > > > > >-------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > >-------------------- > > > > > > > |
|
Trap on Unimplemented ISR
Started by ●August 22, 2003
Reply by ●October 13, 20032003-10-13
Reply by ●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/ |