Sign in
Search 68hc12
Subscribe to 68hc12
68hc12 by Keywords
68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC
Ads
Discussion Groups
Discussion Groups | 68HC12 | Re: PE Micro Cable12 vs. PLL
Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
Re: PE Micro Cable12 vs. PLL - Jeff Smith - Sep 11 9:59:20 2007
--- In 6...@yahoogroups.com, "John Hartman (NoICE)" wrote:
> Having been handed the opportunity on a silver platter, I COULD
> suggest that you try NoICE :)
[...]
I missed my que earlier ;) but being a NoICE user, I want to explain
more about exactly what it is that NoICE has, and you are looking for,
and I've noticed that you're not finding it from P&E Micro. It's sad
because I'd like to see it from all the contributors to debugging tools.
First, of course NoICE is doing a real good job with my DP256B. I
always forget the PLL changes because mostly it never even asks for a
new frequency to try. It just works, as long as there's not something
else gone out of control with the MCU. But that's not the point I want
to make.
The big thing is the current interrest of NoICE. It's not an ignorant
company who's only goal is to be rich by leeching off of a giant like
Freescale (not trying to suggest that any specific company is).
Instead, John is simply interrested in good debugging capabilities.
For example, on September 1st, I emailed him with two problems and I
didn't know if he would care since debugging was basically working. I
was pleased to see a response September 3rd (maybe he was off to
church on the 2nd) and he was giving me patch files which fixed both
problems! They had to do with ways to view variables while debuging,
so I'm sure glad he agreed that would be important to have as much
versatility as possible. One of them is that when I view a variable of
an enum type, I'm not stuck with just seeing numbers and looking up
what they should mean. Now I can actually see the enumeration values
as defined in C. Very helpful!
So my point is that even if you do find trouble like you did with your
P&E, most likely John could get it fixed for you within a week (of
course it's worth it to him because he wants it working for everyone,
too).
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
> Having been handed the opportunity on a silver platter, I COULD
> suggest that you try NoICE :)
[...]
I missed my que earlier ;) but being a NoICE user, I want to explain
more about exactly what it is that NoICE has, and you are looking for,
and I've noticed that you're not finding it from P&E Micro. It's sad
because I'd like to see it from all the contributors to debugging tools.
First, of course NoICE is doing a real good job with my DP256B. I
always forget the PLL changes because mostly it never even asks for a
new frequency to try. It just works, as long as there's not something
else gone out of control with the MCU. But that's not the point I want
to make.
The big thing is the current interrest of NoICE. It's not an ignorant
company who's only goal is to be rich by leeching off of a giant like
Freescale (not trying to suggest that any specific company is).
Instead, John is simply interrested in good debugging capabilities.
For example, on September 1st, I emailed him with two problems and I
didn't know if he would care since debugging was basically working. I
was pleased to see a response September 3rd (maybe he was off to
church on the 2nd) and he was giving me patch files which fixed both
problems! They had to do with ways to view variables while debuging,
so I'm sure glad he agreed that would be important to have as much
versatility as possible. One of them is that when I view a variable of
an enum type, I'm not stuck with just seeing numbers and looking up
what they should mean. Now I can actually see the enumeration values
as defined in C. Very helpful!
So my point is that even if you do find trouble like you did with your
P&E, most likely John could get it fixed for you within a week (of
course it's worth it to him because he wants it working for everyone,
too).
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: PE Micro Cable12 vs. PLL - Jeff Smith - Sep 11 10:26:11 2007
--- In 6...@yahoogroups.com, "Jeff Smith" wrote:
> So my point is that even if you do find trouble like you did with
> your P&E, most likely John could get it fixed for you within a week
> (of course it's worth it to him because he wants it working for
> everyone, too).
I forgot to mention... you don't have to buy it to get support. John
fixed a whole slew of my initial requests, before I even paid for it.
Anyway that left a pretty good first impression :)
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
> So my point is that even if you do find trouble like you did with
> your P&E, most likely John could get it fixed for you within a week
> (of course it's worth it to him because he wants it working for
> everyone, too).
I forgot to mention... you don't have to buy it to get support. John
fixed a whole slew of my initial requests, before I even paid for it.
Anyway that left a pretty good first impression :)
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: PE Micro Cable12 vs. PLL - "James M. Knox" - Sep 11 10:26:54 2007
At 13:58 9/11/2007 +0000, you wrote:
>--- In 6...@yahoogroups.com, "John Hartman (NoICE)" wrote:
> > Having been handed the opportunity on a silver platter, I COULD
> > suggest that you try NoICE :)
>
>... and you are looking for, and I've noticed that you're not
>finding it from P&E Micro. It's sad because I'd like to see it from
>all the contributors to debugging tools.
I've been using P&E for years, ever since the early HC11 days. On
one hand, they offer good value (compared to $10K systems from some
other companies) - lower capabilities with MUCH lower prices, but
enough for most projects.
At the same time, they can be very frustrating. Quality control
(especially software) has been a frequent issue. One eventually
learns to just work around the DOS-like level of help files and
commands that just don't work right. Sometimes they have been
receptive to bug reports, other times it's a great big bit bucket (I
suspect a very small company, that sometimes drowns under their own success).
All of us who use their products have big collections of broken
interfaces that sit on a shelf, no longer communicating. [I think I
have at least three of the BDM pods like that at the moment.] But
all-in-all, their stuff has gotten me through a lot of projects, and
I do not regret any of the purchases. I have recommended them (with
caveats) to others.
>I always forget the PLL changes because mostly it never even asks for a
>new frequency to try. It just works, as long as there's not something
>else gone out of control with the MCU.
This PLL thing may be what finally drives me to try something new. I
ran into a similar problem with the HC08, and P&E told me that
basically it just doesn't work in any mode except fixed frequency -
basically controlled by the pod.
I've done some more experimentation, and I can run the basic crystal
clock up to 2X (I'm using a 4 MHz crystal). With a SYNR of 1
(multiplies by 2) the pod *will* resynch - if I do everything just
right. Any faster and it just sits there and suggests a reset. Note
that the board itself continues to run fine - all the way up to 48
MHz internal (24 MHz bus).
I can do a lot debugging at the lower speeds, but the project
eventually HAS to run at the highest.
>So my point is that even if you do find trouble like you did with your
>P&E, most likely John could get it fixed for you within a week (of
>course it's worth it to him because he wants it working for everyone,
>too).
My concern is that it is not the software, but the hardware that is
the issue. These old pods were originally designed to work with
HC11's running at ... well, about as fast as I am able to get this
one to work. The "debug" chip in the pod is an HC11 - and it may
simply have trouble with the higher speeds. In that case, no
software change is going to fix the problem.
[Anyone using the old parallel Rev-D pods at the higher target board speeds?]
I can certainly purchase a newer P&E USB pod (we are using those for
HC08 projects), but we have had trouble using the USB pods *and* our
USB data port on the same computer. It looses the USB pod every
time, and we have to reboot. The parallel pod doesn't cause this problem.
As much as I hate to change debuggers mid-project, I may give NoICE a
test - at least that will tell me if it's a HW vs. SW issue.
Thanks for the information...
jmk
-----------------------------------------------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 j...@trisoft.com
-----------------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
>--- In 6...@yahoogroups.com, "John Hartman (NoICE)"
> > Having been handed the opportunity on a silver platter, I COULD
> > suggest that you try NoICE :)
>
>... and you are looking for, and I've noticed that you're not
>finding it from P&E Micro. It's sad because I'd like to see it from
>all the contributors to debugging tools.
I've been using P&E for years, ever since the early HC11 days. On
one hand, they offer good value (compared to $10K systems from some
other companies) - lower capabilities with MUCH lower prices, but
enough for most projects.
At the same time, they can be very frustrating. Quality control
(especially software) has been a frequent issue. One eventually
learns to just work around the DOS-like level of help files and
commands that just don't work right. Sometimes they have been
receptive to bug reports, other times it's a great big bit bucket (I
suspect a very small company, that sometimes drowns under their own success).
All of us who use their products have big collections of broken
interfaces that sit on a shelf, no longer communicating. [I think I
have at least three of the BDM pods like that at the moment.] But
all-in-all, their stuff has gotten me through a lot of projects, and
I do not regret any of the purchases. I have recommended them (with
caveats) to others.
>I always forget the PLL changes because mostly it never even asks for a
>new frequency to try. It just works, as long as there's not something
>else gone out of control with the MCU.
This PLL thing may be what finally drives me to try something new. I
ran into a similar problem with the HC08, and P&E told me that
basically it just doesn't work in any mode except fixed frequency -
basically controlled by the pod.
I've done some more experimentation, and I can run the basic crystal
clock up to 2X (I'm using a 4 MHz crystal). With a SYNR of 1
(multiplies by 2) the pod *will* resynch - if I do everything just
right. Any faster and it just sits there and suggests a reset. Note
that the board itself continues to run fine - all the way up to 48
MHz internal (24 MHz bus).
I can do a lot debugging at the lower speeds, but the project
eventually HAS to run at the highest.
>So my point is that even if you do find trouble like you did with your
>P&E, most likely John could get it fixed for you within a week (of
>course it's worth it to him because he wants it working for everyone,
>too).
My concern is that it is not the software, but the hardware that is
the issue. These old pods were originally designed to work with
HC11's running at ... well, about as fast as I am able to get this
one to work.
simply have trouble with the higher speeds. In that case, no
software change is going to fix the problem.
[Anyone using the old parallel Rev-D pods at the higher target board speeds?]
I can certainly purchase a newer P&E USB pod (we are using those for
HC08 projects), but we have had trouble using the USB pods *and* our
USB data port on the same computer. It looses the USB pod every
time, and we have to reboot. The parallel pod doesn't cause this problem.
As much as I hate to change debuggers mid-project, I may give NoICE a
test - at least that will tell me if it's a HW vs. SW issue.
Thanks for the information...
jmk
-----------------------------------------------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 j...@trisoft.com
-----------------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: PE Micro Cable12 vs. PLL - Jeff Smith - Sep 11 17:56:04 2007
--- In 6...@yahoogroups.com, "James M. Knox" wrote:
[...]
> My concern is that it is not the software, but the hardware that is
> the issue. These old pods were originally designed to work with
> HC11's running at ... well, about as fast as I am able to get this
> one to work. The "debug" chip in the pod is an HC11 - and it
> may simply have trouble with the higher speeds. In that case, no
> software change is going to fix the problem.
>
> [Anyone using the old parallel Rev-D pods at the higher target
> board speeds?]
>
> I can certainly purchase a newer P&E USB pod (we are using those
> for HC08 projects), but we have had trouble using the USB pods
> *and* our USB data port on the same computer. It looses the USB pod
> every time, and we have to reboot. The parallel pod doesn't cause
> this problem.
>
> As much as I hate to change debuggers mid-project, I may give NoICE
> a test - at least that will tell me if it's a HW vs. SW issue.
>
> Thanks for the information...
> jmk
I agree that the symptoms show that the hardware probably has trouble
keeping up with the increased BDM clock, but this might help alot:
See back where John explained about setting CLKSW bit in the BDMSTS
register? It seems that NoICE is smart enough to overcome some errata
concerning certain targets, which some debuggers do not.
Here are my references for debug hardware which I've trusted. None
have broke on me, but if they do I can repair them.
http://www.evbplus.com/products.html
http://www.technologicalarts.ca/
TBDML (can't say where to get it, but I built a good one for less than
$10)
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
[...]
> My concern is that it is not the software, but the hardware that is
> the issue. These old pods were originally designed to work with
> HC11's running at ... well, about as fast as I am able to get this
> one to work.
> may simply have trouble with the higher speeds. In that case, no
> software change is going to fix the problem.
>
> [Anyone using the old parallel Rev-D pods at the higher target
> board speeds?]
>
> I can certainly purchase a newer P&E USB pod (we are using those
> for HC08 projects), but we have had trouble using the USB pods
> *and* our USB data port on the same computer. It looses the USB pod
> every time, and we have to reboot. The parallel pod doesn't cause
> this problem.
>
> As much as I hate to change debuggers mid-project, I may give NoICE
> a test - at least that will tell me if it's a HW vs. SW issue.
>
> Thanks for the information...
> jmk
I agree that the symptoms show that the hardware probably has trouble
keeping up with the increased BDM clock, but this might help alot:
See back where John explained about setting CLKSW bit in the BDMSTS
register? It seems that NoICE is smart enough to overcome some errata
concerning certain targets, which some debuggers do not.
Here are my references for debug hardware which I've trusted. None
have broke on me, but if they do I can repair them.
http://www.evbplus.com/products.html
http://www.technologicalarts.ca/
TBDML (can't say where to get it, but I built a good one for less than
$10)
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: PE Micro Cable12 vs. PLL - "James M. Knox" - Sep 11 18:06:07 2007
At 21:53 9/11/2007 +0000, you wrote:
>I agree that the symptoms show that the hardware probably has trouble
>keeping up with the increased BDM clock, but this might help alot:
>
>See back where John explained about setting CLKSW bit in the BDMSTS
>register? It seems that NoICE is smart enough to overcome some errata
>concerning certain targets, which some debuggers do not.
The P&E software does not apparently let you **specifically** set the
CLKSW bit (even though they mention it in a forum note). But I found
a configuration setting that apparently does that (just doesn't use
the name). Without it, the pod won't track across ANY clock change at all.
jmk
-----------------------------------------------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 j...@trisoft.com
-----------------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
>I agree that the symptoms show that the hardware probably has trouble
>keeping up with the increased BDM clock, but this might help alot:
>
>See back where John explained about setting CLKSW bit in the BDMSTS
>register? It seems that NoICE is smart enough to overcome some errata
>concerning certain targets, which some debuggers do not.
The P&E software does not apparently let you **specifically** set the
CLKSW bit (even though they mention it in a forum note). But I found
a configuration setting that apparently does that (just doesn't use
the name). Without it, the pod won't track across ANY clock change at all.
jmk
-----------------------------------------------
James M. Knox
TriSoft ph 512-385-0316
1300 Koenig Lane West fax 512-371-5716
Suite 200
Austin, Tx 78756 j...@trisoft.com
-----------------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )