Jump to content

saybur

6502
  • Content Count

    51
  • Joined

  • Last visited

Recent Profile Visitors

367 profile views
  1. Yay, awesome! Let me know if it causes any more grief, and glad I could help.
  2. 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.
  3. 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 h
  4. 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.
  5. 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?
  6. 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.
  7. 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.
  8. 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
  9. 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.
  10. The old school advice on tantalums was to derate by 50%, so maybe this is just an instance of failure from running too close to the margins, even from the factory? It might be worth going to 20 or 25V on the replacements.
  11. Microchip has a great writeup talking through the low-level behavior of the bus if you end up making a microcontroller project: http://ww1.microchip.com/downloads/en/AppNotes/00591b.pdf If you tackle this, maybe a multicore chip like the Propeller would be a good fit to do the software decoding/encoding of the ADB timing? I don't know hardly anything about them, but it sounds like having separate execution "threads" would be good for keeping track of the mess of different signals all going at once.
  12. I personally use and like the Olimex AVR-ISP-MK2, a clone of the real AVRISP mkII. Mouser and Digikey have it for ~$24 and it is useful across the main 8-bit AVR line: it does ISP for regular AVRs and PDI for Xmegas like on this board (though not UPDI on the new mega0/tiny1 chips). Most of the tutorials out there are for the standard AVRs using ISP, but I did see a Raspberry Pi program for PDI here: https://github.com/DiUS/xmega-pdi-pi2 It looks like it hasn't been updated in a while though.
  13. Great to hear, I'm glad people are getting use out of it. Let me know if you see holes in the docs, I can fill those in from the original hardware if needed.
  14. I've got a troubled IIci and was hoping some wise soul here might have a good idea about what to try next. This system boots up but does not register anything over ADB. Shaking the mouse during or after startup does nothing, nor does typing anything on a keyboard. After the machine boots, pressing the interrupt brings up the usual prompt. This keyboard and mouse are my bench ones I use for testing machines and work on other systems. I verified that 5V is present on the ADB power pin and ~4.7V (or something similar, I don't quite recall) is on the data pin. Soft power from the keyboar
  15. Hey, a fellow Iowan! I'm glad to hear you were OK, that was one wild storm. We just got power back a few hours ago in Ames, so hopefully they'll get things fixed for you soon.
×
×
  • Create New...