Micromys V5 Intermittent Functionality

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • Amiga 500


    I've not been using my Micromys V5 very much, but now that the system I built for it is complete, and I'm using it regularly, I've noticed an intermittent problem.

    1 out of ever 3 power cycles roughly.


    On power-up, once the Amiga has finished loading Workbench, the pointer is found in the top left corner of the screen.

    As soon as I try to move the mouse, the pointer moves to the top right of the screen, and pretty well stays there...

    I mean... if you play with the mouse, scroll the scroll wheel, etc... you can get the pointer to jump to to the left a bit, but it goes back to the top right soon after.


    Initially, I thought...maybe it's not auto detecting the computer 100% correctly, so I moved the Micromys V5 jumpers to the 'Amiga' position

    Based on information found here -> http://wiki.icomp.de/wiki/Micromys_V5

    But that didn't solve the issue..


    Then I thought...maybe the mouse connector (DB9) on the motherboard was worn or damaged, I got lazy and just swapped the A500 motherboard.

    But that didn't solve the issue.


    Sometimes, I can just unplug the Micromys V5 and plug it back in and the issue goes away

    But that's not a solution


    When the Micromys V5 'works' at startup, it stays working fine, I've not seen any issue appear after starting up successfully..


    If I unplug the Micromys V5 when its malfunctioning at start-up and plug in an original Amiga mouse, the pointer works properly.

    I don't experience any weirdness using the original mouse...ever...


    Any thoughts on why I'm seeing this odd Micromys V5 behaviour ?

  • First time someone reports such a problem i think - being a popular product, we'd know by now if there'd be a problem with the micromys and Amiga. *shrug* What kind of power supply are you using? Do you have a multimeter so you can measure the 5V at the joystick port?

  • I whipped up a little DB9 adapter to make getting the probe clips on easier


    Equipment


    Result


    4.98V DC

    Now...there could be a tiny loss due to the 3m of probe wire and the pinch probes and the DB9 connector...
    But it's a pretty good rendition of +5V DC

    The power supply in this case is just below the multimeter.
    Despite its appearance, It is not an ATX PSU, and it has independent switch mode supplies for +5V, +12V and -12V rails, as well as ample capacity (10A on the +5V rail)

    I have the same trouble when I use an original Amiga PSU to power this system.


    The A500 has an Indivision ECS V2, ACE2b, Lyra3 and ACA500+, running OS 3.2, not sure if any of those 'variables' could be contributing ?

  • Okay, so I made a pass-through to measure the voltage


    Setup

    Results


    4.83V DC


    Please keep in mind, you asked me:
    "Do you have a multimeter so you can measure the 5V at the joystick port?"


    The most immediate interpretation of that is:
    "Please stick your multimeter probes into the joystick port and measure the 5V rail"
    which...does imply no load, but there we go..all fixed.


    I am happy to build jigs, and measure things, and wheel the lab up here if need be.

  • Although that's a significant drop, I doubt that voltage itself is the problem. However, with such a contraption of funny PSU and non-standard case, I'd like to see the grounding/shielding efforts before I do any more support work here.

  • What is the expected load of the Micromys V5 contraption ?

    Since the mouse is also supplied through Micromys, you can't say what the total consumption "should" be. However, 32mA sounds small enough. The MCU on Micromys has the voltage watchdog programmed to 3.8V. If your mouse is drawing lots of power - possibly intermittent by switching on it's light - Micromys will only do an internal reset if the voltage drops below 3.8V. That would require the combo of the two to draw over 250mA, which is very unlikely.

  • Mouse being used is Adesso HC-3003PS, just in case "that's a thing"
    I mean ... I suppose the mouse itself could wake up on the wrong side of the PS\2 bed and something goes wrong there..

    Unfortunately, I only have one PS\2 mouse....
    {adds second PS\2 mouse to shopping list}

  • I'd like to see the grounding/shielding efforts before I do any more support work here.

    Okay, totally willing to help on my end.
    I've completed a full tear-down and reassembly taking a hundred or so photos of areas of interest.


    Your request is 'open ended', there is no way for me to definitively answer, but I'll do my best by showing some of the grounding and shielding and if there is a more specific aspect you'd like to see, I will change focus to that.


    Edited, factory lower shield


    Factory insulator


    Board-in connector shield screws


    Star-Topology grounds wires connecting A500 Logic Board and Indivision ECS V2 to the ground at system power entry.


    forum.icomp.de/core/index.php?attachment/2384/

  • OK, bottom shielding is already a good start. However, since I normally refuse to do support work for that Checkmate 1500 case, and while you're at disassembling anyway, why don't you launch the system without the case, just with a normal A500 PSU and see if the intermittent functionality stays the same? After all, "fault isolation" means excluding certain components, so it's always a good idea to start at the smallest-possible configuration.


    If you can borrow a second PS2 mouse, this would also help.

  • and while you're at disassembling anyway, why don't you launch the system without the case, just with a normal A500 PSU

    "I've completed a full tear-down and reassembly"

    Umm...it's all back together again...and funny...did the 'odd' mouse thing described above on first boot :)


    I'm away house shopping today, but "I'll be back"


    How about this?
    I have the first A500 board, the one where I first saw the issue...
    I can stuff it back in it's ugly old plastic coffin, with a second Indivision ECS V2 and a second ACE2b.
    Alas...I don't have a second ACA500+ ... so I'll move this ACA500+ and this Micromys over and whip out my decrepit Amiga power brick.


    Having already seen this behaviour with the Micromys on that board, using the described setup, I'm reasonably confident "the walk" won't be for nothing, as the odd behaviour is sure to show up...


    For a couple of months, this system ran on my desk like this; while I waited for the CM1500 case to show up...


    Powered by the stock power supply...
    And I never said a word about the mouse, because, who's gonna show a picture of a system running like that and say "Help me Obi-Wan"


    I'd point out that the ACA500+, ACE2b and Indivision ECS V2 have been 'otherwise happy' to live in the case and consume the power that I've provided them...old A500 plastic box, logic board screwed into an A500 bottom shield, new CM1500 case, old Commodore PSU, new PSU made by me, they all worked the same. Having looked at the support history of all the iComp designed contraptions involved here, the Micromys does not seem like it should be anywhere near the 'weakest link'. There are so many other iComp contraptions in this setup that are sensitive to power, shielding, grounding, that they would likely be going haywire, if there was such a problem.

    "Fault Isolation" is indeed a good diagnostic practice, but it can also lead to reduction to the absurd if you let it.


    I'm going to get a couple other PS/2 mice and start there, because I think that really would be the simplest thing first.
    If it turns out it's the mouse, my best guess is it's protocol related, I'll send it to you, so you can see what it does differently, and maybe increase Micromys compatibility with what's available on the market...which isn't a whole lot these days.

    If the problem continues with other mice, then I'll proceed with the second A500 in a plastic box as outlined above.

    Chat you in a couple days :)

  • Good news,


    I ordered a couple alternative PS/2 mice from Amazon.


    For the last couple days, I've been using a:
    Make: Perixx
    PERIMICE-209
    Part: M-868


    So far, I've not seen the 'odd' mouse behaviour...which is great as that was getting frustrating :(
    I'm going to try the Adesso PS/2 mouse on an older Windows machine over a week, and see if I can get it to behave 'odd' at start-up. I feel obliged to help narrow down if this is simply a defective mouse or possibly a Micromys V5 compatibility issue with that mouse at startup.

  • Maybe just a contact problem? A loose connection or a break in the cable? After all, a mouse must be considered a consumable, as the ever-moving cable will break sooner or later. It's not a question of "if", but a question of "when".

  • Yeah, sure, wear-out is a thing, but it's three months old, the problem's been there since it was bought new.

    So statistically, lower probability of a wear-out, though still fully possible, bath-tub curve and all that.


    As it still could be a bad wire or contact, I'm testing it on a Windows machine, to see if it is the mouse or the interaction with the Micromys V5 that is the issue.


    I can build a PS/2 connector test jig to test the idea of a wire being disconnected or high resistance at power-up,

    and we should see a similar 'odd' behaviour, though I can't imagine such a mechanism.
    That doesn't mean that all of reality is within the scope of my imagination. Testing is better.


    Right now...I'm thinking:
    Either this mouse is very sensitive to the PS/2 supply voltage requirement of +4.5V <> +5.5V
    It's cord is extra thin, so it may suffer meaningful voltage loss over 30AWG wires and the Amiga's 4.7R internal resistance.
    So maybe it's not POR'ing correctly ?
    Or...

    It 'needs something' at power-on \ initialization that it's not getting from Micromys V5.

    and as a result it's sending back data that makes no sense, or is not synchronizing with the Micromys V5.


    Found someone online talking about the trouble they have had with ensuring that their PS/2 mouse driver is synchronized with their mouse:
    "The trick i found to fix this is to use the fact that byte 0 is supposed to have bit 3 always set. So when i receive a byte that is supposed to be #0 with bit 3 cleared, i simply discard it and assume byte 0 will come next. As long as you're on synch, this is completely transparent, and when the mouse comes out of synch, only a few events are sufficient to restore synchronization (especially fast with steady clicks)"


    Not aware of what Micromys V5 does to detect and correct out of sync condition, or if it uses PS/2 mouse streaming or a different mode of operation.

  • We use both modes; packet-based on startup to get the state of the mouse buttons (so early startup will work), and then switch to streaming mode. Prior to V5, there was only streaming mode, which was inconvenient for entering early startup: You had to move the mouse constantly to ensure you're really transferring the buttons as well.


    Extremely thin wires cause crosstalk on the signal wires, which can cause false bits to arrive at the adapter. Micromys shifts the sample-spot of the data line away from the clock transition, which vastly improves it's immunity against such extremely cheap cables.


    So maybe it's not POR'ing correctly ?

    Hard to believe; a mouse has a micro controller, and these are mostly "wide input" in terms of power. Even if they are pure 5V types, these start working at 3.8V if made in the most popular 5V-tolerant process that TSMC offers (and you may know that TSMC has half of the world's market share for this type of semiconductor). The more likely scenario is that they are "wide voltage" types, so they start working at 2.1V (though at a lower frequency), have their recommended voltage at 3.3V, but are spec'd to tolerate up to 6V.


    but it's three months old, the problem's been there since it was bought new.

    So statistically, lower probability of a wear-out, though still fully possible, bath-tub curve and all that.

    How about just opening the mouse, see if you can find a cold solder joint? After all, it's probably China-made and only went through a very basic QA procedure (if at all).

  • I started with a good old probing of the solder joints back to the PS/2 connector, looking for shorts or breaks in the cheap wire.


    For sure this mouse is made in China, like 80%+ of all electronic goods.
    China is the worlds 'preferred' factory and they have the greatest collective manufacturing experience of any nation.
    But we can all pretend, I guess, that only badly made things come from there, if that smoothes over our egos. :)


    It uses the dirt cheap KA2B optical sensor, which complies with the following spec:


    Absolute Max is also 5.5V

    It has a built-in regulator with 3.6V I/O output, so it may not like being voltage starved, like some of iComp's own devices.


    POR is not specific to micro controllers...

    Your FPGA NOR configurator, NAND flash and DRAM all have POR circuitry, as will this optical mouse chip.


    I'll keep digging until I have a believable failure mechanism.
    I'm not confident this mouse is innocent, heck, that optical chip sells for $0.10 in low volumes, so we know how much testing it got and the mouse assembly is about $20, so we know how much testing the whole system got. But that does not mean it's defective, just not vetted, and it can be tested in the field.

    I would, at the very least, like to save others from buying a widely available PS/2 mouse on Amazon,

    if it's going to cause them the very same grief.


    I assume you'd like to save your customers the same.
    So, I'll stay on it for a bit, see if I can root cause it.

  • It uses the dirt cheap KA2B optical sensor, which complies with the following spec:

    Tried to find the data sheet to see if there's anything "between the lines" for this thing, but everything I find is trading companied wanting to sell the chip, empty PCBs and (if you're lucky) the plastic part that's needed for proper lighting. In other words: My Google-fu is not strong enough. Feel free to upload the datasheet here - maybe I'll spot something.


    BTW, I'm not ranting against making things in China. I do the same, but I make sure that all involved people are getting paid properly. After all, you need to keep your partners happy, and pushing down prices like many western buyers do will result in the general perceptiopn of "China can do everything cheaper and worse". The truth is that you get what you pay for.


    I'd totally trust a semiconductor for 10 cents, as testing chips is fully automated these days. However, a single-sided PCB is most likely not tested, and with lead-free soldering still a challenge (especially when trying to do this on older machines that can't be flooded with nitrogen), you may get whiskers between the pins, small enough to be invisible to the untrained eye, but large enough to cause trouble.