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/ |