68300

Been reading up on TPU stuff, and if I want to attempt to use some of the
more esoteric TPU development features (single step, breakpoints, etc.), it
appears that I need to put the '332 in test mode.  My '332 user's manual
doesn't show the TSTME pin, but somewhere I remember reading that TSC and
TSTME shared a pin.  Anyone know for sure?

Furthermore, the original (not rev 1) TPU ref manual mentions that there is
some documentation of the test submodule registers in the '332 user's
manual.  I suspect that later revs of the '332 book removed detail, so if
anyone has a link to an online copy of a really old '332 user manual,
please pass it on!


thanks,
newell

Scott:
 
    The TSC and the TSTME signal do share the same pin, pin 57 on the 132 pin package and pin 80 on the 144 pin package.  If you want to have the '332 tristated you need to pull this pin to 1.6 * Vdd.  Pulling it low will place it into test mode.  Pulling it to 5 V is where this pin should usually be.  
 
Regards, 

John Honnold 
Motorola SPS 
Technical Information Center 
MCU 16/32 Bit Applications Engineer 

 -----Original Message-----
From: Scott Newell [mailto:newell@...]
Sent: Monday, November 18, 2002 8:24 AM
To: 68300@yahoogroups.com
Subject: [68300] Where's TSTME?



Been reading up on TPU stuff, and if I want to attempt to use some of the
more esoteric TPU development features (single step, breakpoints, etc.), it
appears that I need to put the '332 in test mode.  My '332 user's manual
doesn't show the TSTME pin, but somewhere I remember reading that TSC and
TSTME shared a pin.  Anyone know for sure?

Furthermore, the original (not rev 1) TPU ref manual mentions that there is
some documentation of the test submodule registers in the '332 user's
manual.  I suspect that later revs of the '332 book removed detail, so if
anyone has a link to an online copy of a really old '332 user manual,
please pass it on!


thanks,
newell



Yahoo! Groups Sponsor	

ADVERTISEMENT
 <http://rd.yahoo.com/M=240188.2647639.4038785.2225243/D=egroupweb/S=1706554205:HM/A=1321406/R=0/*http://www.e-dealsdaily.com/soundbug/> 	
  <http://us.adserver.yahoo.com/l?M=240188.2647639.4038785.2225243/D=egroupmail/S=:HM/A=1321406/rand=854144007> 	

---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> 



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . 




[Non-text portions of this message have been removed]

Hi all

I am still being given lots of grief by the TPU and am
now looking at TPU debuggers, and noticed that John
Honold talked of puting the 332 into a test mode.

What is this test mode & does it apply to the 376 ?

Also anybody got any advice on TPU debuggers that work
and are free or cheap and any other tools that may
help with solving TPU issues ?

               thanks Roy

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com

--- In 68300@y..., Roy <spectric@y...> wrote:
> Hi all
> 
> I am still being given lots of grief by the TPU and am
> now looking at TPU debuggers, and noticed that John
> Honold talked of puting the 332 into a test mode.
> 
> What is this test mode & does it apply to the 376 ?
> 
> Also anybody got any advice on TPU debuggers that work
> and are free or cheap and any other tools that may
> help with solving TPU issues ?
> 
>                thanks Roy

Hi,

when I wrote a TPU function I also didn´t get the debugging mode 
running. I used a very slow TPU clock and monitored the parameter RAM 
of the TPU with my own software. So I could see, what was going on. 
Some internal states were stored in dedicated bits of the parameter 
RAM and I was able to follow the internal stages of my TPU software. 
It is also possible to use extra bits, just to show the CPU were the 
TPU is working.
In my application (IIC-Bus) this approach worked quite fast, so that I 
never had to understand why this debugging mode of the TPU does not 
work.

Best regards

Arno Morbach

>I am still being given lots of grief by the TPU and am
>now looking at TPU debuggers, and noticed that John
>Honold talked of puting the 332 into a test mode.

My understand (still untested) is that you have to take TSC low _and_ flip
some register bits to get into test mode, at least on the '332.


>Also anybody got any advice on TPU debuggers that work
>and are free or cheap and any other tools that may
>help with solving TPU issues ?

The original TPU book has a section with some details on the debug hardware
built into the TPU.  There's a copy on the web--google for "TPU microcode
reference" ought to do it.

There's a free dos based TPU debugger (TPUBUG) from Moto out as well, but
I've yet to fire it up.  The readme file for it looks promising.

http://e-www.motorola.com/collateral/TPUBUGDBG.zip

Charles Melear offered to send TPU info to anyone with a mailing address
not 5 days ago on this very list--you should take him up on it.  Good stuff
in a box.


newell

Scott,
 
I have used the free debugger and it is OK.  It is not the last word in debuggers but it is free and it is better than what you have now.
 
(Because you have no debugger at all.)
 
All you need to do is tie the TSTME/TSC pin low and the software does the rest.  If you can't find the documentation, send me a note and I will get it for you.
 
Charlie

-----Original Message-----
From: Scott Newell [mailto:newell@...]
Sent: Tuesday, November 19, 2002 7:21 AM
To: 68300@yahoogroups.com
Subject: Re: [68300] TPU debugging


>I am still being given lots of grief by the TPU and am
>now looking at TPU debuggers, and noticed that John
>Honold talked of puting the 332 into a test mode.

My understand (still untested) is that you have to take TSC low _and_ flip
some register bits to get into test mode, at least on the '332.


>Also anybody got any advice on TPU debuggers that work
>and are free or cheap and any other tools that may
>help with solving TPU issues ?

The original TPU book has a section with some details on the debug hardware
built into the TPU.  There's a copy on the web--google for "TPU microcode
reference" ought to do it.

There's a free dos based TPU debugger (TPUBUG) from Moto out as well, but
I've yet to fire it up.  The readme file for it looks promising.

http://e-www.motorola.com/collateral/TPUBUGDBG.zip <http://e-www.motorola.com/collateral/TPUBUGDBG.zip> 

Charles Melear offered to send TPU info to anyone with a mailing address
not 5 days ago on this very list--you should take him up on it.  Good stuff
in a box.


newell



Yahoo! Groups Sponsor	

ADVERTISEMENT
 <http://rd.yahoo.com/M=240188.2647639.4038785.2225243/D=egroupweb/S=1706554205:HM/A=1321406/R=0/*http://www.e-dealsdaily.com/soundbug/> 	
  <http://us.adserver.yahoo.com/l?M=240188.2647639.4038785.2225243/D=egroupmail/S=:HM/A=1321406/rand=794359453> 	

---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> 



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . 




[Non-text portions of this message have been removed]

At 07:42 AM 11/19/2002 -0700, Melear Charles-rdph40 wrote:
>All you need to do is tie the TSTME/TSC pin low and the software does 
>the rest.  If you can't find the documentation, send me a note and I 
>will get it for you.

You already have--the docs arrived yesterday!


newell

Can anybody find anything wrong with the following.

Having read & re read the motorola literature & the
TPU microcode for the PMA function I now have some
doubt about certain parameters.

I am running the PMA function on channel 1, my sensor
wheel has 12 teeth with 1 additional tooth.

Initially I set Num_Of_Teeth to 11 and set
TCR2_Max_Value to 24.

TCR2 counts from 0 to 11 and the first additional
tooth causes an interupt.  The TPU subtracts the
Num_Of_Teeth
from TCR2_Value and this should be 0, if not an error
will occur.  In my interupt routine I change 
Num_Of_Teeth from 11 to 23.  TCR2 now continues to
count from 12 to 23 before the next additional tooth
occurs.

TCR2 will be reset because bank signal will be a non
zero value, again The TPU subtracts the Num_Of_Teeth 
from TCR2_Value and this should be 0, if not an error
will occur & my interupt routine changes Num_Of_Teeth
from 23 to 11.
I am assuming from my documentation that the
additional tooth does not change TCR2 but does it ?

From the literature TCR2_Max_Value is a number used to
detect conditions where the TPU has missed the
additional tooth, and therefore holds the max number
that TCR2 should count to, in my case 24. From the
motorola literature TCR2 does not count the
additional teeth but can anybody confirm this.

What I am getting is an ERROR of $80, and TCR2 exceeds
TCR2_Max_Value but continues counting.  I have changed
TCR2_Max_Value and got an ERROR of $C0.

Can anybody offer any ideas or advice as myself and
three other engineers are stumped after having spent
over thirty hours brainstorming the TPU and getting no
where fast.


                 all the best Roy





__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus \ufffd Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com