This week the Philips Pronto team agreed to allow me to publish information on an advanced Pronto Script debugging methodology. Lyndel and I have both been using it for some time but were under NDA and could not discuss it. It was never planned for general release but we made the case that it could only have a positive outcome, and the Pronto Team finally agreed. We both found it by accident, as there is no published info regarding the capability. With an inquisitive mind, a desire to tinker, and a background in electronics; anyone could discover what we came upon just as we did; by accident.

With a simple mod (mount a stereo phone jack and solder three wires) to the docking base and the purchase of a special cable (cheapest way) you can have all of the System.print messages directed to a PC program. No more squinting at the screen and watching information disappear out of the window.

I have posted on my website (www.the-gordons.net) a package called Pronto Pro Tools. If you can not find it there perhaps you should not be ....

It has three sub packages the first two of which I use all the time:

1) The debugging system with full documentation on how to mod the base, where to get the cable. All the software you will need is included. The whole thing should take about 10-20 minutes of time for the mod, and $25 or so for the cable. The PC program (and cable driver) are certified for XP but should work on Vista.

2) The Scripting tool with full documentation. It is a PC program that provides a graphic interface to an xcf file (9400 or 9600) and allows you to develop and maintain Pronto Script code using a code editor of your choice. The one I use is mentioned in the manual provided and costs about $50. Believe me it is worth it! Full screen, full color, complete syntax checking, pretty printing and the list goes on. You could just use Notepad...

3) A TCPIP test/demo program for the 9600 with a companion PC program. The 9600 program is about as simple as I could make it, one activity, one page, about 60 lines of code including comments. Not a production environment, but a simple learning tool.

The question what does "System.setDebugMask(9)" do? can now be answered. It is the command to direct the System.print text stream to the built in serial output port that was never externalized (brought out of the docking station). The mod takes care of that and the PC programming gives you a nice display with handy features.

Feedback appreciated. I do ask that if you download a copy of the package you let me know so I can add you to a mailing list for change notices and upgrades.

There is a lot of difference between a program usable by its author and one usable by anyone. IBM once estimated the cost difference between the two in the range of an order of magnitude (X10). Let me know of any issues and I will attend to them.

Now I can get back to SlimServer.

As Barry mentions, debugging with _PS_DEBUG_ panels is not very productive. It can be done, but once you start developing complex scripts, Having the ability to have a PC program running that can display the information makes development of complex scripts MUCH easier.

Now that we can fully discuss the System.setDebugMask() function, to reiterate a previous post.

Current known allowed values:
0 - Off - No output
4 - Trace-Level output by line #
9 - Forward All System.print() calls to external high-speed serial output.

Not sure if this is indeed really a "Mask" as 9 is actuall 8 or'ed with 1.

System.setDebugMask(1) appears to have no noticeable affect.

Also note that this does indeed require you to modify your Docking Station. If you are uncomfortable with this, I'm willing to do this for a nominal charge. Send me RC Mail if interested.

The TSU9400 may support this capability but as there's no USB-passthrough on the dock, one would need to add a jack to the back of the remote itself. This is something that I do NOT recommend for the casual user.

Lyndel,
Referring to your last line above, does this mean this mod will not work on the 9400 base? If I wanted this capability, I would need to bring the serial port out of the remote itself?

You got it. There's no USB pass-thru on the 9400 base. USB only connects to the remote.

On the 9600, there is a 14 or 15 pin connector between the dock and remote. It is over this connector that the signal for the 2nd High-Speed-Serial connection is passed. Since the 9400 does not have such a connector, the only hope of achieving the same functionality is solely dependent on whether the same 3 PCB traces are available in the remote. (I don't know if they are even available).

Just took my 3 week old 9400 apart to find the tracks:) - couldn't resist it now. The CPU is a freescale MC9328MX21. More info on the chip here [Link: freescale.com].
Its an ARM 9 achitecture. The good thing is that there is a JTAG interface for debugging.
Now just to get them out.
If you remove the label at the rear of the unit, there are two embedded pins. Me guess is that they are the TDO and TCK line from the chip, but seeing that this is a BGA chip it's going to take a little longer to trace back to the chip:( I also suspect that one of the charge pins is multiplexed with the JTAG TTRST line.

THe connector between the PCB and the charge pins is actually made up of nine strands. 3 to +, 3 to ground, one charge control and the two others to the embedded pins. I suspect that the charge control is muxed with one of the JTAG pins.

I will try and do a little more at our workshops tomorrow.

Hello,

Can you guys please confirm if the pins on the TSU9600 base are the
TTL - RX,TX Gnd.
If so I guess that I can use my RS232(max232)-ttl interface would do the job.
Cheers
Sorin

Yes and No. they are at 3.3 volts not 5 volts. I believe TTL is generally understood to mean 5 volts and CMOS is used to designate operation at 3.3 volts. Buy the cable.

Is there a way to redirect output from _PS_DEBUG_ to TCP ?
The easiest way to debug with a PC would be to run a listener on a PC and watch
the debug there with a program like syslog.

Hey, what a clever idea!
For the pronto error messages a redirect is necessary, but not for my own messages.
I already use my own function to be able to use the small screen on the 9400 like this:

function outputDebug(s) {
var lines = splitLine(s, 40);
for (var i=0; i}

I just have to change this function to send the messages using TCP instead of using System.print (and then the line splitting isn't needed anymore :-) ).

The easiest way to debug on a pc is have philips provide the capability over the existing USB connection. That has been suggested to them. I even volunteered to write the support package.

The problem with the TCP thought is error messages. They occur asynchronously and not where you will place the TCPIP write statements. Of course you can write all sorts of debug aids using tcpip, but why bother. Mod the base. buy the cable use System.print and be done with it.

A Pronto PRO costs about $800 US last time I checked. the cable with shipping is about $30 or less than the US sales Tax in most states on the unit.

Well, as Lyndell confirmed this mod does not work on the 9400 base (and I only own a 9400).
And to spend $800 + $30 just to buy the 9600 as a Prontoscript debugger... don't think so!

Barry,

your're right, I hope philips offers debugging over usb (or a real emulator) someday. I don't know how difficult to program this might be.

My suggestion to redirect the output from _PS_DEBUG_ to a _PS_DEBUG_TCP_
should be simple for them, because all necessary functions are in the firmware already.

Modding the base (9400) is not an option for me.

Frank

For those of you with a 9400, you MUST have not read too closely above...

There's a post here stating that leads me to believe the 9400 will support the same capability, but not through the DS.

[Link: remotecentral.com]

I wonder about the unused System.setDebugMask() settings...

If that capability existed (a system debug mask setting to direct output to the USB port) then I am sure Philips would release it since the information about debugmask=9 and modding the 9600 DS is out. Why would they not?