Journal (29 Nov -> 15 Feb)

Cutting up a GBA link cable so I can measure the voltages of the GBA and connect it to a circuit board.

Pin out of the GBA connector plug (cable protuding into page).

     _ 
/---| |---\
| 1  2  3 |
| 4  5  6 |
\---------/

Setting all outputs high had the resulting voltages:

Talked to Rod about an interface for the SO28 (Small Outline, 28 pin) PDIUSBD12 chip..

Rushed to a lecture before being able to probe anymore

Got my multimeter back, complete with new battery.

Tried to prove the GBA pins some more, but they all appear high no matter what, except for one.

Perhaps I have my byte order backwards? If I did then my last test would not have been in general-purpose mode (01 must be the last digits).. All outpus except white are high… perhaps white is the ground and the other is simply sheilding?

Changing combinations did not alter the readings, which leads me to believe that one of two things is happening:

1. I am not reading the values correctly, probably because I have not found the correct 'common/ground'
2. (More likely): My crude binary creation code is failing miserably at producing a byte. I need to learn about bit shifting and bit-masking before I'm able to do anthing useful.

After getting some help with C and bitregisters / printf we got output and intput working. Really must learn C. Results of findings:

Note: Shorted out when connected to the p1 (thin) plug of a link cable, but not on a p2 (fat) end.

Annoyingly it seems I made my cut at the wrong end of my cable and have lost the use of SI pin on the cable. I'll probably buy another cable and slice that up. I've only got about 15cm left of the old one, and a lot of that is taken up by the electrical insulation / surge-protection bubble thing.

PDIUSBD12 arrived in a small-outline package, and was soldered onto a (DCS lab) standard dual-line adaptor (to make it much fit patch boards easily) by one of the technicians (Mr Rod Moore) because the 'pitch' (pin thickness & density) of the device was uncomfortably small for personal efforts.

PDIUSBD12 arrived in a small-outline package, and was soldered onto a (DCS lab) standard dual-line adaptor (to make it much fit patch boards easily) by one of the technicians (Mr Rod Moore) because the 'pitch' (pin thickness & density) of the device was uncomfortably small for personal efforts.

Went into the project laboratory hoping to find a PICprogrammer and programming IDE for my laptop and try for compatability, but it was not expected to arrive until tomorrow.

Noted that my laptop needed a serial port in order to use one of the deperatment programmers.

Asked for a network port in the lab to be enabled for laptop use, to facilitate the viewing of online reference materials, source code, example application diagrams and community (forum) help.

Spent half an hour or so familiarising myself with the PDIUSBD12's datasheet, and looking through PIC datasheets to get an idea.

Aquired part of a USB cable, kindly donated by the technicians from one of their terminated projects. Cable looked a little suspicious, the plug seemed a little to big and had unusual funnel-out / flaps at the end. Seems it's an older cable.

Spent an hour getting familiar with the soldering equipment and such while trying to tip the ends of the GBA / USB wiring to make it fit in the patchboard conveniently. Both cables use twisted strands of wire, and not a solid core, and as such are very hard to patch into my board. Due to a certain lack of practice in soldering progress was especially slow.

Bought a (fairly cheap) USB → Serial port adaptor in town.

Realised that the suspicious USB cable aquired yesterday was in fact a USB-A female socket, and not a male plug at all. This was not obvious due to the design of USB-A plugs (looking end on it is effectivly a rectangle which is half full of a small board with tracks on it, the female is too, only the outer shell surrounding the board is that little bit larger).

Aquired the other end of the USB-A cable from the kind technicians. It was in fact soldered to another USB-A plug so effectivly I had two USB-A cables now, which was nice.

Decided that tipping the ends of the wires was not a satisfactory approach to the problem of connecting them to the patch board and sought the advice of the technicians.

Barry suggested attaching small lengths of solid-core cable to the end of each wire, thereby providing the means to patch the cables in and out of my patch board. This seemed a much better approach and I did so to one of the USB cables.

A meeting with Roger englightened me to use a 'component header', instead of attaching solid-core cables to the end of the wires.

Spend considerably less time soldering both the short end of the GBA cable (as the long length of cable I had has two pins moulded together!), and the other USB-A cable. This went quite well with a minimum need for resoldering, and tested OK with check with end-to-end connectivity with a multi-meter.

—

The department had recieved the software they were waiting on yesterday, and provided me with a thorough collection of software, software add-ons, manuals and help files on a couple of CDs. There was a small delay installing the MicroChip IDE on account of it requring Internet Explorer to be the default webbrowser, and not accepting Mozilla Firefox.

Among the manuals were some very large PDF versions of the PIC16F8x and PIC16F87x chips, which would take many hours to download from a 56k connection. I was offered printed versions of the documents but declined on account of the extra space and weight this would require when travelling, coupled with a personal preferance for searchable electronic documents.

The USB → Serial port adaptor I bought (thankfully) worked flawlessly with the PICprogrammer I was provided with and after some very minor setup problems we had the PICprogrammer talking to the IDE and vice versa.

Barry ran me through the steps needed to create, populate, compile and program-to-pic an assembly project and then a CCS project.

During the CCS project example we encountered an error which is seemingly not explained anywhere in their packaged help. Something about PWRT and BOD settings being in conflict. We managed to lockate the cause of the error in the PIC-settings dialogue where Brown-Out Detection was enabled, disabling this seemed to fix it. I personally amd not sure what PWRT is or indeed if it was in the same list and Brown-Out Detect.

Before calling it a day I was offered some invaluable advice, the CCS compiler has bugs in it - and I have been given the latest version, which the department are not yet familiar with. So if something completely confounds me I ought to consider the very real possibility that it's a bug in the compiler. The case cited to me was in regards to writing to the program-memory space (due to all ROM/RAM being used up) - functions exist to do this task, but they do indeed have bugs and this was only solved by programming the routine manually in assembly!

—

I aquired some solid-core cabling of assorted colours as well as some components (an LED and a few small capacitors for decoupling connections) for use over the Christmas break.

While transporting the patch board home it split into two seperate sections - the PIC daughter board, and the patching surface it's self. Luckily there was/is no electronic connection between the two and this 'break' only affects the convenience of having the two permenantly together. I do not intend to reglue the PIC daughter board to the patchboard as this is very likely to happen again due to the raised PIC mounting socket:

 __
|  |
 || 
 ||
 ||  |
=======  [^^^^^^^^^^^^^^^^^^^^^^^^^]
=====================================

|-----|  |--------------------------|
  PIC            Patch surface

The PICSTART Plus programmer only worked the first time I tried to use it after arriving in Cyprus.

It enabled fine, reset fine, and was queried it's firmware version fine, but it failed to read the PIC16F84A which was in it without timing out too many times. Changing the serial port settings and trying this a couple more times resulted in errors along the lines of 'The programmer firmware must be 2.10.3 or newer to work'. This was quickly replaced with 'Unsupported Programmer detected: 80' on successive attempts.

It has now settled down to this message, with varying numbers at the end, but so far always 80 or 8F.

This is going to seriously hamper any progress I was hoping to make. Looks like it's going to be purely academic work this Christmas break, with maybe some GBA programming mixed in.

Decided to try my hand at getting the GBA to suspend. Turns out this is done via a direct BIOS instruction (called SWI 3) which is written in assembly ( as SWI 3, interestingly ). In order to bring the GBA back to life I needed to learn to handle key-generated interrupts, and in doing so also experimented a little with the cartridge interrupt (indicating the removal / re-entry of a cart into the GBA). This cart interrupt had an interesting problem - because the code I wrote was running from the bootstrap, and not the cart, inserting a cartridge would force the GBA to reset. This was even the case when I loaded the code through multiboot while there was a cart in the GBA (achieved by holding down START + SELECT while the Nintendo logo displays itself at start-up). The keyboard interrupt required setting a register for the keys, a register for the interrupt, and a few flags to enable them.

A working example is in the Suspend_Test (vHAM) project. (see Game Boy Advance)

Due to problems with Stephan's GBA cart, I developed a small multiboot program to backup / restore the SRAM, using the DebugLib which was provided with the MBv2 cable. I started by trying out the example code from the libary which did exactly this, but it proved quite troublesome as writing seemed to produce random data changes, and reading was seemingly unreliable (although, much more reliable from writing).

Looking into the specification in GBATek I learned that I needed to set a writestate of 8 (CPU cycles) in order to use SRAM reliably. I found how to set this and did indeed achieve reliable reading / writing.

I added the facility to verify the code, as well as restart the program once it completed (allowing multiple runs of the same thing to be done, for testing purposes).

I then tried to add a progress indicator to the code, but the simple approach of updating the display every iteration of the loop slowed the program down by a factor of 5 (at least!). I tried to apply my knowledge of interrupts to the problem and hence get the screen to update about every second, instead of every interation. I did get this to work and without the slow down associated with the every-iteration approach; however doing so has made the program less stable and it randomly hangs now. I added 'disable interrupts' and 're-enable interrupts' statements to my interrupt handler function, and while this helped somewhat, it has not erradicated the problem.

After quite a bit of fillding I have run out of idea as to why this happens, and have simply opted not to have progress indicators - gaps in feedback arn't typically longer than 30 seconds anyways.

A working examplke is in the 'SRAM restore' project. Despite this name is can also backup and verify. (see Game Boy Advance)

The issue of the exact chips being used in the GBA was raised, as the ARM7TDMI is a core, and not a chip. This means it is unclear what the 'waitstates' are and how they work. During a discussion it was thought that waitstates (being measured in CPU cycles) implied that the CPU did not wait for the response from external memory, and this could cause considerable problems; and that this might affect the communications port. Moreover it is likely that an architecture as sophisticated as the ARM series may be able to be fabricated to know about different I/O types at different memory addresses - which raised the question of whether this was programmed or hard-coded into the design, as GBA cartridges can use different types of memory for their save games (EEPROM, SRAM and Flash).

This will need looking into. — The next step is to try and get the PDIUSBD12 to ennumerate with a PC, and this requires being able to read raw data from the USB port. A USB keyboard (courtesy of the dept.) will be used while setting up USB RAW data capabilities on the PC, as this ought to prove easy enough to check the data at either end. Once this is done the fun of making the PDIUSBD12 circuit presents itself, followed by the task of enumeration of any sort at all.

Attempts at low-level USB debugging have thus far been unsuccessful trying a keyboard and mouse. The USB Command Verifier tool from USB.org seems to successfullly swap out the MS USB Stack on my WinXP Pro SP2 laptop, as the external keyboard and mouse cease responding when the message 'Please wait for stack swap' is displayed at start up. However, when attempting to run commands through the tool, an error message is recieved:

'Intialization - A device was not found. Please make sure that you have one plugged in.
If you are testing a full/low speed device, please connect the device to a USB 2.0 high speed hub and connect the USB 2.0 high speed hub to the USB 2.0 host controller on this system.'

It was thought possible that both these devices were being handled by the machine's BIOS, and not by the USB stack - which may account for USB Command Verifier not seeing any attached devices. For this reason some other USB devices at the department's disposal were made available to me: a web camera and scanner.

—

USB A connector (male) viewed looking into plug

 _________
| 1 2 3 4 |
|||||||||||

—

Powered it up (from USB cable) after a few moments the GoodLink LED blinked, and windows announced that some hardware failed to install correctly. Encouraging.

Made some progress with low-level usb debugging. I found a tool on sourceforge called SnoopyPro (v0.20) which allows snooping of all traffic. Successfully logged “Hello World!” being typed on a USB keyboard, and saved this along with the enumeration and sequential keystrokes (ie abcdefghijklmnopqrstuvwxyz) to seperate log files.

Aquired a larger bread board and a new PIC chip - a PIC16F877. This ought to allow me to implement printf statements which output to USART and hopefully can be read by either my laptop (via hyperterminal or similar) or on the dumb-terminals in the lab.

Tied the USB and GBA link cables to the new bread board via nylon lacing wire, I was worried about the constant stress the solder-joints were experience as a result of transporting the electronics between home and uni everyday. I am confident that the lacing choord with take the strain instead of the solder now.

The transition from the old breadboard to the new one went quite smoothly. I did a continuity check between the plugs on the cables, and the tracks on the breadboard, and every pin checked out ok. I was a little confused to find the at the left and right most vertical tracks of the breadboard (which are split into groups of 4) each make a long vertical track, and not multiple groups of 4 as I expected. This caused a small delay, and initial worry about the solder joints of the cables. I assume that these lines are intended to be the power lines for the whole board, and I am using them as such.

So far I have not managed to get the flashing LED program to work on the PIC16F877, or the PIC16F84A when on the breadboard. I believe this is because I do not have an oscillator crystal to generate the clock signals. I assumed that chips could produce their own (somewhat unprecise) clock from reading their documentation, but upon further examination the minimum setup requires a resistor/capacitor potential divider. I do not feel the capacitors I have are suitable, and will inquire about getting a crystal as soon as practable.

Outdated! See USB for expanded / updated version.

After looking at the example from Philips' on how to interface the PDIUSBD12 with a HITACHI H8S 2357, I noticed that their example schematic (found on page 2) indicates that the V_OUT3.3 is grounded by two capacitors in parallel (one 0.1u and the other 1u). This strikes me as an odd thing to do.

The datasheet for the PDIUSBD12 has this to say about V_OUT3.3 (pin 27):

3.3 V regulated output. To operate the IC at 3.3 V, supply a 3.3 V to both V_CC and VOUT3.3 pins.

This supports my understanding of this pin's purpose (to conveniently supply power from the USB cable to devices which require 3.3V), but does not help with the parallel capacitors query. It is likely that this is some sort of standard practice of which I am unaware due to my limited experience with such things. I make enquires on the topic with the experts at universtiy.

The D12 datasheet specifies that the D+ and D- pins interface with the USB cable via 'termination resistors'. Again this concept is not familiar to me, and I gather from the HITACHI example that two 18 Ohm resistors placed in serial between the pin and wire are what is intended. There also exist two 1MOhm resistors which ground the D+ and D- wires, it is more likely that these are the terminating resistors, in which case the purpose of the 18Ohm resistors is a little unclear. I will check the foundation of this term.

It seems that EOT_N (pin 19) ought to be connected to the VBUS of the USB cable, as this is how the D12 does V_BUS sensing. The schematic shows a seperately powered setup, while I intend to use a USB-powered setup - hence I must be careful about how EOT_N is connected - the schematic shows that EOT_N should be connected to V_BUS at a point between 4.7 kOhm (VBUS side) and a 1 MOhm (GND side).

Again, two capacitors in parallel are used - this time between V_CC and the various pins it supplies with power. Perhaps this is being used for power-smoothing?

The write and read strobes for the D12 are on seperate pins - and care must be taken to ensure these pins never contradict each other.

There is a chip-select pin (CS_N, pin 11) which presumably is for enabling the data bus pins of the D12 in a multi-chip common-bus environment. In this instance the 877 has sufficient data ports to negate the need for such an approach, and so we must tie the pin low to ensure the chip is always selected.

RESET_N (pin 20) and DMACK_N (pin 18) should be tied high to ensure the chip does not reset while powerd, and DMA acknowledgement is unnecessary as there is currently no intention to use it.

ALE (pin 10) is the 'Address Latch Enable', and is intended for common-bus arrangments, it should be tied low in our case to disable it.

A0 should be connected to one of the general I/O pins of the PIC16F877, and is used to latch a command (directed to the D12). When this pin is high, the data bus is latched and interpreted as a command for the D12, when the pin is low, the databus is used for data to be passed through the D12. Presumably this compliments the normal method of clocked input. This brings rise to the issue how to start and stop sending data via the USB bus.

When the D12 powers-up the default clock setting is 4MHz and appears to be generated by an internal clock of some sort, which is apparently not very accurate (I do not recall reading a specific figure, however).

There is a note in the D12 datasheet which says

“There is no protection against writing or reading over a buffer's boundary or against writing into an OUT buffer or reading from an IN buffer. Any of these actions could cause an incorrect operation.”

Clearly this is an important remark to keep in mind when setting up the circuits and doing the initial debugging.

Another remark says that when a setup packet is recieved (from the host) the microcontroller must explicity acknowledge it before the validate_buffer and clear_buffer commands are re-enabled. This acknowledge setup command must be sent to both the IN and the OUT endpoints. This last bit was not obvious to me.

Curiously some of the timings in Table 17 can be negative, according to the footnote. This is somewhat odd, and as a matter of curiosity I will look into this a bit more.

After finally getting a resonator attached to the PIC16F877 (and discovering that the resonator needs to be as physically close to the PIC as possible in order for it to work reliably) I had erratic functioning from the PIC. It seemed to work when my leg was under the table, and not when I removed myself! Eventually Rod discovered that I had left the RESET_N pin disconnect, and hence it was 'floating'. Tying this high solved the problem.

I looked into the issue of termination resistors, and was advised by Rod not to worry about it unless I intended to use very high data throughputs speeds, which I do not.

While playing with the flashing LED program on my new PIC setup, I encounted a “Power surge on hub port” error on my laptop. This strikes me as odd, because the only things being powered by the port were 2 LEDs and the PIC, which are very unlikely to consume more than the 100mA which the USB spec permits before enumeration. Most likely one or two of the wires were shorting out.

I checked the voltage outputs of the MAX3232 signals before interfacing it to the PIC, and the signals were -6V and +7.5V, not +/- 12V as expected. Apparently this is not unusual behaviour. I interfaced it with the PIC, loaded some code Rod kindly sent me, and connected my breadboard to a dumb terminal. It was outputting some garbage for a while, but after changing the baud-rate on the terminal, it worked as expected.

See terminals_dumb_terminal_amp:hyperterminal.

Met with Roger, as usual, and asked for his thoughts on the footnote to Table 17, which listed timings for the various I/O, of the PDIUSBD12 datasheet, where it said “Can be negative”. After some thought the conclusion we arrived at was that these inputs could accept signals slightly early due to internal propagation delays.

I learnt there is no electrical distinctions between “Open Drain” and “drive active low”. Open drain usually denotes an interface that can only be a drain, or disconnect; while “drive active low” implies that the interface can also drive active high and be diconnected.

Yesterday I found out the distinction between CMOS and TTL logic: TTL is always 0-5V, while CMOS has a range of about 3-18V, and is much more suseptible to static electricity but also requires less power. It is best to consider the two as incompatible, due to different thresholds and such.

Borred RS232 extension coord from department, so I can use my desktop as a dumb terminal (via hyperterminal) and do development on my laptop.

Trimmed the LED legs for the board so I don't have to worry about them bending all the time when I pack away the breadboard for the cycle to/from campus.

Tried checking GBA compatability with TTL logic, using a logic probe. This wasn't very encouraging - the logic probe failed to show any state at all when powered from either the breadboard (0/5V) or the GBA plug itself (0/3V). I expect this is because of hysteria voltages in TTL logic being in the region of the GBAs output.

Oops! I'd forgotton to common the grounds between the USB powered breadboard, and the GBA powered link. As the GBA link cable does not have a seperate wire for ground (like USB does) I used the sheild, and this seems to work fine.

I also looked into UART on the GBA system, and found some encouraging links:

Did some more probing of the GBA comms, and noted that when the pins are diconnected and set as input, they float high (ie binary 1 in the register).

Moved the GBA code snippets to their own page: Code.

Made the board a bit more tidy.

Rechecked the GBA wiring to the breadboard, the white wire (via the plug) does not match up to any IO pin on the GBA hardware, as such one of the IO interfaces (SerialOut) is unavailable. I took apart my MBv2¹⁾ and checked used this cable to check my program code on the GBA was functioning correctly. It was. Hence the problem is caused by my cable which was originally intended for multiplayer games, and not it's current use. I cannot cut-up and use the MBv2 cable as I need it to program the GBA and it is expensive compared to other sources of cable.

I'm looking into http://www.gbax.com to see if they sell plugs for GBAs, I recall being informed during contact with them that they do.

Discovered that the department does not have a 6Mhz crystal, which the PDIUSBD12 requires. Rod has said he will order one, and that it ought to arrive beginning of next week, in the meantime I will attempt to use a 4Mhz resonator.

Met with Roger, as per usual²⁾. Some interesting points were raised:

• Using a 6Mhz Oscillator Module which is only connected to 1 of the 2 pins on the PDIUSB12D may work, and it's worth trying.
• The GBA output levels of ~3V will probably work fine with TTL logic, but it's worth looking into the threshold values of TTL and considering using comparators just in case.
• As a point of interest, we were both a little suspicious of reports that the GBA hardware can work at 0/5V levels on the communications port when working in its backwards-compatable mode (ie with GB and GBC games), partly because a standard GBA unit works on 2x AA batteries. Seeing as one of my housemates has some GB/GBC games I'll give this a try and see what happens.
• With regards to the project Presentation, should my project not be complete at that time (which is quite likely) then it would be best to focus on what did work and merely mention that there is a small portion missing. This way when the examiner comes to read the project report and it states “That bit that wasn't work? It's all peachy now” it shoulddn't give rise to suspicion — as opposed to beating myself up about how badly something didn't work through-out the presentation.

• After speaking to Barry, I have learned that the capacitors in the example cicuit diagrams are intended for power smoothing, just as I suspected. Barry feels I ought to account for this in my own project, and has provided me with the capacitors used in the example schematic.

Aquired a 6Mhz crystal from Maplin in town. Hooked it up and it seems to work — I don't have a scope handy to check the clock, but I did apply a voltmeter across the CLKOUT of the PDIUSBD12 and it indeed has a voltage (which indicates an active crystal). I'd better get started on interfacing the two chips!

Took apart my offical GBA link cable (which has a socket in the middle) and checked the connectivity of the wires to the SerialOut pin on the GBA - it seems all the pins are attached except the pin which corresponds to power — but this makes sense.

Attached the new cable to the pins with the following mappings:

Distracted over the last few days due to other work.

Connected the two floating V_DD and V_CC to power using a “shortcut” under the PIC chip.

Wired up a powerfilter on the PDIUSBD12 as found in the Hitachi example. (: Put details & link to example)

Wired up the PDIUSBD12 databus to the PIC16F877's port D. Port D's layout is spread over the PIC and wiring this up using the cabling I had would have been very messy, Barry suggested using a ribbon cable — something which had not even occurred to me — and was nice enough to tip the stripped ends of some colourful ribbon cabling while I was securing the new GBA cable to the bread board using nylon 'wire' (that “unbreakable” stuff) to ensure that the cable-board connection does not take the strain of bumps and tugs, but instead is absorbed by the board and cabling.

Also it came to mind that the before strobing the bus into the PDIUSBD12 I must allow some settling time, by means of a small forced delay in my code.

Had a play with connecting the GBA to the MAX3232 to try UART. I found that the darkfader app pair ought to be very useful, as there is a schematic (uart.gif) which makes use of a MAX3222 between a gameboy and a PC, it comes complete with a PC-side app which talks to the GBA-side; both with source-code. Having said that I looked through the GBA source, and while interesting and quite helpful, I'm unable to complile it as I am missing the libraries the original developer used (and I'm working in a different environment all together anyways) — there is a precompiled binary which seems to work on my GBA.

I did not manage to exactly copy the wiring in the schematic, and subsequently did not have any success getting the GBA to talk to my PC though — I will need to wire up the CTS and RTS pins of the RS232 plug if I want to copy the schematic exactly. I'll look into this.

I also started looking into the USB side of things, now that it's all wired up. Of all the demos I have from Philips, the HID Mouse using a PDIUSBD11 (note I am using a PDIUSBD12). The purpose of the code is very clear (transmitting directions which are sent from keypresses on a development board), and it seems that Philips were using a 8051 microcontroller; much like in their Hitachi example setup.

Windows reported that an unknown USB device failed to enumerate after I played around a bit - it seems that the PDIUSBD12's A0 is just a flag for commands, and not a strobe itself, which I thought it was. Once I discovered this I was able to step through my program very (very!) slowly by tapping keys in hyperterminal. It would consistently show that something failed to enumerate at the end of the 'Set Mode' command. Unfortunately once I removed the need to press keys on hyperterminal I was unable to reproduce this. This may be related to my trying to use SnoopyPro to sniff the activity (and it does seem to make USB less reliable — my combination mouse / keyboard device sometimes appears to be unplugged with SnoppyPro's sniffer service is installed).

Also it seems that my wiring is not quite right, I noticed on the 8051 example in the PDIUSBD12's datasheet that there is a pull-up/down resistor on the INT_N line. I'm not sure whether it is a pull-up or a pull-down. I doubt this is what is causing my problem, as it isn't meaningful for the PDIUSBD12 to generate an interrupt before it is enabled or active.

Probed the circuit a bit using a logic-probe while running the thing on batteries to try and ascertain if the D12 was flagging an interrupt because of an interaction on the USB bus. Seeing as it was battery powered the USB plug was not connected to anything, and the probe showed that the INT_N line was still low. I suppose it must be the lack of a pull-up resistor. I'm still a litte uncertain how this adding a pull-up resistor is going to help thing, but it's in the schematic so I'll follow through. I'd better find out why it's needed though.

Adding a 820 kOhm pull-up resistor (i.e. connected to V_DD) hasn't changed the INT_N line, perhaps it really is sending an interrupt? I'll try acknowledging the INT_N, although so far I've not gotten any feedback from the D12 via the PIC, so this might prove to be troublesome in itself.

The PIC is not on the breadboard at the moment, and the D12 is outputting lows on the databus - which means it's not accepting the bus as input. Tying WR_N or even RD_N does not seem to change this, which is not too suprising as it's a strobe so I'm unlikely to see the tiny transaction take place, but I'm still somewhat suprised it's activly outputting low on the bus; there must be more to it. A0, RD_N and WR_N all seem to be inputs (the logic probe does not show either 0 or 1, (or both as in the case of the clock signals)) as expected.

I've not been able to work out why this is happening, and I'll have to look into the resistor issue tomorrow - on BeyondLogic.org their schematic shows a 4K7 Ohm pull-up resistor on the INT_N line, although they are using a PDIUSBD11, not a D12 like me.

Odd, I turned it on this morning and the interrupt line was high (i.e. not triggered).. very odd. I've not changed anything since last night. I swapped the reisitor to a 4k7 Ohm one like on BeyondLogic.org's schematic, and it still seems to be working as hoped. Which is encouraging.

Nope, isn't working again..

I've changed the RESET_N connection to the D12 to now connect to one of the I/O pins of the 877, so I can reset it through my firmware. This is something the example firmware from Philips seems to do. On a similar note the Philips firmware simply writes to the D12 as it's first instructions, which reinforce my view on this — and only further confuses me as to why the D12's bus seems to float low, when it ought to be input!

OK, it seems that when the D12 is in a reset state (i.e. RESET_N is low) it does not generate an interrupt (INT_N is high, as shown by both my test code on the PIC and a logic probe), but once RESET_N is brought high, INT_N goes low signalling an interrupt immediately.

At least I now know that my INT_N pull-up resistor circuit is working, and that the two states are clearly defined and readable. I guess I need to find out how to service this interrupt.

Seeking Rod's experience and advice on my problem, he suggested looking into whether the RD_N and WR_N lines were in conflicting states. I set took the 877 out of its socket (so the bus was not connected to anything) and manually tied WR_N and RD_N into known states and probed the bus. Sure enough setting RD_N high and WR_N low made the D12 bus goes into it's third state (input) and do a no-show on the logic probe. Now to put it together in my PIC code.

The code in the PIC was fine, turns out that PIN_B3 on the PIC wasn't working as an output. I fiddled a bit, but was not able to find a reason or a work around — not all of port b on the PIC is in use, so I've simply changed the pin that the D12's A0 connects to, it is now PIN_B6. I did a find a replace on my code, programmed it and tested it, and I now see (from my code output) that the Interrupt register bytes are 0x40 and 0x00, while all the last transaction status registers are 0x00 (which is as expected).

A quick look in the datasheet shows that 0x40 (binary 0100 0000) is a bus reset.

Re-worked my test code into functions and even interrupt service routines, make some cosmetic changes to the source code and debugging statements (i.e. the printfs), as well as defining things like D12_A0 using compiler directives.

Did plenty of testing and am satisfied that this code is reliable. It configures the PDIUSBD12 into a known state, where the GoodLink(TM) LED comes on at the end of the code. This is an important milestone, so I have put the code up in the USB section, see GoodLink(TM) code.