VMWare guest suddenly can't ping host (but can reach LAN/WAN) - SOLVED! (Linux VM on Windows 7 host)

Scenario:

1. Laptop running VMWare, single Gig-E port on laptop onto LAN/WAN. The usual.
2. VMWare setup working fine since forever, VMs bridged to LAN and hence work like an independent network interface with their own MAC/IP etc. Yay.
3. Suddenly one day out of the blue the fecking thing only half-works; 
1. the VM can reach the LAN and internet 
2. Other boxes on the  LAN can reach the VM just fine
3. ...but the VM can't ping/etc the host machine, or vice versa.
4. W.T.F!? Has worked since forever!

SOLUTION:

Running Wireshark (or similar network sniffer) switches the gig-e interface into promiscuous (i.e. not MAC-filtered) mode, which is all fine and dandy, and when capture stops, as you'd expect, Wireshark switches it off again...

If you run arping from the VM to the host, it fails, but it starts working as soon as you begin packet capture in wireshark - and stops as soon as you stop..

It appears (which is somewhat logical) that VMWare lan bridge stuff requires the i/f in promiscuous mode and Wireshark turning it off at the end of a capture breaks the connectivity from VM to host somehow.

Solution: After using wireshark, in the Windows network adapter panel, disable and re-enable the interface. This resets it back to a fully working (with VMWare) condition.

If that stopped you screaming at your computer - you're welcome!

DFPlayer MP3 module - high quiescent power consumption and clicks when power applied and removed - FIX!

The DFPlayer is a great little MP3 player module at a fantastic price, but there's a really odd design choice; it has a high quiescent current of about 25ma, requiring you to cut the power to it with a PFET when not in use, and, worse, it suffers from power on/off clicks when you do that.

The schematic of the module is basically the reference design from here (the mp3 player chip vendor's page)

http://www.yxin18.com/kp/2015102450.html

and they're using a bog-standard no-name 8-pin 8002 audio amplifier chip (in this case a class AB one, not a PAM8002 which is class D, but hey, the whole board costs about a buck), anyway it's a BTL amplifier, so + and - are both floating at VCC/2 when no sound is playing.

This requires the amp to put a little care into avoiding pops/clicks when power is applied and removed, and the 8002 designers kinda did this already; here's a generic 8002 amp datasheet;

http://thaieasyelec.com/downloads/EFDV308/HXJ8002_Miniature_Audio_Amplifier_Datasheet.pdf

They have both a SHUTDOWN pin and a bias cap so that the speaker ramps up and down subsonically... 

Anyway looking at the DFPlayer board I see they just have the SHUTDOWN pin (pin 1) wired to GND, i.e. always-on, via a 0-ohm resistor (if you look next to pin 1 on the 8-pin chip on a generic DFPlayer module, there's a "000" resistor next to it).

What's totally bizarre is that the MP3 player chip is set up to output a "BUSY/IDLE" signal (comes out on pin 1 of the DFPlayer module) which is the right polarity and basically ideal to drive the SHUTDOWN on the 8002 amplifer.

..and lo and behold, if you pull off the 0-ohm resistor and wire pin 1 of the 8002 straight to the BUSY output pin of the module - you get a double win - no more power on/off clicks at all (now totally silent) AND halves the quiescent power consumption of the module (takes about 10mA off it).

WTF? No idea why they didn't do this... Anyway, there's your easy fix...  now you can gate the power to the entire module (still necessary, it sucks down >10ma even when not doing anything) but at least it doesn't click when you do it....

EDIT: Aaaaahhh.. they did, it's an option. Looking at the underside of the board there's  unpopulated pads opposite the 0R resistor; remove the 0R and put it on the other pads and it connects SHUTDOWN to BUSY :-)

DFPlayer MP3 module - high quiescent power consumption and clicks when power applied and removed - FIX!

The DFPlayer is a great little MP3 player module at a fantastic price, but there's a really odd design choice; it has a high quiescent current of about 25ma, requiring you to cut the power to it with a PFET when not in use, and, worse, it suffers from power on/off clicks when you do that.

The schematic of the module is basically the reference design from here (the mp3 player chip vendor's page)

http://www.yxin18.com/kp/2015102450.html

and they're using a bog-standard no-name 8-pin 8002 audio amplifier chip (in this case a class AB one, not a PAM8002 which is class D, but hey, the whole board costs about a buck), anyway it's a BTL amplifier, so + and - are both floating at VCC/2 when no sound is playing.

This requires the amp to put a little care into avoiding pops/clicks when power is applied and removed, and the 8002 designers kinda did this already; here's a generic 8002 amp datasheet;

http://thaieasyelec.com/downloads/EFDV308/HXJ8002_Miniature_Audio_Amplifier_Datasheet.pdf

They have both a SHUTDOWN pin and a bias cap so that the speaker ramps up and down subsonically... 

Anyway looking at the DFPlayer board I see they just have the SHUTDOWN pin (pin 1) wired to GND, i.e. always-on, via a 0-ohm resistor (if you look next to pin 1 on the 8-pin chip on a generic DFPlayer module, there's a "000" resistor next to it).

What's totally bizarre is that the MP3 player chip is set up to output a "BUSY/IDLE" signal (comes out on pin 1 of the DFPlayer module) which is the right polarity and basically ideal to drive the SHUTDOWN on the 8002 amplifer.

..and lo and behold, if you pull off the 0-ohm resistor and wire pin 1 of the 8002 straight to the BUSY output pin of the module - you get a double win - no more power on/off clicks at all (now totally silent) AND halves the quiescent power consumption of the module (takes about 10mA off it).

WTF? No idea why they didn't do this... Anyway, there's your easy fix...  now you can gate the power to the entire module (still necessary, it sucks down >10ma even when not doing anything) but at least it doesn't click when you do it....

Seriously optimizing power consumption on a STM8F103F3P6 "minimum system board"

You know, these things, they're all over EBay

Anyway, when running off 3.3v (not using the USB connector) and putting them into the lowest power mode I could find (ACTIVE-HALT using the AWU to wake it up once a second) I was still seeing several milliamps power consumption; was expecting a hundred microamps or thereabouts;

To achieve this;
a) (Obviously) Remove the "PWR" led (or take off the resistor on the underside) to save a few mA
b) Remove the 3.3v regulator(!!) this was the main problem; was leaking about 2.2mA when back-powered with 3.3v

Down to about 178uA now (with internal main voltage regulator (MVR) on) running off internal LSI clock, which is nicely just under the datasheet's quoted 200uA.

With the MVR off in halt and the flash powered down (and again waiting up with AWU at 1hz to do practically nothing), i.e.
FLASH_SetLowPowerMode(FLASH_LPMODE_POWERDOWN);
CLK_SlowActiveHaltWakeUpCmd(ENABLE);

we're down to 38uA!!! Sweeeet!

Found: bug in Tinysidplay V0.94 playing Martin Galway music (and others probably)

Bug in TinySidPlay 0.94

The linux source for this version comes with a .CPP version and a separate .C version (the latter is what the makefile uses). There's a couple of glaring bugs in the 6510 emu which means it can't play several bits of music, e.g. Martin Galway's stuff.  This is fixed in the CPP version but it's hard to spot;
the error is in the "CPX" and "CPY" instruction emulations in sidengine.c;

at both "case cpx:" and " case cpy:" (around line 950ish) the "setflags(FLAG_C, a >= bval);" is setting the carry flag based on comparing with A not X, so change it to
setflags(FLAG_C, x >= bval);
..same with "cpy" just below it, change to
setflags(FLAG_C, y >= bval);

and workie!

Modifying YDS-812 buck converters

These buck converters are great; readily available on Ebay for about $4 a pop.


Wins:

• Well heatsinked, well made
• Synchronous  for higher efficiency
• Easily modified in useful ways

Official datasheet is here - however practical experience actually you can ignore quite a lot of it :-)

The over-current shutdown doesn't seem to work very well (I pulled 13A @ 5v out of one) and the minimum voltage spec is also pessimistic - when modded you can run them on lower voltage inputs. YMMV of course.

The main control chip is the Texas Instruments LM2727

The fets are 52N06 fets

Firstly; you MUST add electrolytic capacitors on the input and outputs or they just don't work; I put e.g. 1000uf (e.g. 35v) on the input and 2500uf on the output. You should use low-ESR caps.

Adjusting output voltage

On the PCB, VR1 is 1k,  VR2 is composed of an 18k (on the left) and a 1k (right) in series = 19k.

The controller wants to see 0.6v on the FB input, so the default divider values of 1k & 19k gives you 

12v 'input' (buck output) = 0.6v output (feedback to chip). 

The resistor divider calc is of course (19k+1k)/1k * 0.6v =12v at Vout  

When modding this board for lower voltage output I find it easiest to piggyback an extra 0402 resistor on top of the 18k one 

Here's the datasheet sample schematic that roughly matches what we have on the board (minus the 5v regulator, FET driver and other bits and pieces)...

Soft on/off

The transistor just above VR1 on the board is an internal on/off switch (not sure when it's used), but if you solder a wire onto the right hand side pin of it (according to the above pic) you get access to /SD; pull this low and the buck switches off.  Note it has an extremely weak (microamps) 5v pullup on-chip.

How to fix Crucial V4 SSD I/O errors

I use a 32GB Crucial V4 SSD for the OS drive of my home theater PC; it's not a great drive but it works.. well, up until today, when an unexpected powerdown corrupted it. I tried to reimage the drive (I use "DD" under linux) but I got a bunch of IO errors writing to the SSD. DOH!  Normally I'd bin the drive and buy another one (hint; not a Crucial drive) but this time I found a fix...

If you re-flash the drive's firmware (using the bootable usb stick image found here ) it cautions in the docs here "!ALL DATA WILL BE LOST!"   ...well, y'know actually that sounds ideal...

And lo! Even though my drive was already running the latest firmware, the tool allows you to reflash it anyway, and bingo - twenty seconds later a completely blank SSD with no hard errors.

Happy new year!