SCSI to Ethernet Adapter on New Hardware

[landoGriffin]

For future readers of this thread.... I wasn't able to get the xmega-pdi-pi2 programmer to work with my ATxmega128a3. It threw an error while trying to program that there was a mismatch at address 212 :-(  

I'm giving up on the pi method, and ordered the Olimex AVR-ISP-MK2  I've got too many projects lined up. Spending a day debugging a MCU programmer to save $25 isn't high on my list

 

[reukiodo]

Are there any plans to sell a complete kit? or even a complete model? I'd love to pay extra for the ability to just plug into a Classic.

 

[landoGriffin]

Are there any plans to sell a complete kit? or even a complete model? I'd love to pay extra for the ability to just plug into a Classic.

I'll have an extra fully assembled board and ~3 spare PCBs once this is done. Once I get it working, let's talk!

 

[landoGriffin]

@saybur - Is there any additional setup that I need to do to make scuznet work?

I've programmed the firmware with my brand new AVR-ISP-MK2. When I connect it up to my SE/30, the Nuvolink driver detects that it is there (it doesn't complain that the device is missing at startup). The Nuvolink utility also detects that its there and reports the MAC address as expected. 

However, whenever I try to do something on the network (Ping using AGNetTools, or open a web page with Netscape), the entire machine freezes.

Do I need to have an SD card installed for the network functionality to work? (Currently, the slot is empty)

SCSI probe doesn't correctly decode the "Nuvolink" information. Did you see this as well? (I ran into this problem while trying to develop this functionality on RaSCSI. SCSI Probe seems very picky about how the INQUIRY response is formatted.)

Here's a picture of my board, in case you notice something blatantly obvious (like I have a chip on backwards or something). Note that I patched in a micro-USB power port instead of using the 5v barrel jack. That's what the giant booger of hot glue is.

 

[saybur]

No, it should be working at the point you're at. I don't have the firmware in front of me, but as far as I can recall the weird INQUIRY response is normal. Basic bus transactions must still be fine to get the info from the Nuvolink utility, so I'm guessing it's not anything with your soldering.

Are you using the most recent commit in the git repo, and did you compile with debugging enabled? I'll get my board out tonight and see if I can get some additional stuff added that might be helpful in figuring this out.

 

[landoGriffin]

I built with the default options (just "make all"). It appears debugging is on by default, so I do have debugging on.

I did built with the latest version. I forked your repo so that I could make updates to the README with some instruction updates. But my fork is up to date with your repo.

Is the "TX" debug port just a RS-232 type signal? What baud rate did you use? I can hook up a TTL receiver and try to capture some info, if that helps.

 

[saybur]

It should be 500kbaud, but it's mostly just symbols at certain code points. I should really get a proper debugger some time...

Thinking about this more, I wonder if it might be a power problem: the Ethernet controller draws extra juice to transmit, and it might be enough to cause the MCU to do a brown-out reset if the USB power source isn't up to the task. I was thinking of adding an LED pattern on reset so you could see it, but if you tie into the debug line you should be able to observe a reset that way too.

 

[landoGriffin]

Ooo... Good call. I'll give that a try!

 

[saybur]

I pushed an update to Github to help narrow down if this is a power problem. The Xmegas have a nice register that shows what the cause of the last reset was; I added a handler so if a reset was triggered by a brown-out the device will halt and go into a LED blink loop (1/2 sec on, 1/2 sec off). I figure a brown-out is a Bad Thing no matter what causes it, since it probably indicates the PSU is bad.

If you could, try the most up to date firmware and let me know what you see. If you don't get the looping blink, could you let me know what state the LED is in when the system freezes?

 

[landoGriffin]

Thanks for the update @saybur, I just tried a 300w, 5v power supply with the same result. I'm questioning whether its really a brown out. But, I'll still give the new firmware a try in the morning.

What do you use to monitor the console output? I'm using TeraTerm, but it looks like some of the characters that the software is sending are not printable ASCII characters. If you could double-check and share your serial port settings, I'd also appreciate it. The only time I see any output is on 9600baud. They're garbage characters, but I think that's expected.



What is the non-power LED normally supposed to be showing? Its off most of the time, but I'll see if flicker ever now and then. Activity maybe?

Thank you for your help! I really appreciate it!

 

[saybur]

Yeah, I agree that makes power issues seem way less likely. For the UART, 500kbaud is correct, but the device uses binary, not ASCII.  Try that and see if data appears; debug.h has the symbol meanings.

The LED will light during startup very briefly and again during bus transactions. Non-data transfers are fast enough it usually will just flicker briefly.

 

[saybur]

I've added a "testing" subdirectory to the Github repo that can be used to build a special firmware for doing post-assembly verification of a PCB. It's not comprehensive at all right now, but my goal is to expand it to cover as many of the connections into the microcontroller as possible. Boards like this have so many small parts that they are really annoying to debug if the hand-soldering is not perfect; I remember assembling some SCSI2SD clones a few years ago, and how much I appreciated having the scsi2sd-util helping me out when I had dry joints on some pads.

@landoGriffin, I have a feeling this won't cover what you're experiencing yet, but I hope to get the control lines added to the board test firmware here over the next couple days.

 

[landoGriffin]

@landoGriffin, I have a feeling this won't cover what you're experiencing yet, but I hope to get the control lines added to the board test firmware here over the next couple days.

Thank you for your help, @saybur! I did notice I had some of the resistors installed sideways, but fixing those didn't seem to help. More troubleshooting tomorrow night!

 

[saybur]

All right, the most recent commits on Github have a much more comprehensive test suite ready to go. It requires building a simple loopback adapter for the DB25 connection, with instructions in the repo. At the moment, this will check all of the SCSI lines and the connection to the Ethernet controller, but not the memory card. Hopefully this will highlight whats going on if its a problem with the hardware.

 

[landoGriffin]

All right, the most recent commits on Github have a much more comprehensive test suite ready to go. It requires building a simple loopback adapter for the DB25 connection, with instructions in the repo. At the moment, this will check all of the SCSI lines and the connection to the Ethernet controller, but not the memory card. Hopefully this will highlight whats going on if its a problem with the hardware.

Very cool!! Thank you so much!

 

[landoGriffin]

ITS ALIVE!! 

@saybur - I owe big time!! (Let me know if you ever want a RaSCSI, I'll hook you up)

 

[saybur]

Yay, awesome! Let me know if it causes any more grief, and glad I could help. 

 

[ronan]

Hi !

First congrats on your project ! And for all the work done, it’s impressive and promising for the future !

I’m trying a new design heavily based on yours but with a stm32 and firmware upgrades using usb and I was wondering about something you stand in your README : «The '574 is unnecessary and a result of a bad design choice on my part. It could be replaced with a '245. » Why the 574 is a bad choice ? The 245 is not a buffer with latch so you could miss frames right ?

Thank you again !

 

[saybur]

First congrats on your project ! And for all the work done, it’s impressive and promising for the future !

Thanks!

«The '574 is unnecessary and a result of a bad design choice on my part. It could be replaced with a '245. » Why the 574 is a bad choice ? The 245 is not a buffer with latch so you could miss frames right ?

The original design used the 574 with the latch clock hooked to /ATN, with the idea being to potentially fiddle with doing (slow) synchronous transfers; during periods when the board needed to read when /ATN was not active, an extra 74126 gate was used to block /ATN and let the microcontroller drive the latch. In the end, I felt like this caused more problems than it was worth, so I pulled the /ATN hookup from the released board but left the 574 there to minimize the disruption to the code. If I had to do it over again, I'd choose the 74LVT245 just to save an I/O pin - with async SCSI, the initiator will hold the data until you negate /REQ, so you're not in any danger of missing data.

The Xmega chip here does support firmware updates over USB, if that's the main thing you'd like to get. I didn't think to implement it on the board, but it could be added fairly easily by moving some signals around. AFAIK, all Xmega chips ship with a USB bootloader, so you wouldn't necessarily need a PDI programmer this way. That said, there's lots of advantages to an Arm chip here, so if you do make something let us know, I'd love to see it!

 

[ronan]

The original design used the 574 with the latch clock hooked to /ATN, with the idea being to potentially fiddle with doing (slow) synchronous transfers; during periods when the board needed to read when /ATN was not active, an extra 74126 gate was used to block /ATN and let the microcontroller drive the latch. In the end, I felt like this caused more problems than it was worth, so I pulled the /ATN hookup from the released board but left the 574 there to minimize the disruption to the code. If I had to do it over again, I'd choose the 74LVT245 just to save an I/O pin - with async SCSI, the initiator will hold the data until you negate /REQ, so you're not in any danger of missing data.

Just to make thing clearer you would design something like the the image I attached to this post ? (Maybe directly connect the DIR Pin to GND/VCC to choose and fix the right direction of the 245).

If I understood well you would use the 245 only as a level converter. But for instance the STM32 as a high input threshold at 1.88V so it would not even need a chip between the physical port and the chip.

That said, there's lots of advantages to an Arm chip here, so if you do make something let us know, I'd love to see it!

Sure ! I'm pretty close to releasing a PCB, I will keep you posted and release everything on github !

My idea with the STM32 is that indeed it's an ARM mcu but it also supports well USB and I was thinking maybe in the future to be able to do some ethernet other USB. So that we would be able to share files between a computer and the vintage macs using only USB