With the ROVA USB-TOOLS programmer expensive and sold by few vendors, in 2013 I added support for Parallel port programming,
but with PCs equipped with Parallel ports increasingly rare, but this hasn’t been enough.
Recently I was contacted by a knowledgeable, well equipped reader by the name of Rajko Stojadinovic – who has added a frequently requested feature to ROVATool:Even more programming hardware options.
FTDI Based boards
This is a new option, which utilises inexpensive FTDI based boards for programming Realtek devices.
(Or pretty much anything else with a Cypress EZUSB-FX2 on it) This option isn’t entirely new, but details how it’s possible to convert one of these inexpensive dongles into a ROVA USB-TOOLS programmer.
There aren’t any! Other than that I’ve split out ROVATool into its own download, as most of the users of this suite use the tool for RTD2660 platforms, there is little point in bundling the ROVAEdit tool with it, which is not applicable.
After about an hour of sending thousands of web requests, bingo, the mystery character appeared, and the logic analyser breakpoint I set had triggered. I was pleased to see a clean and clear write of 0xFF to 0x20481 – the exact value to the location I suspected was being trashed.
After scrolling through reams of bus transactions and correlating it to a dissassembly, which I used Watcom’s ‘wdis’ tool to create, the problem was becoming apparent.
Although there was only one problem that caused the original fault, I spotted another while I was at it:
1 – I’d forgotten to push the AX register to the stack in the ISR. A bit of a bummer for any interrupted code that was using it.
2 – The second problem had me feeling like I’d failed computer science 101. I’m using the W5100’s interrupt so the application doesn’t have to waste time polling the SPI for stuff to do. Generally speaking the interrupt handler adhered to good practise – Doing no real work, just flagging stuff for the main routine to do.
The oops? I was still reading from the SPI in the ISR, and the main routine code was too, so one thread of w1500_read() would be interrupted by another copy of w5100_read(), stuffing the whole thing up, because the SPI controller and the W5100 are a shared resource, and I wasn’t disabling interrupts for the execution of the non interrupt context version.
In the end I moved the W5100 flags ‘read’ out of the ISR, and into the main loop, instead just flagging the interrupt pin in the ISR, which is safe.
Did I really need a logic analyser for this? Not really, but heck, once I had a capture, it helped me find both problems in minutes.
Recently I started on getting the Arduino Ethernet shield working with 8OD. Aside from the pull up resistor problem which was found and fixed fairly easily, another much more ominous issue cropped up while I was making a little web demo app.
Crap. After a few hundred web requests – it appears. Straight away I can see that the source of this text, which is in a “const” section in RAM is being modified. There’s nothing in the code that I can see which would be modifying this area. This is not good.
Either it’s memory corruption caused by code bug, or a hardware fault. I have been able to rule out fault with a specific unit, because it reproduces easily on a second board. Beyond that, I’m stumped. It’s now time to break out with the logic analyser, and put a breakpoint on that memory location, and hopefully see what’s changing it.
Before I can even do that, I’ve got to prepare an 8OD.1 unit for logic analysis, which is a bit of a job.
Many of the connections needed for logic analysis are on the EPROM socket, but there’s still quite a lot that aren’t. The rest are exposed as test pads which I then have to solder wires and headers to. This is a little bit of a pain but with the PCB only being 2 layer, adding footprints for test connectors (I.e. Mictor test probes) is out of the question.
With 4 pods on a 16752A in use, this is about the minimum I can get away with to do a meaningful analysis on 8OD.
The ethernet shield was always on my list of things run with 8OD, but sat in the “too hard” basket, mostly because I was afraid of a difficult software task, which in the end would turn out to be rather simple.
It was only a matter of time before I was going to own one of these. Having used the 16700A on the job more than 10 years ago, it was one piece of kit I never forgot the enjoyment of using.
It also was inevitable that it’d be an 1670X that I’d go for, not for cost reasons, but to some extent. The affordable 16900’s are clapped out old Pentium III based units that won’t go to anything newer than the ancient Windows XP. This HP-UX based unit on the other hand, is timeless.
One of the first jobs: Replace that flaky, slow old SCSI hard disk with something a bit more modern. As no one has demonstrated any kind of practical (and cost effective) SSD solution for these units yet, I’m not keen to go splashing out on an expensive SCSI to SATA adapter which’ll be unlikely to work. The best hard disk option for repairers appears to be using SCA Ultra320 hard disks from old servers. They’re inexpensive, good performing, large and plentiful.
But first there is an annoying problem: Mine being one with the built in CD-ROM, the hard disk is mounted the opposite way to CD-ROM less units, and the offset of the connector with adapter on the incumbent disk arrangement makes it almost impossible to fit the SCA disk with adapter without slashing up the metalwork, or rebuilding the large SCSI ribbon cable, so I’ve had to make up this little “offsetter” cable to deal with it easily.
And here it is back in the LA
During the re-install I found that the installer just couldn’t seem to cope with the 146GB drive I had installed. I don’t think it’s completely impossible but the LVM configurator is hard coded to always use the whole drive, then complain that it’s too large for the bootloader to boot from. In the end I copped out and installed it on another 9.1GB disk and DD’d it over to my new drive. The bootloader doesn’t mind massive drives, just so long as the root VG doesn’t span its entirety.
I’m not sure where the line between ‘works’ and ‘doesn’t work’ is in terms of disk size, but can confirm that a 73GB drive works, whereas 146GB doesn’t. Maybe 128GB is the maximum?
To transfer the smaller partition set onto the large drive was easy. I simply attached both drives to the analyser at once, boot into the recovery shell from the install CD-ROM and run these commands:
That took about 5 hours. Note here that SCSI ID 5 is the old 9.1 GB disk I just installed the OS on, and ID 6 is the newer 146GB drive. This had the disadvantage that I’ve wasted most of the drive, but it’s not like it’s ever going to be needed, and only using less than 10% of the drive has considerable performance advantages as the heads barely ever have to move a millimeter to boot the LA.
The upgrade was definitely worth it. With the old drive radiating enough heat to cook a steak, and producing the sound of a hundred maracas in a washing machine, this new drive is cool quiet and a lot faster. It’s now more responsive, and also boots about 15 seconds faster than before. It’s just a shame the rest of it makes a noise level somewhere between a hovercraft and a jet engine.
While I had the unit open – I took the opportunity to photograph two rather sought after but difficult to obtain items:
This is one tremendously exotic bit of RAM. It is similar to the memory found in old HP-UX workstations which had between one and four 64MB memory modules, but this particular one is a completely logic analyser specific pair of 64MB modules on a single 128MB PCB, despite the system reporting it as two 64MB upgrades.
Sadly these memory upgrades are only feasibly obtainable with a unit that was sold with them. Keysight apparently have some stock of the above upgrade, but with shipping and administrative charge, it’s cheaper to just buy a used Option 003 analyser, pinch its ram and throw it away.
Even more difficult to come by is the video memory upgrade, which increases maximum resolution from 1280×1024 to 1600×1200. So far as I can tell this upgrade is effectively useless as it will only output 1600×1200 @ 75Hz which no LCD monitor will accept, as 60Hz is the maximum refresh rate for all LCD panels, unless the monitor happens to have some kind of intermediate buffering mechanism which I am unaware of any examples of.
Interestingly though there is a “user defined” display mode which I hoped would allow entry of a modeline or EDID but thus far I have not found any interface to configure it.
The best way to use this Analyser appears to be the same way that I did on the job all those years ago: Remote X11
I was a little disappointed to find that after logging via Telnet using the “logic 192.168.0.x:0.0” format, that nothing happened? I don’t remember remote X11 being a difficult thing to use on these units. After trying all sorts of X servers, nothing worked at all!
In the end, I followed this guide, got a shell on it, reset the password for the secret “hplogicz” user.
(Quoted from http://www.perdrix.co.uk/)
As the system is booting, use the Esc key to interrupt the boot process, then issue the command BO PRI ISL. When it asks you if you wish to interact with the boot process, respond with a “y” and press enter, then at the ISL> prompt, issue the command:
to get into single user mode.
Once you have a command prompt, you can use passwd root to change the root password.
In my case I wasn’t interested so much in resetting the root users password (but what the hey, why not) – but instead the hplogicz user which is already in place for this kind of use.
# passwd hplogicz
– and then reboot the LA, logged in via telnet with this account and started the logic analyser application manually with the following commands:
So it appears that on mine, the program that normally is supposed to start the remote session (/usr/sprockets/bin/sessionWrapper) wasn’t working, but can be manually fudged around by starting vp the old fashioned way.
As many have said, when embarking on a project, it’s always the smallest details that kick your arse, and today, I’ve hit one of those.
A while back, still mourning the loss of the Intel Desktop Board line, I purchased a Jetway NF9E-Q77 as the Intel DQ77KB had become unobtainable, but this Jetway board, despite being sold as an industrial board, seems to be missing one of the most obvious features you’d expect from an industrial board: Auto power on. I’m rather baffled by this, further by the assertion of use for digital signage, if one of these ends up driving a large display high above the ground, does someone have to reach up to it with a long pole to press the power button every morning?
My first attempt at resolving this was to connect the +PWR_ON (power button) to the boards +5V supply (via a 4.7K resistor), this works good, because when the board is off, +5V is 0v, which is the same as pressing the power button, which just connects +PWR_ON to GND. As luck would have it, it powers on during the falling edge so it works a treat. Problem is – I couldn’t turn the darn thing off, because after shut down it goes right ahead and turns its self back on again, as you’d expect. Not exactly the behaviour I wanted.
Second bodge: This seems to be a common trick, attaching some kind of capacitor across the power switch. This works too. Most of the time…
Given that I want to be able to shut this machine down, and require that it always turns back on when AC power is connected, to heck with it, I’m going to have to use some kind of Microcontroller.
A while back I bought this little relic from a high street electronics retailer (Maplin). I went in there to buy the modern (and common) 12F675, but came out with a 12C508. Was it that they were out of 12F675’s, or perhaps they gave me the wrong part? I don’t know for sure, but I doubt it. Most likely is that my mind was harping back to the bygone era of EPROM PICs, and I really did ask for it.
I find it interesting that high street retailer sells something like this, because this line of PICs is really quite difficult to work with, and is the last thing that the average walk-in-off-the-street hobbyist would ever want to tangle with:
It requires specialist kit to download code onto it, i.e the £1000+ MPLAB PM3, or a high voltage benchtop EPROM programmer
It’s OTP (One Time Programmable) so unless you’ve got a whole tube of them (who does right?) there’s only one chance to get the code right
It uses Microchips’ most basic 12-bit instruction set, for which, C compilers don’t support, so it’s got to be programmed with the dreaded PIC12 ASM language
So what am I going to do here? Cop out and use a 12F675, or conquer one of these once again. Not having written any ASM for many years, I can already see what should be a 1 hour task turning into a 6 hour curiosity project.
In order to make absolutely certain that the machine is turned on in all cases, I decided to make it work like this:
+5v Standby voltage powers up PIC
PIC waits 3 seconds
PIC tests if machine is on (by sampling +5V main supply)
If powered on, go to step 7
If not, PIC presses power button for 500ms
Go to step 2
Do nothing until powered off and on again
The device would only need 4 connections:
The +5V standby voltage, which pin 9 on an ATX power supply cable, failing that, most mainboards will have it available on at least one connector, in my case I found it on the CIR header.
The main +5V. This is found just about anywhere, and is used only to test if the PC is on.
The power on button active signal. This is either pin 8 or 6 on the front panel header, One of those two is connected to ground, ignore that one and connect the other to this device. It’s no problem to leave the physical power button connected, this device will not interfere with its operation.
Ground. Take your pick where to connect this.
If using an Intel Desktop Board, or one that is designed to be compatible, the Custom Solutions Header has all four of these connections.
And here’s the source code (download project). Understanding that few would be equipped and comfortable attempting this on an OTP PIC, It also works on PIC12F675 when use12f675 is set to 1.