Skip navigation
> RoadTest Reviews

MPS Four-Channel Output Power Module EVM - Review

Scoring

Product Performed to Expectations: 7
Specifications were sufficient to design with: 5
Demo Software was of good quality: 8
Product was easy to use: 8
Support materials were available: 7
The price to performance ratio was good: 7
TotalScore: 42 / 60
  • RoadTest: MPS Four-Channel Output Power Module EVM
  • Buy Now
  • Evaluation Type: Development Boards & Tools
  • Was everything in the box required?: Yes
  • Comparable Products/Other parts you considered: I don't really have anything else to compare it to.
  • What were the biggest problems encountered?: There were several bugs in the Virtual Bench Pro software where the values shown did not match those in the datasheet. The datasheet was missing elements from its block diagram, and did not warn about the potential for reverse leakage current when using the discharge function. The sections of the datasheet describing I2C and MTP registers were rather disorganised and resulted in a lot of scrolling around looking for what I needed. The chip's requirement of strobing EN low when switching between individual and parallel mode was a significant problem for the project I had in mind.

  • Detailed Review:

    One of my long-term electronics projects involves driving an array of addressable LEDs on a long cylinder. The driver electronics and power supplies have to fit inside the cylinder, which is quite a challenge both in terms of physical size and thermals. The only 250W 5V power supplies that'll fit into the space are prohibitively expensive and require force air cooling. Instead, I'm planning to use five Meanwell IRM-60-5 supplies, each providing 10A, in parallel using an N+1 load-sharing topology. The total cost of the supplies is around £150, plus the added costs of the load-sharing board, but the total cost is still far lower than a single larger supply in an equivalent form factor.

     

    One major benefit of this approach is efficiency. You might think that using more supplies would be less efficient, due to any quiescent current being multiplied by five, but in practice it actually ends up being significantly more efficient. The reason for this is the SMPS efficiency curve. A typical SMPS doesn't achieve its rated efficiency until you apply 50% of its rated maximum load, and the efficiency in the bottom 10% of the range can be as low as 50%. This is a problem if the ratio between your system's average load and its peak load is very high - if you need 50A peak, but only 2-5A average, you're spending most of your time in the low-efficiency region of the curve. If you use multiple supplies in parallel, and dynamically switch them on and off, you can push more load onto fewer supplies for greater efficiency. In addition, if your supply's efficiency tapers off a little toward the top end of the graph, you can bring more supplies online to bring the load back into the most efficient region.

     

    The following graph of a fictitious power supply's efficiency curve demonstrates the concept in a 1+1 configuration.

    The red line represents the efficiency of the supply. The blue line in the center represents the peak efficiency, in this case around 89.5%. The blue shaded region to the left and the yellow shaded region to the right represent the areas in which switching between one supply and two supplies makes sense. If two supplies are running in parallel and the resultant load on each supply is below around 22.5%, one of those supplies should be turned off in order to apply twice the load to one supply, shifting us closer to the 45% mark where efficiency is highest. If one supply is running and the load on that supply exceeds 80%, a second supply should be switched on so that both supplies are around 40-50% loaded.

     

    To demonstrate, consider the following four scenarios:

     

    The first row represents 10% load, and the bottom row represents 45% load. The left column represents the lower efficiency configuration, and the right column represents the higher efficiency configuration. As you can see, the efficiency gains are significant, even in the high load scenario where there's less of an impact.

     

    The downside of the approach is complexity. There are a lot more parts involved, and considerations to be made. A key requirement for taking this approach is the ability to predict and/or control load. If your system goes from pulling 5A to 45A in the space of a few milliseconds, and you don't know that it's about to happen, you're going to massively overload your supplies. There are two mitigation approaches here: predictive and reactive. If your system has deterministic behaviour that you can plan for, you can spin up additional supplies just in time for the load spike. If your system has some mechanism by which you can reduce power draw, you can react to overcurrent events and apply a temporary limit until more supplies come online. Luckily, my project fits both of these profiles - I can precompute displayed effects to predict the power requirements ahead of time, and I can use adaptive dimming to compensate for any overshoot.

     

    While I did independently invent this trick, it isn't new. Some blade server solutions utilise this approach to increase efficiency when the servers aren't running at high demand, utilising integrated power management features on the CPU and PCH (via PMBus) to apply temporary throttling at the rising edge of load spikes. This discovery was quite welcome because it validated my assumptions.

     

    Building a system like this to prototype with is expensive and daunting. I've been designing the circuits and PCBs for a year or two now, but never got around to practical experimentation because of the upfront cost and physical footprint. A month or so back, I stumbled across Element14's Road Test program, which provides reviewers with free parts and equipment in return for a public review. Coincidentally, one of the items up for grabs was a development board for Monolithic Power Systems' new MPM54304 quad-output step-down SMPS module. This caught my eye because each pair of outputs can be paralleled together for increased power output. The key specs are as follows:

     

    • 4V to 16V DC input
    • 0.55V to 5.4V DC output
    • 3A per channel on channels 1&2, 6A in parallel
    • 2A per channel on channels 3&4, 4A in parallel
    • Fully I2C programmable
    • Configurable switching frequency and phase
    • Single-chip design with integrated inductors

     

    The datasheet also helpfully includes efficiency curves vs. load current for a range of input and output voltages.

     

    I applied for the road test and was accepted. Element14 sent me the EVM54304-MN-01A development board and an EVKT-USB2IC-02 adapter that allows the board to be configured with MPS's Virtual Bench Pro software.

     

     

    Getting it up and working was easy. I connected the USB adapter to the PMBus (I2C) header on the board, hooked up a 12V supply, switched it on, and picked the MPM54304 with its default address in the software. It presented me with all the settings I needed.

     

    Each buck converter has an independently configurable voltage reference, from 550mV to 1820mV in 10mV increments. This reference can be used directly, or it can be used with a 1/3 feedback option to multiply the output voltage by 3, giving you an output voltage between 1.65V and 5.46V in increments of 30mV. In addition to the voltage, you can set a phase delay of 0, 90, 180, or 270 degrees, which is useful in a parallel configuration. The buck converters can be independently switched on and off, too.

     

    An interesting feature of the device is that it contains two-time writable non-volatile memory for its configuration. Normally, when you configure the device over I2C, the settings are lost when you power it down. However, you can send a command to the device to write the current configuration to non-volatile memory, and the configuration will be remembered at power-up. This is helpful if you don't want to include a microcontroller on your board to configure the I2C at runtime - you can flash the settings at manufacturing time, and it'll remember them. The datasheet calls this non-volatile storage an MTP e-fuse, although calling it "multi-time programmable" seems a bit rich for something you can only program twice. Still, twice is better than once or not at all.

     

    You can configure 32 different I2C addresses via the I2C bus itself, and it'll switch to that address immediately. You can then store that to MTP, so you don't need external address selection parts after programming. If you'd prefer to use hardware address configuration, you can still do so with a voltage divider..

     

    The chip has a multi-function GPIO pin. The default mode is ADD, which allows you to set the device address to 0x68, 0x69, 0x6A, or 0x6B depending on the voltage applied. You can change the mode with I2C and MTP. In PG mode the pin goes high when all four buck converters are emitting a power good signal. In OP (output) mode you can program the pin to output high or low based on a register. In SYNCOUT mode the device outputs a 50% duty cycle synchronisation pulse that can be used to sync other switching supplies to the same phase. All in all, it's quite capable.

     

    I started by testing the device's performance under various loads. The following graph shows the frequency spectrum while the device is configured at Vout=4.5V and a switching frequency of 533kHz, while under only 20mA of load. This is a poor configuration, since at that low load you ideally want a higher switching frequency, but I wanted to see what it looked like when things were sub-optimal.

     

     

    All in all, it's not bad at all. You can clearly see spikes at the switching frequency and its harmonics, but they're under 10mV. Bumping the switching frequency to the maximum of 1.6MHz drops all harmonics below the -70dBu noise floor, leaving only a single peak at the fundamental - barely 3.5mV.

     

    This is all fine and good, but what's it like when you really push it? Outputting 5.46V at 3.15A - exceeding the rated maximum current by 150mA - demonstrates why they include the lower switching frequencies. At fs=1.6MHz I saw 800mV of droop on the output, which is clearly problematic. Dropping it down to 533kHz, the voltage is rock steady, but the noise is nowhere near as good.

     

     

    The noise at the fundamental reaches 35mV, although it's a bit jumpy and averages around 15mV. Below 700kHz, excluding the fundamental, the noise is under 5mV. The noise floor is raised up a fair bit, from around 250μV to around 700μV, but that's still in the realm of being purely academic if you're planning on pushing a buck converter that hard.

     

    This testing wasn't super precise - I just bodged up some high-power ceramic resistors together to act as a load. I do have a programmable load, but I was quickly testing this on my desk and there wasn't space for it.

     

     

    One thing I did notice, during experimentation, was that the over-current protection feature (OCP) didn't work as expected. It didn't seem to be taking any action when I was applying a high load to the buck converter.

     

    Each buck converter has four options for over current limiting in the Virtual Bench Pro software:

    However, no matter what I tried, I couldn't get OCP to kick in - even when pushing the channel beyond 3A, above its maximum rating. What confused me even further is that the datasheet doesn't match the software:

    The software options don't really make any sense, since the numbers are per-buck and 7A output isn't possible even with channels 1 and 2 in parallel. I suspect that the datasheet is closer to the truth, but the fact that OCP didn't kick in at 3.2A with D[5:4] set to 00 makes me question whether something else is missing. The datasheet's description of the functionality is a little confusing, and the description of the undervoltage protection is lacking detail (e.g. it says that undervoltage is measured at Vref, but doesn't explain the behaviour when 1/3 feedback is used), making it hard to figure out what's going on. It also doesn't help that the PG signal logic for each buck is missing from the block diagram. I passed this feedback to Element14 along with some questions, in the hopes of getting some clarification. I eventually did get some clarification - the datasheet is right and the software is wrong - but ultimately I didn't have time to investigate the OCP any further.

     

    Luckily I don't need the current limiting for this project, but it'd be nice to see MPS improve their datasheets to include more practical details about OCP behaviour, whether or not OCP is dependent on GPIO configuration, whether UVP uses the scaled or pre-scaled Vref when 1/3 feed is in use, how PG signals are generated from each buck, and what "Ref0" is in the block diagram.

     

    Next on the agenda is the actual experiment. The setup is quite simple: measure the power going into the MPM54304, and the power coming out of each buck converter, then control the MPM54304 based on that.

     

    The overall setup is roughly as follows:

     

    The ESP32 is just for convenience, since I have a ton of them - you could easily use any other microcontroller, or even a generic I2C-to-USB interface if you wanted to do everything in software.

     

    One slight problem was that the INA219 breakout boards I had on hand were limited to 3.2A. This is because they come with 100mΩ shunt resistors as standard, and the maximum measurement range of the INA219 is 320mV with its inbuilt PGA set to divide by 8. This isn't ideal for a few reasons. First, 320mV is a huge drop - it complicates my calculations and means each shunt is dissipating 900mW at 3A, which is close to the 1W maximum rating. The resistors heating up would then cause some additional skew in the measurements. Setting the PGA to /8 also reduces the accuracy of the INA219, adding between 30μV and 190μV of measurement offset. Additionally, 3.2A doesn't give enough headroom if I want to combine the two buck outputs before the current measurement, where I'd need to measure 6A or more. Even if all that weren't enough, putting 200mΩ of resistance in the path between the two parallel buck converters is unlikely to produce healthy results from the MPM54304.

     

    Luckily, the solution is trivial: change the resistance.

     

    Adding an additional 10mΩ shunt resistor in parallel with each board's 100mΩ shunt gives a resultant resistance of 9.1mΩ, which means I can measure up to 4.4A with the PGA disabled (40mV range), or 8.8A range with the PGA set to /2. Since the INA219 offers 12-bit resolution, that gives an LSB of around 1.07mA or 2.15mA respectively - more than enough resolution for my needs. Having the much lower voltage drop also means I can effectively ignore any impact the shunt resistor might have. I could've gone with 10mΩ on its own, instead of the parallel pair, but I didn't want to risk lifting pads on these extremely cheap PCBs, and 0.9mΩ doesn't really make any practical difference.

     

    Connecting everything together in the manner described above lead to a frustrating problem: when I disabled one of the two supplies in the MPM54304 but left the outputs connected together, a significant leakage current (100-300mA) flowed back through the disabled output. Looking at the block diagram from the datasheet, there was no obvious cause.

    After some very annoyed troubleshooting and some venting on Twitter, @RalimTek pointed out that the MPM54304 has a programmable discharge function. This isn't shown in the block diagram. If you dig further through the datasheet, you'll find this paragraph:

     

    Output Discharge
    In order to discharge the energy of the output capacitor during the shutdown sequence, there are discharge resistors (typically 45Ω) from the SWx pin to ground. The discharge function can be enabled or disabled through the I2C and MTP interface.

    The applicability of this isn't immediately obvious if you're just searching for issues relating to VOUT, because the SWx pins aren't necessarily something you'd be thinking about. However, when the discharge function is enabled, the IC connects a 45Ω resistor between SWx and GND, which creates a path from VOUTx to GND through the internal inductor. This was the source of the leakage. Disabling this by setting VOUT_DIS_ENx to 0 fixed the problem.

    At this point I was ready to graduate away from the Virtual Bench Pro software and write my own library. The I2C interface for the device is simple enough - it uses a fairly typical register model. To read a register, you send its 8-bit address and then read back one byte of content. To write a register, you send its address followed by a byte of data. If you send multiple bytes of data in a single write transaction, the device automatically increments the write pointer, skipping read-only registers.

     

    The register layout is quite simple, although the layout of the datasheet means you end up jumping around a bit for reference. Each buck converter has three config registers, starting at 0x00-0x02 for buck 1, then 0x03-0x05 for buck 2, and continuing in that fashion. After the buck config, there's a larger system config and status block, starting at register 0x0C. These registers can be easily manipulated in C/C++ using bitfields in structs.

     

    A similar set of registers, starting at address 0x40, is used for MTP programming. This replicates the buck config layout, along with a slightly modified version of the system config registers. For some reason, though, the datasheet has the MTP table first, then a section explaining all the fields, then the table showing the normal config and status registers, and finally a section describing just the fields that were different from the MTP block. This feels backwards, and it resulted in me scrolling back up and down a lot, getting a bit lost.

     

    I think the datasheet layout could be improved a fair bit, with a single table showing the I2C and MTP addresses for the shared fields, to save getting lost in the document. For example:

     

    The couple of registers that aren't shared across I2C and MTP could then be documented in smaller separate tables below, followed by a full explanation of all the register fields. That keeps everything together and flows nicely.

     

    Anyway, weird documentation layout aside, I wrote an MPM54304 Arduino library and released it under MIT license. It supports runtime configuration of the device, but does not support any of the MTP functions. Pull requests welcome if you want to implement the MTP stuff yourself.

     

     

    The library has a familiar API interface for anyone who's used Arduino libraries before:

     

    MPM54304* mpm54304;
    mpm54304 = new MPM54304(0x68);
    mpm54304->begin();
    
    // fetch the config from the device
    mpm54304->update();
    
    // turn buck 1 and 2 on, and enable parallel supplies
    mpm54304->enableParallelBuck12();
    mpm54304->enableBuck(MPM54304_BUCK1);
    mpm54304->enableBuck(MPM54304_BUCK2);
    mpm54304->disableBuck(MPM54304_BUCK3);
    mpm54304->disableBuck(MPM54304_BUCK4);
    
    // use the OP pin as GPIO
    mpm54304->setOutputPinFunction(MPM54304_OUTPUT_PIN_GPIO);
    
    for (uint8_t i = 0; i < 4; i++)
    {
         mpm54304->setOverVoltageProtectionEnable(i, true);
         mpm54304->setVoltageOutLimitEnable(i, false);
         mpm54304->setOutputVoltage(i, 5.0);
         mpm54304->setSoftStartTime(i, MPM54304_SLEW_RATE_1000uV);
         mpm54304->setCurrentLimit(i, MPM54304_CURRENT_LIMIT_4A_VALLEY_3A_OUTPUT);
    }
    
    // update changed registers and read the new config back
    if (!mpm54304->update())
    {
         Serial.print("Update failed! Status: ");
         Serial.println(mpm54304->getLastI2CStatus(), HEX);
    }
    
    // print the config to the serial port
    mpm54304->printConfig();

     

    There's more information about the full API in the readme on the GitHub repo.

     

    The printed config output looks something like this:

     

    Configuration for MPM54304 device at address 0x68
    
    SYSTEM CONFIG:
    MPM54304_SYSTEM_CONFIG.Reg0x0C = 0xC3
    MPM54304_SYSTEM_CONFIG.EnableBuck1 = true
    MPM54304_SYSTEM_CONFIG.EnableBuck2 = true
    MPM54304_SYSTEM_CONFIG.EnableBuck3 = false
    MPM54304_SYSTEM_CONFIG.EnableBuck4 = false
    MPM54304_SYSTEM_CONFIG.UnderVoltageThreshold = MPM54304_UVLO_THRESHOLD_4500mV
    MPM54304_SYSTEM_CONFIG.OutputPinGPIOState = MPM54304_OP_GPIO_STATE_OPEN_DRAIN
    MPM54304_SYSTEM_CONFIG.Reg0x0D = 0x68
    MPM54304_SYSTEM_CONFIG.SwitchingFrequency = MPM54304_SWITCHING_800KHz
    MPM54304_SYSTEM_CONFIG.ShutdownDelayEnable = true
    MPM54304_SYSTEM_CONFIG.I2CAddress = 0x8
    MPM54304_SYSTEM_CONFIG.Reg0x0E = 0x81
    MPM54304_SYSTEM_CONFIG.OutputPinFunction = MPM54304_OUTPUT_PIN_GPIO
    MPM54304_SYSTEM_CONFIG.MTPProgram = false
    MPM54304_SYSTEM_CONFIG.PowerGoodDelay = MPM54304_PG_DELAY_200us
    MPM54304_SYSTEM_CONFIG.ParallelBuck34 = false
    MPM54304_SYSTEM_CONFIG.ParallelBuck12 = true
    MPM54304_SYSTEM_CONFIG.Reg0x0F = 0x0
    MPM54304_SYSTEM_CONFIG.MTPConfigureCode = 0x0
    MPM54304_SYSTEM_CONFIG.Reg0x10 = 0x2
    MPM54304_SYSTEM_CONFIG.MTPRevisionNumber = 0x2
    MPM54304_SYSTEM_CONFIG.Reg0x11 = 0x0
    MPM54304_SYSTEM_CONFIG.MTPProgramPassword = 0x0
    MPM54304_SYSTEM_CONFIG.Reg0x12 = 0xC0
    MPM54304_SYSTEM_CONFIG.PowerGoodBuck1 = true
    MPM54304_SYSTEM_CONFIG.PowerGoodBuck2 = true
    MPM54304_SYSTEM_CONFIG.PowerGoodBuck3 = false
    MPM54304_SYSTEM_CONFIG.PowerGoodBuck4 = false
    MPM54304_SYSTEM_CONFIG.OverTemperatureWarning = false
    MPM54304_SYSTEM_CONFIG.OverTemperatureProtection = false
    MPM54304_SYSTEM_CONFIG.Reg0x13 = 0x81
    MPM54304_SYSTEM_CONFIG.VendorID = 0x8
    MPM54304_SYSTEM_CONFIG.ChecksumFlag = false
    MPM54304_SYSTEM_CONFIG.CurrentMTPPageIndex = 0x1
    
    BUCK 1 CONFIG:
    MPM54304_BUCK_CONFIG.Byte0 = 0x2
    MPM54304_BUCK_CONFIG.SoftStartDelayMillis = 0x0
    MPM54304_BUCK_CONFIG.AdditionalPhaseDelay = false
    MPM54304_BUCK_CONFIG.SoftStartTime = MPM54304_SLEW_RATE_1000uV
    MPM54304_BUCK_CONFIG.Byte1 = 0x68
    MPM54304_BUCK_CONFIG.VoltageOutLimitEnable = false
    MPM54304_BUCK_CONFIG.SwitchingMode = MPM54304_MODE_FORCED_PWM
    MPM54304_BUCK_CONFIG.CurrentLimit = MPM54304_CURRENT_LIMIT_4A_VALLEY_3A_OUTPUT
    MPM54304_BUCK_CONFIG.OverVoltageProtectionEnable = true
    MPM54304_BUCK_CONFIG.PhaseDelay = MPM54304_PHASE_DELAY_0
    MPM54304_BUCK_CONFIG.VoltageOutDischargeEnable = false
    MPM54304_BUCK_CONFIG.Byte2 = 0xF0
    MPM54304_BUCK_CONFIG.FeedbackRatio = MPM54304_FEEDBACK_ONE_THIRD
    MPM54304_BUCK_CONFIG.VoltageReference = 0x70
    
    BUCK 2 CONFIG:
    MPM54304_BUCK_CONFIG.Byte0 = 0x2
    MPM54304_BUCK_CONFIG.SoftStartDelayMillis = 0x0
    MPM54304_BUCK_CONFIG.AdditionalPhaseDelay = false
    MPM54304_BUCK_CONFIG.SoftStartTime = MPM54304_SLEW_RATE_1000uV
    MPM54304_BUCK_CONFIG.Byte1 = 0x68
    MPM54304_BUCK_CONFIG.VoltageOutLimitEnable = false
    MPM54304_BUCK_CONFIG.SwitchingMode = MPM54304_MODE_FORCED_PWM
    MPM54304_BUCK_CONFIG.CurrentLimit = MPM54304_CURRENT_LIMIT_4A_VALLEY_3A_OUTPUT
    MPM54304_BUCK_CONFIG.OverVoltageProtectionEnable = true
    MPM54304_BUCK_CONFIG.PhaseDelay = MPM54304_PHASE_DELAY_0
    MPM54304_BUCK_CONFIG.VoltageOutDischargeEnable = false
    MPM54304_BUCK_CONFIG.Byte2 = 0xF0
    MPM54304_BUCK_CONFIG.FeedbackRatio = MPM54304_FEEDBACK_ONE_THIRD
    MPM54304_BUCK_CONFIG.VoltageReference = 0x70
    
    BUCK 3 CONFIG:
    MPM54304_BUCK_CONFIG.Byte0 = 0x12
    MPM54304_BUCK_CONFIG.SoftStartDelayMillis = 0x1
    MPM54304_BUCK_CONFIG.AdditionalPhaseDelay = false
    MPM54304_BUCK_CONFIG.SoftStartTime = MPM54304_SLEW_RATE_1000uV
    MPM54304_BUCK_CONFIG.Byte1 = 0x6A
    MPM54304_BUCK_CONFIG.VoltageOutLimitEnable = false
    MPM54304_BUCK_CONFIG.SwitchingMode = MPM54304_MODE_FORCED_PWM
    MPM54304_BUCK_CONFIG.CurrentLimit = MPM54304_CURRENT_LIMIT_4A_VALLEY_3A_OUTPUT
    MPM54304_BUCK_CONFIG.OverVoltageProtectionEnable = true
    MPM54304_BUCK_CONFIG.PhaseDelay = MPM54304_PHASE_DELAY_90
    MPM54304_BUCK_CONFIG.VoltageOutDischargeEnable = false
    MPM54304_BUCK_CONFIG.Byte2 = 0xF0
    MPM54304_BUCK_CONFIG.FeedbackRatio = MPM54304_FEEDBACK_ONE_THIRD
    MPM54304_BUCK_CONFIG.VoltageReference = 0x70
    
    BUCK 4 CONFIG:
    MPM54304_BUCK_CONFIG.Byte0 = 0x2
    MPM54304_BUCK_CONFIG.SoftStartDelayMillis = 0x0
    MPM54304_BUCK_CONFIG.AdditionalPhaseDelay = false
    MPM54304_BUCK_CONFIG.SoftStartTime = MPM54304_SLEW_RATE_1000uV
    MPM54304_BUCK_CONFIG.Byte1 = 0x68
    MPM54304_BUCK_CONFIG.VoltageOutLimitEnable = false
    MPM54304_BUCK_CONFIG.SwitchingMode = MPM54304_MODE_FORCED_PWM
    MPM54304_BUCK_CONFIG.CurrentLimit = MPM54304_CURRENT_LIMIT_4A_VALLEY_3A_OUTPUT
    MPM54304_BUCK_CONFIG.OverVoltageProtectionEnable = true
    MPM54304_BUCK_CONFIG.PhaseDelay = MPM54304_PHASE_DELAY_0
    MPM54304_BUCK_CONFIG.VoltageOutDischargeEnable = false
    MPM54304_BUCK_CONFIG.Byte2 = 0xF0
    MPM54304_BUCK_CONFIG.FeedbackRatio = MPM54304_FEEDBACK_ONE_THIRD
    MPM54304_BUCK_CONFIG.VoltageReference = 0x70

     

     

    This makes it nice and easy to debug things and see the exact configuration status of the device - including the raw register bytes. This actually ended up with me finding a bug in the Virtual Bench Pro software: the Power Good Delay dropdown incorrectly shows only four options, with 0b000 as 5ms and 0b001 missing. The datasheet has the correct options: 0b000 is 200us, and 0b001 is 5ms.

     

    During development I also identified an omission in my design, relating to the behaviour of the parallel options. The datasheet has this to say, in a footnote:

     

    The parallel mode must be programmed before pulling the EN/SYNCI pin to logic high.

     

    What this means in practice is that EN must be strobed low in order to reflect the newly configured value. The device cannot switch from individual to parallel operation, or vice versa, without interrupting the supply. This is unfortunately, a deal-breaker for my project. Without uninterrupted power during the switchover, it isn't really feasible to implement the kind of dynamic switching between individual and parallel supplies that I had intended. While the strobing can be applied to EN quite quickly, in practice I found that at least 500us passed without output power during the swapover. This might not be a problem if you've got enough output capacitance, but at several amps that's unlikely.

     

    If you don't have this type of restriction in your design, but you still want to be able to switch between parallel and individual supplies, there is a silver lining: you don't need to waste a GPIO on your microcontroller to handle the EN pulsing - you can configure the OP pin on the MPM54304 to operate in GPIO mode, and use that to drive the EN pin low. On the development board this is as easy as connecting the EN and GPIO pins together, since the EN switch applies a pull-up resistor.

     

    It's a shame that ultimately this part didn't work out for my project, but it was interesting to investigate and at least I ended up writing an Arduino library for it. Thanks to Element14 and MPS for providing me with this to test.


Comments

Also Enrolling

Enrollment Closes: Oct 1 
Enroll
Enrollment Closes: Oct 18 
Enroll
Enrollment Closes: Oct 1 
Enroll
Enrollment Closes: Oct 9 
Enroll
Enrollment Closes: Oct 4 
Enroll