All posts by admin

8OD.1 Board: Mea Culpa

(8OD – Main article)

Recently I started looking into the next phase of development I wanted to do on 8OD, specifically, to make a bus available on the 36-pin header and start attaching peripherals to it.

As I looked back through the design, something jumped out at me…

U9

U9 is a not-entirely-necessary, but nice to have bit of logic which performs bus steering, to make the addressing of 8-bit peripherals easier. It is effectively a bus transceiver, although not quite performing the same role as an actual bus transceiver.

 

U1

Yet…

The signals made available on the 8086 for the control of bus transceivers, are N.C. Well well…

Diving back in the the CPLD’s VHDL code, I can see that I’ve derived the control signals for U9 from the 8086’s bus control signals, not the dedicated transceiver control signals. This of course is less than ideal, but is it actually a problem? Let’s get those timing diagrams out and have a look.

First stop, the 8086 read timings. Straight away, it doesn’t look good. Because the #OE’s of the transceiver are asserted for the period of the #CS signals of the two peripherals behind it, the de-assertion of #RD will reverse the direction of the transceiver while it is still driving the bus.

Therefore the above diagram shows that this inappropriate use of RD# causes a potential bus clash between peripherals and the transceiver (U9), whereas DT/#R (Not used by my design) is well clear of any such eventualities. How the heck did I miss that?

But as previously stated, this only highlights a potential clash. Because the peripheral is assumed to be driving the bus during this period, we have to examine it to determine if there is an actual clash. Let’s take a look at the SC16C554 datasheet:

timing3

That’s not good, it’s now very likely that there is a clash. In terms of the UART (U10), this is clearly represented and quantifiable by the symbol ‘t12h’.

timing4

Which is 15 nanoseconds per bus cycle.

The only remaining hope lies within the propagation times of U9 (SN74LVC16T245). I’ve got a pretty good feeling there isn’t going to be any good news there either.

timing5

And there it is. U9 can change direction significantly faster than U10 can release the bus. There’s officially a major problem with my design.

I’m a little miffed about this. I really thought the 8OD.1 board was free of mistakes, certainly, it didn’t show any problems during my testing. In some respects, what I’ve just found is the worst kind of problem, as it is likely to be missed during design verification, and will lead to premature failure, after the product has been shipped.

It’s just as well I didn’t mass produce these things.

So what next?

8od.1modWire mods.

And a couple of pull-up resistors. This time I checked the need for these carefully, as I was keen not to get my backside kicked by yet another quirky detail, specifically that control signals tend to float during certain periods, i.e. Hold Acknowledge, Reset.

timing7And there they are on the original SDK-86 schematic, circa 1978.

I’ve now got DT/#R connected to the DIR signals on U9, and #DEN to the CPLD to control the #OE signals for U9. This is fairly faithful to the original guidelines, and will make these boards reliable in the long term.

So now I’ve got to revise the board. I guess this isn’t such a bad thing, as there’s already a list of things I want to improve with the current design.

Moral of the story

8OD’s 8-bit bus spur was a design annoyance, which I didn’t put as much thought into as I should have. As is always the case when designing complex electronics: If you haven’t thought of absolutely everything, there will always be a major problem hiding in the overlooked details.

ROVATool 2.0 released

(ROVATools – Main article)

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.

Read more here

ALTERA USB Blaster II Clones

(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.

Read more here

Other changes

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.

Download

ROVATools v1.2 released

After several emails received from users – I’ve released a new minor version of ROVATools

There are two changes which are applicable to RTD266x platforms only.

  • Added support for Pm25LD010 flash chip
  • Fixed issue where RTD266x platforms cannot correctly program .BIN files which aren’t padded to 256 bytes

It can be downloaded here.

Mystery character problem solved

(Continuation of this post)

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.

Capture of the write to const section in RAM
Capture of the write to const section in RAM

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.

Back to the Logic Analyser

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.

strangechar

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.

8OD.1 logic analyser connections
8OD.1 logic analyser connections

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.

8086 based 8OD.1 attached to 16700 logic analyser
One of the 8OD.1’s would inevitably find its self back on this spot

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.

Acquisition of an Agilent 16702B

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.

HP 16700/Agilent 16702B
Agilent 16702B in action

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.

scaadapter

And here it is back in the LA

scaadapter_installed

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:

# loadfile dd
# dd if=/dev/dsk/c0t5d0 of=/dev/dsk/c0t6d0 bs=1048576

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:

HP/Agilent 5063-9262 128MB
RARE: HP/Agilent 5063-9262 128MB memory upgrade

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.

HP/Agilent 5063-9262 128MB
5063-9262 Underside

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.

HP/Agilent 16600-66518 Video memory upgrade
UNOBTAINABLE: HP/Agilent 16600-66518 Video memory upgrade

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.

HP/Agilent 16600-66518 Video memory upgrade
16600-66518 Underside

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:

hpux -is

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:

logic:/home/hplogic> export DISPLAY=192.168.0.31:0.0
logic:/home/hplogic> vp &
Agilent 16702B running with remote X11 on MobaXTerm
16702B running with remote X11 on MobaXTerm

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.

Auto power on after AC loss mechanism for PC mainboards

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.

pic12c508a pic12c509a
ANCIENT HISTORY: A PIC12C508A purchased in error

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:

  1. It requires specialist kit to download code onto it, i.e the £1000+ MPLAB PM3, or a high voltage benchtop EPROM programmer
  2. 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
  3. 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:

  1. +5v Standby voltage powers up PIC
  2. PIC waits 3 seconds
  3. PIC tests if machine is on (by sampling +5V main supply)
  4. If powered on, go to step 7
  5. If not, PIC presses power button for 500ms
  6. Go to step 2
  7. Do nothing until powered off and on again

The device would only need 4 connections:

PC Power on device
The schematic
  1. 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.
  2. The main +5V. This is found just about anywhere, and is used only to test if the PC is on.
  3. 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.
  4. 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.

PIC Based pc power on device
The device built on prototype board

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.

use12f675 equ 0

if use12f675 == 1

#include "p12f675.inc"
processor 12f675
list f=inhx8m
__config (_INTRC_OSC_NOCLKOUT & _MCLRE_ON & _WDT_OFF & _CP_OFF & _CPD_OFF & _BODEN_OFF)

delay_ms_arg equ 0x20
delay_s_arg equ 0x21
add_arg equ 0x22

else

#include "p12c508a.inc"

processor 12c508a
list f=inhx8m
__config (_IntRC_OSC & _MCLRE_ON & _WDT_OFF & _CP_OFF)

delay_ms_arg equ 0x07
delay_s_arg equ 0x08
add_arg equ 0x09

endif

; Start of code

org 0x00 ; reset vector
goto main

delay_ms
movf delay_ms_arg, f
btfss STATUS, Z
goto outer_loop
retlw 0
outer_loop
movlw 0xF9
movf add_arg, w
inner_loop
movlw 0xFF
addwf add_arg, f
btfss STATUS, Z
goto inner_loop
nop
decfsz delay_ms_arg, F
goto outer_loop
retlw 0

delay_s
movlw 0xFA
movwf delay_ms_arg
call delay_ms
movlw 0xFA
movwf delay_ms_arg
call delay_ms
movlw 0xFA
movwf delay_ms_arg
call delay_ms
movlw 0xFA
movwf delay_ms_arg
call delay_ms
decfsz delay_s_arg, f
goto delay_s
retlw 0

main
movlw 0x00
movwf GPIO

movlw 0x3D
if use12f675 == 1

; 12F675
bsf STATUS, RP0 ; select register bank 1

movwf TRISIO

movlw 0x00 ; All A/D off
movwf ANSEL

bcf STATUS, RP0 ; select register bank 0

movlw 0x07 ; Comparators disconnected
movwf CMCON
else

; 12C508A
tris GPIO
endif

main_loop ; Power button pressing loop

movlw 0x03 ; 3 Seconds per pass
movwf delay_s_arg
call delay_s

btfsc GPIO, 0 ; System now on? Exit if so
goto infinite_loop

bsf GPIO, 1 ; Assert power button

movlw 0xFA ; 250ms delay
movwf delay_ms_arg
call delay_ms

movlw 0xFA ; 250ms delay
movwf delay_ms_arg
call delay_ms

bcf GPIO, 1 ; De assert power button

goto main_loop

infinite_loop ; Done till next power on
goto infinite_loop

end