|
Hello to all, I have a very strange problem. I designed one year ago a led sign display controller with an MC9S12A128, the board has an external 128Kbytes RAM mapped to the bus and one 29F040 used as storage. The board has a 16Mhz cristal oscillator and works at 24MHZ bus frecuency using the PLL. There are about 5 differents versions of firmware working without problem with an MC9S12A128. Recently i needed more Flash memory for the firmware and i decide to migrate to an MC9S12A256, and here started my problems... I download the firmware to the board using the CW 3.0 debugger with an USB MULTILINK interface, all works ok. If the PLL is not active, all works ok, i can single step and insert breakpoints into the code. But when the PLL is activate , when i insert a breakpoint or i execute a halt command , the debugger losses contact with the board. If i not stops the firmware, for example doing a refresh of the memory dump window every 10 mS i can see that the USB Multiling is in contact with target,also when the PLL is active. That problem only happens with the MC9S12A256B, i tested an MC9S12DP256 and that not happens. Here is the code that enables the PLL: void InitPLL(void) { CLKSEL &= ~BM_PLLSEL; // ME ASEGURO QUE NO ESTA SELECCIONADO EL PLL PLLCTL |= BM_PLLON+BM_AUTO; // Habilito el PLL en modo automatico REFDV = S12_REFDV; // Cargo Reference Divider Register SYNR = S12_SYNR; // Cargo Synthesizer Multiplier while ((CRGFLG & BM_LOCK) == 0) ; // Espero a que el PLL se enganche CLKSEL |= BM_PLLSEL; // Selecciono el PLL clock } Any Idea? Regards Javier Ruiz BKB ELECTRONICA SL SPAIN |
|
|
I Can not debug with P&E USB MULTILINK & MC9S12A256
Started by ●January 21, 2004
Reply by ●January 22, 20042004-01-22
|
Hi, I suspect life with BDM on HCS12 is like that. I am finding P&E parallel Multilink cable and Cosmic Zap very slick, but can be a real pain at times. PowerPC's BDM is difficult, but P&E's HC16's BDM was very stable. In all three cases I would change the pll multiplier. Andrew Lohmann AIIE Design Engineer PLEASE NOTE NEW EMAIL ADDRESS IS: Bellingham + Stanley Ltd. Longfield Road, Tunbridge Wells, Kent, TN2 3EY, England. Tel: +44 (0) 1892 500400 Fax: +44 (0) 1892 543115 Website: www.bs-ltd.com ----- Original Message ----- From: Javier Ruiz To: Sent: Wednesday, January 21, 2004 8:21 PM Subject: [68HC12] I Can not debug with P&E USB MULTILINK & MC9S12A256 Hello to all, I have a very strange problem. I designed one year ago a led sign display controller with an MC9S12A128, the board has an external 128Kbytes RAM mapped to the bus and one 29F040 used as storage. The board has a 16Mhz cristal oscillator and works at 24MHZ bus frecuency using the PLL. There are about 5 differents versions of firmware working without problem with an MC9S12A128. Recently i needed more Flash memory for the firmware and i decide to migrate to an MC9S12A256, and here started my problems... I download the firmware to the board using the CW 3.0 debugger with an USB MULTILINK interface, all works ok. If the PLL is not active, all works ok, i can single step and insert breakpoints into the code. But when the PLL is activate , when i insert a breakpoint or i execute a halt command , the debugger losses contact with the board. If i not stops the firmware, for example doing a refresh of the memory dump window every 10 mS i can see that the USB Multiling is in contact with target,also when the PLL is active. That problem only happens with the MC9S12A256B, i tested an MC9S12DP256 and that not happens. Here is the code that enables the PLL: void InitPLL(void) { CLKSEL &= ~BM_PLLSEL; // ME ASEGURO QUE NO ESTA SELECCIONADO EL PLL PLLCTL |= BM_PLLON+BM_AUTO; // Habilito el PLL en modo automatico REFDV = S12_REFDV; // Cargo Reference Divider Register SYNR = S12_SYNR; // Cargo Synthesizer Multiplier while ((CRGFLG & BM_LOCK) == 0) ; // Espero a que el PLL se enganche CLKSEL |= BM_PLLSEL; // Selecciono el PLL clock } Any Idea? Regards Javier Ruiz BKB ELECTRONICA SL SPAIN --------------------To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu o learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu ------ Yahoo! Groups Links a.. To |
Reply by ●January 22, 20042004-01-22
|
In True-Time Simulator & Real Time Debugger, open ICD-12,
Communication, Special Setup tab and check Set CLKSW bit in BDM..... Even that, tracing is sometimes lost when clock frequency is changed. Jordi Costa ----- Original Message ----- From: "Javier Ruiz" <> To: <> Sent: Wednesday, January 21, 2004 9:21 PM Subject: [68HC12] I Can not debug with P&E USB MULTILINK & MC9S12A256 >[...............] > Recently i needed more Flash memory for the firmware and i decide to migrate to an MC9S12A256, and here started my problems... > > I download the firmware to the board using the CW 3.0 debugger with an USB MULTILINK interface, all works ok. > > If the PLL is not active, all works ok, i can single step and insert breakpoints into the code. > > But when the PLL is activate , when i insert a breakpoint or i execute a halt command , the debugger losses contact with the board. > Any Idea? >[...............] |
|
|
Reply by ●January 22, 20042004-01-22
|
Hello Javier. I already replied to this in the newsgroup, so just pasting again: 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/window, speed variation detections by the cable should be reported there like this: "Frequency change detected, reconnecting using io_delay_count: "<number>" I guess that the some A256 mask also need this PLL filter. A128(B?) is a different mask and probably does not behave the same way. Regards, Gilles At 09:21 PM 1/21/2004, you wrote: >Hello to all, > >I have a very strange problem. > >I designed one year ago a led sign display controller with an MC9S12A128, >the board has an external 128Kbytes RAM mapped to the bus and one 29F040 >used as storage. > >The board has a 16Mhz cristal oscillator and works at 24MHZ bus frecuency >using the PLL. > >There are about 5 differents versions of firmware working without problem >with an MC9S12A128. > >Recently i needed more Flash memory for the firmware and i decide to >migrate to an MC9S12A256, and here started my problems... > >I download the firmware to the board using the CW 3.0 debugger with an USB >MULTILINK interface, all works ok. > >If the PLL is not active, all works ok, i can single step and insert >breakpoints into the code. > >But when the PLL is activate , when i insert a breakpoint or i execute a >halt command , the debugger losses contact with the board. > >If i not stops the firmware, for example doing a refresh of the memory >dump window every 10 mS i can see that the USB Multiling is in contact >with target,also when the PLL is active. > >That problem only happens with the MC9S12A256B, i tested an MC9S12DP256 >and that not happens. > >Here is the code that enables the PLL: > >void InitPLL(void) { > > CLKSEL &= ~BM_PLLSEL; // ME ASEGURO QUE NO ESTA > SELECCIONADO EL PLL > PLLCTL |= BM_PLLON+BM_AUTO; // Habilito el PLL en modo automatico > REFDV = S12_REFDV; // Cargo Reference Divider Register > SYNR = S12_SYNR; // Cargo Synthesizer Multiplier > while ((CRGFLG & BM_LOCK) == 0) ; // Espero a que el PLL se enganche > CLKSEL |= BM_PLLSEL; // Selecciono el PLL clock > } > >Any Idea? > >Regards > Javier Ruiz > BKB ELECTRONICA SL > SPAIN > >--------------------To learn more >about Motorola Microcontrollers, please visit >http://www.motorola.com/mcu >o learn more about Motorola Microcontrollers, please visit >http://www.motorola.com/mcu > |
Reply by ●January 22, 20042004-01-22
|
Hello Jordi, thanks for your answer, i discovered the problem this
morning. The MC9S12A256 that i mounted in this new boards are MASK Set 1K79X. I found in the Motorola web page the document MSE9S12DP256_1K79X.PDF relating MASK erratas and i found that my problem is the ERRATA NUMBER MUCTS00436: BDM:loses sync when using PLL at high frecuencies Seting the CLKSW=1 with the PLL activated, the BDM resyncronices it self. Thanks and Best Regards Javier Ruiz BKB ELECTRONICA SL SPAIN ----- Original Message ----- From: Jordi Costa To: Sent: Thursday, January 22, 2004 10:08 AM Subject: Re: [68HC12] I Can not debug with P&E USB MULTILINK & MC9S12A256 In True-Time Simulator & Real Time Debugger, open ICD-12, Communication, Special Setup tab and check Set CLKSW bit in BDM..... Even that, tracing is sometimes lost when clock frequency is changed. Jordi Costa ----- Original Message ----- From: "Javier Ruiz" <> To: <> Sent: Wednesday, January 21, 2004 9:21 PM Subject: [68HC12] I Can not debug with P&E USB MULTILINK & MC9S12A256 >[...............] > Recently i needed more Flash memory for the firmware and i decide to migrate to an MC9S12A256, and here started my problems... > > I download the firmware to the board using the CW 3.0 debugger with an USB MULTILINK interface, all works ok. > > If the PLL is not active, all works ok, i can single step and insert breakpoints into the code. > > But when the PLL is activate , when i insert a breakpoint or i execute a halt command , the debugger losses contact with the board. > Any Idea? >[...............] --------------------To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu o learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu ------ Yahoo! Groups Links a.. To |
|
|
Reply by ●January 23, 20042004-01-23
|
The 1K79X mask set has a number of serious bugs. We appreciate that the S12 is complex (& good) and accept that early releases can have identified bugs. But we also expect that the manufacturer will take the first opportunity to fix the problems. I was surprised, then, that a recent delivery of A256s was still mask set 1K79X. In our case, it was intended that the A256 replace DP256Cs we had been using, and now we find we can't protect our code (one of the serious bugs with 1K79X - it also has some serious issues with the serial port). I should have checked the mask set number, of course, but then again, 12 months down the track one might reasonably expect that the major problems have been addressed. After all, you only find out about them from lists like this or by delving very, very deeply into errata documents. P.S. still praying for an E256. bruce --- In , "Javier Ruiz" <android@j...> wrote: > The MC9S12A256 that i mounted in this new boards are MASK Set 1K79X. > > I found in the Motorola web page the document MSE9S12DP256_1K79X.PDF relating MASK erratas and i found that my problem is the ERRATA NUMBER MUCTS00436: > > BDM:loses sync when using PLL at high frecuencies > > Seting the CLKSW=1 with the PLL activated, the BDM resyncronices it self. > |
|
|
Reply by ●January 23, 20042004-01-23
|
Bruce, Here is what I belive happens with these MC9S12D family parts: The MC9S12D family parts are extensively used in automotive applications. You can envision the automotive companies sit at the end of the Motorola production lines with sacks and collect all the latest silicon mask set parts that Motorola can manufacture. Motorola give precedence to the big automotive companies, so what's left for the small customers is sometimes old silicon mask-sets that are left in large quantities at the Motorola distributors (since Motorola won't sell direct to small customers) In order to attempt to resolve the problem I believe Motorola have tried to sort out the mask-set revisions by assigning different part numbers to different mask-sets with Major improvements. For example: DP256 mask-set 0K36N is marked DP256 DP256 mask-set 0K79X and 1K79X is marked DP256B DP256 mask-set 2K79X is marked DP256C DT256 mask-set 0L91N (latest mask-set) is marked DT256 (it has 3 MSCANs as opposed to 5 MSCANs on the DP256). I believe if you specify the part number DP256C... (or A256C... if such a part number exists) you stand higher chances of receiving mask set 2K79X which you are looking for. Hope this helps, Doron Nohau Corporation HC12 In-Circuit Emulators www.nohau.com/emul12pc.html At 08:06 23/01/2004 +0000, you wrote: >The 1K79X mask set has a number of serious bugs. > >We appreciate that the S12 is complex (& good) and accept that early >releases can have identified bugs. But we also expect that the >manufacturer will take the first opportunity to fix the problems. > >I was surprised, then, that a recent delivery of A256s was still mask >set 1K79X. In our case, it was intended that the A256 replace DP256Cs >we had been using, and now we find we can't protect our code (one of >the serious bugs with 1K79X - it also has some serious issues with the >serial port). > >I should have checked the mask set number, of course, but then again, >12 months down the track one might reasonably expect that the major >problems have been addressed. After all, you only find out about them >from lists like this or by delving very, very deeply into errata >documents. > >P.S. still praying for an E256. >bruce > >--- In , "Javier Ruiz" <android@j...> wrote: > > The MC9S12A256 that i mounted in this new boards are MASK Set 1K79X. > > > > I found in the Motorola web page the document MSE9S12DP256_1K79X.PDF >relating MASK erratas and i found that my problem is the ERRATA NUMBER >MUCTS00436: > > > > BDM:loses sync when using PLL at high frecuencies > > > > Seting the CLKSW=1 with the PLL activated, the BDM resyncronices it >self. > > >--------------------To learn more >about Motorola Microcontrollers, please visit >http://www.motorola.com/mcu >o learn more about Motorola Microcontrollers, please visit >http://www.motorola.com/mcu > |
|
|
Reply by ●January 23, 20042004-01-23
|
Doron, Thanks - your posts are always appreciated. I don't believe there is an A256C. There's just the flawed A256B. At least it doesn't appear on the M website - Happy to be corrected on this :-). [We have been using the DP256C and it is just fine - it's just that we don't use CAN and the A256 looks an obvious substitute, unless you read this list.] bruce --- In , Doron Fael <doronf@n...> wrote: > Bruce, > > Here is what I belive happens with these MC9S12D family parts: > > The MC9S12D family parts are extensively used in automotive applications. > You can envision the automotive companies sit at the end of the Motorola > production lines with sacks and collect all the latest silicon mask set > parts that Motorola can manufacture. Motorola give precedence to the big > automotive companies, so what's left for the small customers is sometimes > old silicon mask-sets that are left in large quantities at the Motorola > distributors (since Motorola won't sell direct to small customers) > > In order to attempt to resolve the problem I believe Motorola have tried to > sort out the mask-set revisions by assigning different part numbers to > different mask-sets with Major improvements. For example: > > DP256 mask-set 0K36N is marked DP256 > DP256 mask-set 0K79X and 1K79X is marked DP256B > DP256 mask-set 2K79X is marked DP256C > DT256 mask-set 0L91N (latest mask-set) is marked DT256 (it has 3 MSCANs as > opposed to 5 MSCANs on the DP256). > > I believe if you specify the part number DP256C... (or A256C... if such a > part number exists) you stand higher chances of receiving mask set 2K79X > which you are looking for. > > Hope this helps, > Doron > Nohau Corporation > HC12 In-Circuit Emulators > www.nohau.com/emul12pc.html > > At 08:06 23/01/2004 +0000, you wrote: > >The 1K79X mask set has a number of serious bugs. > > > >We appreciate that the S12 is complex (& good) and accept that early > >releases can have identified bugs. But we also expect that the > >manufacturer will take the first opportunity to fix the problems. > > > >I was surprised, then, that a recent delivery of A256s was still mask > >set 1K79X. In our case, it was intended that the A256 replace DP256Cs > >we had been using, and now we find we can't protect our code (one of > >the serious bugs with 1K79X - it also has some serious issues with the > >serial port). > > > >I should have checked the mask set number, of course, but then again, > >12 months down the track one might reasonably expect that the major > >problems have been addressed. After all, you only find out about them > >from lists like this or by delving very, very deeply into errata > >documents. > > > >P.S. still praying for an E256. > >bruce > > > >--- In , "Javier Ruiz" <android@j...> wrote: > > > The MC9S12A256 that i mounted in this new boards are MASK Set 1K79X. > > > > > > I found in the Motorola web page the document MSE9S12DP256_1K79X.PDF > >relating MASK erratas and i found that my problem is the ERRATA NUMBER > >MUCTS00436: > > > > > > BDM:loses sync when using PLL at high frecuencies > > > > > > Seting the CLKSW=1 with the PLL activated, the BDM resyncronices it > >self. > > > > > > > > > > >--------------------To learn more > >about Motorola Microcontrollers, please visit > >http://www.motorola.com/mcu > >o learn more about Motorola Microcontrollers, please visit > >http://www.motorola.com/mcu > > > > > > |
|
|
Reply by ●January 23, 20042004-01-23
|
There is, in fact, an A256C with mask 2K79X...they are loaded on the boards
I am developing with. Bill At 09:18 AM 1/23/2004 +0000, you wrote: >Doron, >Thanks - your posts are always appreciated. >I don't believe there is an A256C. There's just the flawed A256B. >At least it doesn't appear on the M website - Happy to be corrected on >this :-). |
|
|
Reply by ●January 23, 20042004-01-23
|
Bill, that's good news, I guess. Somehow I still feel bad. So, all, be advised: Digikey is still shipping the A256B. bruce ___________________ --- In , "William R. Elliot" <bill@w...> wrote: > There is, in fact, an A256C with mask 2K79X...they are loaded on the boards > I am developing with. > > Bill > > At 09:18 AM 1/23/2004 +0000, you wrote: > > >Doron, > >Thanks - your posts are always appreciated. > >I don't believe there is an A256C. There's just the flawed A256B. > >At least it doesn't appear on the M website - Happy to be corrected on > >this :-). |
