Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by saybur

  1. When I had trouble doing this, I had to get into scsi2sd-util and hack in additional debugging to get more than the a terse "things didn't work" message. I don't have the modified versions I made, unfortunately.


    To roll your own, in scsi2sd-util.cc there's a (myHID->scsiSelfTest() ? "Passed" : "FAIL") statement. I believe the value returned there is the same integer returned in the firmware's self-test, defined in scsiPhy.c, where certain bits are set if particular tests failed. You could change the line so instead of doing a pass/fail conditional it just writes the results of scsiSelfTest() to the console so you can check which bits are set.


    In all cases with me the problems I had were with with bridged / dry pins on the main SoC. The 0.5mm spacing is tight and it's hard to see if there is a problem there, even using a loupe.

  2. Ah, I get what you guys are aiming for. Just to explore the concept:


    It looks like a 2.5" HDD is about 100x70mm, which is basically the same size as this board, so the circuit could probably still fit OK. You'd want to keep the base SCSI interface and SD card, but rip out the ENC28J60 and replace it with some kind of wireless access device. That part might be problematic; the ESP8266 type devices have their own TCP/IP stacks, but the Nuvolink protocol assumes lower-level access to the network. It looks like some people have figured out how to make the ESP8266 enter promiscuous mode and work with raw packets, but both that and WiFi framing in general is not in my wheelhouse.


    Assuming you could get the hardware put together, there would be a bunch of firmware work that would also need to be done. From the scuznet base, you'd need to rip out enc.c and net.c at minimum and replace them with something suitable for talking to the wireless controller. You would also likely need to develop some kind of Mac utility that could send wireless control information to order the WiFi device to associate with the correct network and that kind of thing, unless it was programmed in the firmware somehow.


    It seems like an interesting idea, but I'd consider it to be out-of-scope for this project. If someone wanted to tackle it, hopefully the work done here would at least make their lives easier.

  3. On the power side, after doing some more research I don't believe the USB-C approach will work easily. The ADC pins on the Xmega are all blocked in the current layout and I'm not keen on changing that if I can avoid it - it took quite a while to arrive at the current layout, I'm pretty happy with how things are, and it has been tested to work. There are some external ICs to support USB power but they seem to all be in hobbyist-unfriendly packages that would make this (already tricky) board harder to solder.


    As for sourcing from TERMPWR, after doing the math I'm leery of doing that. This board draws considerable power for the non-termination components (possibly up to 380mA), which combined with a second active terminator on the bus could overload TERMPWR and potentially blow the Mac's fuse. Also, for the systems that supply TERMPWR, they should have a diode on the Mac which could possibly drop the line to ~4V or so; adding an additional diode to allow "auto-switching" between USB/barrel/etc could push the line so low it might not be able to provide enough headroom to let the 3.3V regulator operate properly.


    There are two approaches I'm considering.

    • Require the barrel jack, draw all power from it, and just hang the USB off the board as data only. This is the KISS approach and avoids problems with sketchy TERMPWR, USB silliness, etc.
    • Alternately, move the terminator over to TERMPWR and use USB 100mA/500mA power for everything else. I would need to add enumeration support to the firmware, which is doable, and set things up to keep the peripherals in reset until the device is authorized to pull the higher power level or determines that it is attached to a dumb power brick.

    I'd be interested in hearing if there might be another alternative I've overlooked, if anyone following along has thought of it.

  4. No, I think you're right, from what I've heard most chargers (especially cheap ones) don't seem to follow the rules and just deliver +5V until they hit their limits (or Bad Things happen, the Big Clive YouTube videos on those things are hair-raising). I'm more concerned about plugging the board into a computer for programming, where the amount of power available is likely to be restricted to the USB spec.

  5. 18 minutes ago, ronan said:

    You could manage to get power from USB, so you could easily remove the jack :) 


    Definitely. My only concern with USB is the power negotiation step; I figure this board has a peak draw of ~950mA, including the terminator, which would exceed standard USB's 500mA. When you get into the higher power levels, AFAIK you have to actively negotiate with the supply, which is more complicated than just throwing a barrel jack on the board and calling it a day.


    USB-C has the CC pins to indicate power availability, and I was considering going that route as an alternative. I've heard horror stories about bad USB-C cables, and I'm not 100% sure I understand the spec, but from what I can read it looks like an ADC input could detect the available power level and just refuse to start the terminator and/or other devices if insufficient power is available.


    28 minutes ago, ronan said:

    I also added a double DB25 port to be able to daisy chain the board, I used this one : https://www.digikey.fr/product-detail/fr/adam-tech/DPD-25-00-B3/2057-DPD-25-00-B3-ND/9833611


    I think that's a great idea. The board is too short to add it at the moment, but I agree the feature would be nice for daisy-chaining.


    29 minutes ago, ronan said:

    Maybe you could also add mounting holes ?


    The case I suggest (Hammond 1455L801) doesn't require them, but there is plenty of spare space along the edges kept clear for the PCB rails. I can probably sneak in mounting holes. :)


    Thanks for the feedback!

  6. I'm doing a revision of the hardware to add extra features and correct some bugs. @ronan also made good observations about things to fix, which is appreciated. Here's the list of what I'm working on:

    • Move from KiCad 4 to KiCad 5, and change the footprints to match the awesome new library versions.
    • Add USB for reprogramming & config updates (not sure if USB-C or just micro at this point, and I'm uncertain about powering via USB or leaving the barrel jack).
    • Change the linear regulators to use more reasonable packaging, they're significantly oversized.
    • Fix the oversized footprint on the barrel jack if it stays.
    • Extend the board depth by 0.5mm to fit the case better, it tends to knock back and forth a bit.
    • Shift the Ethernet / power plugs to get a bit more room on the back.
    • (Possibly) add a jumper to use TERMPWR for board power.
    • (Possibly) switch from the microSD socket to a full SD socket and upgrade the software to allow hot-plugging.

    For anyone who has built one of these, were there other things you found annoying and/or features you thought were missing?

  7. That's mostly how I figured it, assuming a 250mA load: (5-3.3) * 0.25 * 235 to get the 100C rise. The 250mA was just a ballpark figure, based on the max 180mA the ENC28J60 uses while transmitting plus a random amount extra; you'll probably want to run through what the max current consumption is for the various components to build a power budget and then add a bit extra for safety.

  8. I'd suggest swapping the MIC5319 for an alternative 3.3V regulator. SOT-23-5 won't be able to reject all that much heat; if you figure a max draw of ~250mA and a 5V input voltage (worst-case after the diodes), that's a ~100C temperature rise for that package. An alternative might be the MCP1825: it has minimal capacitor requirements, is available in SOT-223, and has a similar dropout voltage.

  9. On 11/12/2020 at 7:16 PM, Chopsticks said:

    Now that I've got this running 100% I was wondering if there is any way to make the driver load on a unsupported Mac model. my SE/30 has an install of 7.6.1 (os 8 at some stage too) and I had to 'fool' the Mac to think its a Quadra 700 for it to boot this version of the system, but the NuvoLink extension complains on start up that this model isn't supported so I was wondering if there's anything I can hack in resedit to get it to load?


    I'm not very knowledgeable about the Mac driver side of the equation. There might be a hack to make the driver skip the gesalt check, but if there is I'm not aware of it.


    Another avenue might be to try the Focus drivers instead. From what I've read the Focus EtherLAN SC is basically just a rebranded Nuvolink SC, but I've never tried using their drivers on a scuznet board. I suspect they probably changed some stuff in the INQUIRY response to keep this from being easy.

  10. 47 minutes ago, ronan said:

    There is a connection to « CD » , I set up solder bridges to activate the connection or directly connect CE to GND. I did not connect CD to the STM32 though, is this something useful ? 


    Oh, OK, I get where that's going now. I'd suggest not doing it that way; there are situations where you will need to read the data bus when C/D is not asserted. It would probably be easiest to assign it to a free I/O pin to maximize your control.


    51 minutes ago, ronan said:

    I saw that on your GitHub yes. I’m going to look for more adjusted resistors on digikey and see if I can get closer to 2.85V. Should the terminator resistor arrays value be adjusted if I change this voltage ?


    Yes, they're specific to the 2.63V variant. Standard SCSI terminators are 110ohm, so that'd be the likely choice.

  11. On 11/4/2020 at 6:43 PM, Chopsticks said:

    just wondering if anyones had a similar issue of getting a crash to macsbug with when trying to shutdown the ir mac when the drivers are installed but the device isn't connected. i built one of these up and  this seems to happen every time its not hooked up via scsi unless i remove the driver from the extension folder. just not sure if its an issue on my end with my setup or if others had had similar issues.. again this is a driver issue not a issue with the scuznet board


    I haven't had this ever happen to me, usually it just complains about the device not being present. What computer and OS are you running?


    On 11/3/2020 at 6:10 PM, ronan said:

    Okay I have a first version of the board with an stm32 which is heavily based on your design. I attached the schematics if you want to have a look, as well as a first render of what the board would look like.


    I've been badly distracted by the (lame) real world but I did manage a quick pass through the schematic. I'm completely unqualified to look at the STM32 side of things, so the following are just observations on the SCSI / Ethernet parts. Like I've mentioned elsewhere in this thread, I'm no expert on this or anything, so definitely feel free to ignore the below advice without any concerns! :D

    • All the driver chips are LS series in the schematic; I'm assuming you probably want LVx parts instead.
    • It might be good to add 100nF decoupling capacitors on all of the ENC28J60 power pins. I didn't read anything in the datasheet on this, but it is likely best-practice.
    • I didn't see a connection for the "CD" signal on U8's /CE pin, but I may just be missing it. If you're running short on free I/O pins RDBP is pretty useless and could be dropped; I'm pretty sure the only time I've used it is to do a diagnostic check on the TDBP driver.
    • R11 is the only 22ohm series terminator left on the Ethernet SPI bus. I added them to be on the safe side, since the board had decently long traces going to the Ethernet chip, but they may not be needed on your board.
    • Per the note by U4, be aware that combo of adjustment resistors should produce 2.63V for the termination resistors instead of 2.85V. This is an alternate configuration for the 100ohm resistor packs.
    On 11/5/2020 at 7:16 AM, ronan said:

    I'm going to upgrade my design to get power from SCSI and let a usb port for power fallback in case !


    Over on the Bluepill SCSI device thread in Peripherals there are some reports of issues with certain systems not supplying great power; assuming that you get 0.7V drop from the Mac diode supplying TERMPWR, you're running close to the 1V dropout voltage on the LM1117 supplying +3.3V. You might want to switch to a low-dropout regulator if you're sourcing from TERMPWR. Also be aware that the Ethernet PHY can draw up to 180mA by itself when transmitting - this is not a low power board, unfortunately. IMHO I'd definitely keep a provision for external power.


    On 11/5/2020 at 7:16 AM, ronan said:

    @saybur : I don't want monopolize your topic, I can create a new one if you want to


    It doesn't bother me at all, but it might be a good idea to make a new thread to let people not following this one know that a different approach is out there. A couple users noted early on that they would have liked to see this design based on an ARM chip anyway, so there may be interest for sure.


    If you do make a new one I'll definitely be following along, I'm interested in seeing where this goes. :)

  12. Great graphic, that's how I'd do it. Since the 245 is permanently reading from the bus you should be able to tie DIR without a problem. In case the bus floats for some reason (bad termination?) you might want to toggle /OE only when you know data is on the bus. The LVT transceivers have a 10ns/V transition time recommendation with "outputs enabled," so the current scuznet firmware does toggle /OE to avoid having the outputs on except when necessary, in case the SCSI bus is being sluggish during transitions. I don't know if this is strictly "needed" or not.


    For bus reading, the buffer is there mainly for 5V protection (the Xmegas are TTL compatible at 3.3V). You could probably get away with not using the buffer, depending on what's on the bus: if all devices are open-collector, you should only see 2.63-3.0V on the lines. However, SCSI does allow push-pull drivers on most lines, and those can output up to 5.5V and still be in spec. I'm not familiar with the STM32s, so they may have 5V tolerant GPIO pins to avoid the problem.

  13. 13 hours ago, ronan said:

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




    13 hours ago, ronan said:

    «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! :)

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

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

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

  17. 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?

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

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

  20. Yeah, just in the documentation so people know not to connect external terminators. Apart from asserting /RST anytime another target tries to talk I doubt there is a way to force having just one device.


    If the transfer speeds are low you might be able to get away with some pretty nonstandard termination that wouldn't exceed the power budget. Maybe try something super simple, like 1K pull-ups to 3.3V? There are transmission line effects to consider, but that's black magic I have no experience with.


    AFAIK there were some Macs that had automatic termination supplied by the mainboard as well, which might cause grief in some setups.

  21. The STM32F103C8 is only rated to sink up to 150mA total across the device; even with only 1 active terminator on the bus that limit will probably be exceeded. It might be worth limiting the SCSI bus to just this one device and omit the terminator? Alternately, buffer chips driving the output lines would also fix the problem, but that'd obviously increase complexity and cost.

  • Create New...