Sam, >Is it just for the programming state machine, in order not to "fry" >the memory if Tbus is too long, even if EE-clock would be within range? As the note at the top of page 26 in the EETS4K Block User Guide V02.06 states, the restriction is because of the effect of clock synchronization on the functional timings. Just keep the bus clock above 1MHz and you should be in good shape. I agree, the flow chart in Figure 4-1 is *very* confusing. Here's the assembly code I use for determining values for the ECLKDIV & FCLKDIV registers: ; OscClk: equ 16000000 Eclock: equ 24000000 ; final E-clock frequency (PLL) RefClock: equ 8000000 REFDVVal: equ (OscClk/RefClock)-1 SYNRVal: equ (fEclock/RefClock)-1 if OscClk>12800000 FCLKDIVVal: equ (OscClk/200000/8)+FDIV8 else FCLKDIVVal: equ (OscClk/200000) endif ; Regards, Gordon Sam Laur wrote: >Gordon Doughman wrote: > >>You do *not* need to change the values of the ECLKDIV & FCLKDIV >>registers when changing the bus clock frequency. The values written to >>the ECLKDIV & FCLKDIV registers is based on the oscillator frequency >>(EXTAL). >> > >I can see that, but why is Tbus (in any way) related to those values? >See for example S12EETS4KV2.pdf Figure 4-1 where Tbus is in many >places. If I say that that diagram is a bit complicated, it's an >understatement, but I digress. I see from the block diagram >though that it is related only to the oscillator clock. > >Is it just for the programming state machine, in order not to "fry" >the memory if Tbus is too long, even if EE-clock would be within range? > >With a 16 MHz crystal, switching the bus clock from 8 MHz to 24 MHz >shouldn't do anything to the EEPROM clock dividider, since the >Tbus is so short compared to the minimum 5 s criterion. > >Anyway, I should have done more of the unpopular RTFM activity before >posting here. The problem was indeed solved by setting ALTCLK to the >correct value. Now I can step right over the PLL setting instruction, >and the software goes on as if nothing special happened. > >Thanks for all the help. > >Best wishes, >Sam Laur >Aumec Systems Oy >-------------------- > >">http://docs.yahoo.com/info/terms/ > -- =============================================================== Gordon Doughman Ph: 937-438-6811 Motorola Semiconductor Fax: 937-434-7457 Field Applications Engineer Pager: 800-759-8352 Pin: 1304089 Suite 175 3131 Newmark Drive Miamisburg, OH 45342 Check out my HC12 book at: http://www.rtcbooks.com/programming.php

Gordon Doughman wrote: > You do *not* need to change the values of the ECLKDIV & FCLKDIV > registers when changing the bus clock frequency. The values written to > the ECLKDIV & FCLKDIV registers is based on the oscillator frequency > (EXTAL). I can see that, but why is Tbus (in any way) related to those values? See for example S12EETS4KV2.pdf Figure 4-1 where Tbus is in many places. If I say that that diagram is a bit complicated, it's an understatement, but I digress. I see from the block diagram though that it is related only to the oscillator clock. Is it just for the programming state machine, in order not to "fry" the memory if Tbus is too long, even if EE-clock would be within range? With a 16 MHz crystal, switching the bus clock from 8 MHz to 24 MHz shouldn't do anything to the EEPROM clock dividider, since the Tbus is so short compared to the minimum 5 s criterion. Anyway, I should have done more of the unpopular RTFM activity before posting here. The problem was indeed solved by setting ALTCLK to the correct value. Now I can step right over the PLL setting instruction, and the software goes on as if nothing special happened. Thanks for all the help. Best wishes, Sam Laur Aumec Systems Oy

Sam, What is the crystal frequency of your target? As Gilles mentioned, you will need to use D-Bug12's ALTCLK command to specify the bus clock frequency when the PLL is engaged as the bus clock. For the S12 devices with the BDM/PLL errata D-Bug12 automatically sets the CLKSW bit in the BDM status register. Regards, Gordon Sam Laur wrote: >I've had some problems recently while trying to debug my program, >and enabling the PLL. What I'm doing is this: > >// PLL init > REFDV = 2; > SYNR = 0; > > while (BIT(CRGFLG,LOCK) == 0); > SET(CLKSEL,PLLSEL); // Wait until PLL locked, then select PLL >clk > >However, every BDM I've tried thus far crashes after that bit set. >Or more exactly, the communication stops. (NoICE 7.7, and BDM Multilink, >or ComPOD12, or microBDM12SX) > >I'm actually not running a real Technological Arts microBDM12SX board, >it's a Future Electronics 9S12BADGE with updated D-Bug software. >It seems to work well enough as a BDM, though. > >I've tried to switch CLKSW to 1 and 0 through the D-Bug12 BDM >interface, but it still behaves the same way all the time. >So "wbb ff01 c0" or "wbb ff01 c4", no difference. > >I was tracing up to that problem point a while ago, and logged >what happens: > >S>gt 730c >R> >Temporary Breakpoint Encountered > >PP PC SP X Y D = A:B CCR = SXHI NZVC >30 730C 3FC0 3FC8 21A3 27:10 1101 0100 >xx:730C 1F003708FB BRCLR $0037,#$08,$730C > >S>t > >PP PC SP X Y D = A:B CCR = SXHI NZVC >30 7311 3FC0 3FC8 21A3 27:10 1101 0100 >xx:7311 1C003980 BSET $0039,#$80 > >S>t >Can't Communicate With Target CPU > >What would be a working (but still low-cost) BDM for using the PLL, >or am I initializing it the wrong way somehow? > >With regards, >Sam Laur >Aumec Systems Oy >PS: I posted a while ago about the SPI locking problem. By chance, >there was another thread about SPI problems right after that, and >the posted initialization code seems to have helped. Thanks! >-------------------- > >">http://docs.yahoo.com/info/terms/ > -- =============================================================== Gordon Doughman Ph: 937-438-6811 Motorola Semiconductor Fax: 937-434-7457 Field Applications Engineer Pager: 800-759-8352 Pin: 1304089 Suite 175 3131 Newmark Drive Miamisburg, OH 45342 Check out my HC12 book at: http://www.rtcbooks.com/programming.php

Mike, You do *not* need to change the values of the ECLKDIV & FCLKDIV registers when changing the bus clock frequency. The values written to the ECLKDIV & FCLKDIV registers is based on the oscillator frequency (EXTAL). Regards, Gordon Mike Elphick wrote: >Sam. > >You need to change the values in the baud rate clock divisor registers to >accommodate the new clock speed. Specifically, for the 24MHz you are aiming >for, you need to deposit $009c in SCIxBDH/SCIxBDL to maintain a baud rate of >9600 as soon as the PPL is engaged. You will also need to change the values >for ECLKDIV and FCLKDIV to be able to write to EEPROM and flash. > >Mike >>I've had some problems recently while trying to debug my program, >>and enabling the PLL. What I'm doing is this: >> >>// PLL init >> REFDV = 2; >> SYNR = 0; >> >> while (BIT(CRGFLG,LOCK) == 0); >> SET(CLKSEL,PLLSEL); // Wait until PLL locked, then select PLL >>clk >> >>However, every BDM I've tried thus far crashes after that bit set. >>Or more exactly, the communication stops. (NoICE 7.7, and BDM Multilink, >>or ComPOD12, or microBDM12SX) >> >>I'm actually not running a real Technological Arts microBDM12SX board, >>it's a Future Electronics 9S12BADGE with updated D-Bug software. >>It seems to work well enough as a BDM, though. >> >>I've tried to switch CLKSW to 1 and 0 through the D-Bug12 BDM >>interface, but it still behaves the same way all the time. >>So "wbb ff01 c0" or "wbb ff01 c4", no difference. >> >>I was tracing up to that problem point a while ago, and logged >>what happens: >> >>S>gt 730c >>R> >>Temporary Breakpoint Encountered >> >>PP PC SP X Y D = A:B CCR = SXHI NZVC >>30 730C 3FC0 3FC8 21A3 27:10 1101 0100 >>xx:730C 1F003708FB BRCLR $0037,#$08,$730C >> >>S>t >> >>PP PC SP X Y D = A:B CCR = SXHI NZVC >>30 7311 3FC0 3FC8 21A3 27:10 1101 0100 >>xx:7311 1C003980 BSET $0039,#$80 >> >>S>t >>Can't Communicate With Target CPU >> >>What would be a working (but still low-cost) BDM for using the PLL, >>or am I initializing it the wrong way somehow? >> >>With regards, >>Sam Laur >>Aumec Systems Oy >> >> >>PS: I posted a while ago about the SPI locking problem. By chance, >>there was another thread about SPI problems right after that, and >>the posted initialization code seems to have helped. Thanks! > > > >-------------------- > >">http://docs.yahoo.com/info/terms/ > -- =============================================================== Gordon Doughman Ph: 937-438-6811 Motorola Semiconductor Fax: 937-434-7457 Field Applications Engineer Pager: 800-759-8352 Pin: 1304089 Suite 175 3131 Newmark Drive Miamisburg, OH 45342 Check out my HC12 book at: http://www.rtcbooks.com/programming.php

Sam. You need to change the values in the baud rate clock divisor registers to accommodate the new clock speed. Specifically, for the 24MHz you are aiming for, you need to deposit $009c in SCIxBDH/SCIxBDL to maintain a baud rate of 9600 as soon as the PPL is engaged. You will also need to change the values for ECLKDIV and FCLKDIV to be able to write to EEPROM and flash. Mike > I've had some problems recently while trying to debug my program, > and enabling the PLL. What I'm doing is this: > > // PLL init > REFDV = 2; > SYNR = 0; > > while (BIT(CRGFLG,LOCK) == 0); > SET(CLKSEL,PLLSEL); // Wait until PLL locked, then select PLL > clk > > However, every BDM I've tried thus far crashes after that bit set. > Or more exactly, the communication stops. (NoICE 7.7, and BDM Multilink, > or ComPOD12, or microBDM12SX) > > I'm actually not running a real Technological Arts microBDM12SX board, > it's a Future Electronics 9S12BADGE with updated D-Bug software. > It seems to work well enough as a BDM, though. > > I've tried to switch CLKSW to 1 and 0 through the D-Bug12 BDM > interface, but it still behaves the same way all the time. > So "wbb ff01 c0" or "wbb ff01 c4", no difference. > > I was tracing up to that problem point a while ago, and logged > what happens: > > S>gt 730c > R> > Temporary Breakpoint Encountered > > PP PC SP X Y D = A:B CCR = SXHI NZVC > 30 730C 3FC0 3FC8 21A3 27:10 1101 0100 > xx:730C 1F003708FB BRCLR $0037,#$08,$730C > > S>t > > PP PC SP X Y D = A:B CCR = SXHI NZVC > 30 7311 3FC0 3FC8 21A3 27:10 1101 0100 > xx:7311 1C003980 BSET $0039,#$80 > > S>t > Can't Communicate With Target CPU > > What would be a working (but still low-cost) BDM for using the PLL, > or am I initializing it the wrong way somehow? > > With regards, > Sam Laur > Aumec Systems Oy > PS: I posted a while ago about the SPI locking problem. By chance, > there was another thread about SPI problems right after that, and > the posted initialization code seems to have helped. Thanks!

Hi Sam. As far as I understand, you use the 9S12BADGE board as a BDM pod to debug another HCS12 device in BDM. Check the Reference Guide For DBug12 Version 4.x.x "DB12RG4.pdf". The ALTCLK - Specify An Alternate BDM Communications Rate command should help you to specify the target chip bus speed after PLL setup. Regards, Gilles At 03:09 PM 10/29/2003, you wrote: >I've had some problems recently while trying to debug my program, >and enabling the PLL. What I'm doing is this: > >// PLL init > REFDV = 2; > SYNR = 0; > > while (BIT(CRGFLG,LOCK) == 0); > SET(CLKSEL,PLLSEL); // Wait until PLL locked, then select PLL >clk > >However, every BDM I've tried thus far crashes after that bit set. >Or more exactly, the communication stops. (NoICE 7.7, and BDM Multilink, >or ComPOD12, or microBDM12SX) > >I'm actually not running a real Technological Arts microBDM12SX board, >it's a Future Electronics 9S12BADGE with updated D-Bug software. >It seems to work well enough as a BDM, though. > >I've tried to switch CLKSW to 1 and 0 through the D-Bug12 BDM >interface, but it still behaves the same way all the time. >So "wbb ff01 c0" or "wbb ff01 c4", no difference. > >I was tracing up to that problem point a while ago, and logged >what happens: > >S>gt 730c >R> >Temporary Breakpoint Encountered > >PP PC SP X Y D = A:B CCR = SXHI NZVC >30 730C 3FC0 3FC8 21A3 27:10 1101 0100 >xx:730C 1F003708FB BRCLR $0037,#$08,$730C > >S>t > >PP PC SP X Y D = A:B CCR = SXHI NZVC >30 7311 3FC0 3FC8 21A3 27:10 1101 0100 >xx:7311 1C003980 BSET $0039,#$80 > >S>t >Can't Communicate With Target CPU > >What would be a working (but still low-cost) BDM for using the PLL, >or am I initializing it the wrong way somehow? > >With regards, >Sam Laur >Aumec Systems Oy >PS: I posted a while ago about the SPI locking problem. By chance, >there was another thread about SPI problems right after that, and >the posted initialization code seems to have helped. Thanks! >-------------------- > >">http://docs.yahoo.com/info/terms/

I've had some problems recently while trying to debug my program, and enabling the PLL. What I'm doing is this: // PLL init REFDV = 2; SYNR = 0; while (BIT(CRGFLG,LOCK) == 0); SET(CLKSEL,PLLSEL); // Wait until PLL locked, then select PLL clk However, every BDM I've tried thus far crashes after that bit set. Or more exactly, the communication stops. (NoICE 7.7, and BDM Multilink, or ComPOD12, or microBDM12SX) I'm actually not running a real Technological Arts microBDM12SX board, it's a Future Electronics 9S12BADGE with updated D-Bug software. It seems to work well enough as a BDM, though. I've tried to switch CLKSW to 1 and 0 through the D-Bug12 BDM interface, but it still behaves the same way all the time. So "wbb ff01 c0" or "wbb ff01 c4", no difference. I was tracing up to that problem point a while ago, and logged what happens: S>gt 730c R> Temporary Breakpoint Encountered PP PC SP X Y D = A:B CCR = SXHI NZVC 30 730C 3FC0 3FC8 21A3 27:10 1101 0100 xx:730C 1F003708FB BRCLR $0037,#$08,$730C S>t PP PC SP X Y D = A:B CCR = SXHI NZVC 30 7311 3FC0 3FC8 21A3 27:10 1101 0100 xx:7311 1C003980 BSET $0039,#$80 S>t Can't Communicate With Target CPU What would be a working (but still low-cost) BDM for using the PLL, or am I initializing it the wrong way somehow? With regards, Sam Laur Aumec Systems Oy PS: I posted a while ago about the SPI locking problem. By chance, there was another thread about SPI problems right after that, and the posted initialization code seems to have helped. Thanks!