RapidRoad USB starts shipping oct-20-2014

[demolition]

Originally Posted by copse

Does look like a software issue. Does not look like a hardware issue. Right?

True, the good news from him was that there was no need to ship anything back to have it fixed, thus it was not a hardware issue. So it can only be a software issue which can be fixed 'remotely'.

[roomeo]

Today I upgraded my a3640 from rev 3.0 (with cut'n'jumper patch) up to full 3.2 revision.
Nak timeout still apear in zIII mode.

Does anyone know if the RapidRoad works with an A3640 with an 060 installed?

[roomeo]

Dunno, but I am about to test this as soon as I get hold of a 060..got the adapter ready to plug in. I have my doubts though.

[Schoenfeld]

Current investigation has shown that IRQs get switched off by "some software" in Z3 mode. It's a bit tedious to find that piece of software, as it does not seem to be anything in the driver itself.

If all else fails, I can probably make a fix in the hardware (CPLD programming) that keeps IRQs enabled all the time (i.e. make it a "write-once" register). However, I prefer to solve a problem at the cause, and not to fix the symptom.

Jens

[roomeo]

By "some software" you mean stuff we have installed not related to RR?

[Schoenfeld]

I can't point to anything right now. The current state of investigations is that after the IRQs have been enabled, they get disabled again. It'll be quite some work to pinpoint the source - that's WIP.

Jens

[roomeo]

Ok.

Wouldn't it be possible to make a little code snippet that turns the irq on again as a patch? Or is it something that bangs the irq off constantly?

For the record I think all of us have installed things from scratch.. so the os might be the culprit?

[spudje]

For those facing the issue and having enough technical knowledge. Can they somehow help you pinpoint the cause Jens?

[Schoenfeld]

Even if you'd have the technical knowledge and equipment, you could not help as much as my logic analyzer can do: I can use free pins of the RapidRoad CPLD to trigger the logic analyzer if the IRQ enable bit toggles from 1 to 0. I can then look at the address lines on the Z3 bus and tell exactly what address is causing the trouble.

In short: You'd need the CPLD source, and that's not public. I have a few more days with the ACA500plus, then I can free the development-place for the next debugging session of RapidRoad in Z3 mode.

Jens

[demolition]

If the CPU in the system has an MMU, would it not be possible to use it to detect access to the specific IRQ address? Or possibly just block the address with the MMU as a temporary fix?

[roomeo]

Im playing with the registers of rr just for fun.

base  equ $00EA0000 ;address of xSurf100
Start
        lea base,a0
        move.w $4801(a0),d0 ;read INT status of isp1763a
        rts

Running this will cause IRQ to shut down as expected. Poseidon goes haywire and alot of nak timeouts. Restarting the device in poseidon and usb is up and running again.

Now comes my question to confrm im getting this right. Reading this register while usb is running results in %0000 in d0. While usb not running i get %0010.

The status of the INT line of the isp1763a chip can always be checked by reading bit 1 of X-Surf-100 register offset 0x4800. Note that this is a word-wide register, so bit 1 is actually located in address 0x4801.

When saying bit 1. You start counting from 0 right? So this will be bit 1 set -> %0010?

Sorry for thread noise and noob question..

[Don_Adan]

Originally Posted by roomeo

Im playing with the registers of rr just for fun.

base  equ $00EA0000 ;address of xSurf100
Start
        lea base,a0
        move.w $4801(a0),d0 ;read INT status of isp1763a
        rts

Running this will cause IRQ to shut down as expected. Poseidon goes haywire and alot of nak timeouts. Restarting the device in poseidon and usb is up and running again.

Now comes my question to confrm im getting this right. Reading this register while usb is running results in %0000 in d0. While usb not running i get %0010.



When saying bit 1. You start counting from 0 right? So this will be bit 1 set -> %0010?

Sorry for thread noise and noob question..

Why you read word from $4801, not from $4800?
For me nak problem is software bug in xsurf driver only.
If you want i can give you resourced version of xsurf driver and you can try to fix this driver.
Bits are counting from 0 to 31.

[roomeo]

I have disassembled the driver, but im not that confident to understand all the code..

No reason to not read from $4800.. just a test and brainfart from my side.
Same results though reading from $4800 or $4801

[roomeo]

In z2 mode the INT bit in $4800 is set. In z3 mode it is not set. In both cases this is before i have initialized the rr device.

The USB module starts up with IRQ-passing disabled. This will ensure safe startup of the Amiga, even if the chip goes wild due to faulty software.

So to me it seems that in z3 mode, somehow this bit is set before any software is run. Basicly what Jens said i guess..

Please send me what you got.. Fun to look at.

[Don_Adan]

Originally Posted by roomeo

In z2 mode the INT bit in $4800 is set. In z3 mode it is not set. In both cases this is before i have initialized the rr device.



So to me it seems that in z3 mode, somehow this bit is set before any software is run. Basicly what Jens said i guess..

Please send me what you got.. Fun to look at.

Oki. I will put resourced driver to Zone tomorrow, if Jens or Chris will be not angry. If this is only INT bit problem for Z3, then this bit can be set in driver (software fix for hardware bug?). The best if you have access to Amiga with Z3 and no nak timeout problem. Then you can check if this bit is 0 or 1 for working Amiga Z3 config.

[roomeo]

I tried to set it in z3 mode and then initialize the rr driver. Same behaviour in poseidon (nak timeout). The driver could mess things up after this, but i dont think its a software issue. But this is ONLY speculation.
If i have understood things right, this bit should be set as default before anything is initialized.

I have only this setup to test on..

[Schoenfeld]

Originally Posted by roomeo

If i have understood things right, this bit should be set as default before anything is initialized.

...which is why the bit is set as one of the first things that the driver does.

Also, please note that Z2 vs. Z3 is fully transparent. Only the base address of the X-Surf-100 is different, but all other software is completely identical. Software initializes the USB chip (especially proper IRQ polarity), then enables IRQ passing to the Amiga, then does all it's other business. It works fine on Z2 machines, and there is a difference between some accelerators in Z3 mode. Since it does work for many Z3 customers, and our hardware-banging test routines also work even on a machine that shows the problem, there is no hardware defect that causes this.

Like I wrote yesterday, the only explanation I currently have is that some software hits a mirror of the register. There are a lot more mirrors of these registers in Z3 mode. So if you want to play around with MMU, then you could inhibit accesses to anything in the X-Surf-100 space that's outside the first 64kBytes (uses 64MBytes space in Z3 mode). If that helps, we may have a hint at where to look for the problematic piece of software.

Jens

[roomeo]

Cool. Thanks for that clarification. I have no idea how to operate the MMU, but now I got a reason to learn it..

[Schoenfeld]

Thor's MMU lib will make things easier.

Jens