|Product Performed to Expectations:||6|
|Specifications were sufficient to design with:||5|
|Demo Software was of good quality:||7|
|Product was easy to use:||7|
|Support materials were available:||4|
|The price to performance ratio was good:||8|
|TotalScore:||37 / 60|
Infineon 3-Phase Motor Drive Evaluation Board with FOC Sensorless Control (EVAL_DRIVE_3PH_PFD7) RoadTest
By Gough Lui – June-September 2021
My thanks to element14 and Infineon for selecting me for this RoadTest. I will start off by admitting that I am no expert in motor drives and applied for this RoadTest out of interest. Being suitably equipped with test equipment, I thought I would be able to learn a lot from this kit.
Sensorless three-phase permanent-magnet synchronous motor control is appealing because it reduces the complexity and bill-of-materials for a given system. This makes sense especially in lower-powered consumer applications where cost and performance are key parameters. Getting started and doing this well has not always been easy. A sensorless field-oriented control system might traditionally be implemented using some code running on a powerful microcontroller with a high-speed ADC and necessary support components (like that suggested by the Renesas SH7086 Application Notes and NXP K60 reference design); or have some of those components already pre-populated (as in the NXP KEA128 reference design). But such designs often require additional components to ready them for evaluation, can become quite messy to debug and difficult to optimise.
The allure of the Infineon iMOTION Digital Motor Controller family and its many evaluation boards is the tight integration of the controller software, hardware and driver components. They have a range of evaluation boards, some of which are full-solutions, others which are controller/driver only to be paired with a suitable inverter board, which allows for a lot of flexibility when evaluating their solution, reducing the amount of effort needed to get started while also ensuring safety with a number of protections available out-of-the-box. The MCEWizard and MCEDesigner software that supports these controllers and iMOTION-LINK connectivity allows for a more streamlined programming, tuning and debugging experience with integrated oscilloscope-like views. These all seemed very appealing to a novice such as myself, although perhaps not entirely unique as the NXP MCAT Tool also seems to offer similar features.
The particular board that is the subject of this RoadTest review is the EVAL_DRIVE_3PH_PFD7, a board built around an IMC101T-038 iMOTION microcontroller, supported by the 2ED28073J06F 600V EiceDRIVER™ half-bridge gate driver IC and the IPN60R1K5PFD7S 600V CoolMOS™ MOSFET after which this board takes its catchy name. This board supports the running of motors with up to 825mA current per leg – in our case, we have been supplied with an EBM-Papst A2D200-AA02-01 75W axial fan motor. To interface with the evaluation board, an XMC Link has also been provided.
I apologise that this review has taken longer than usual to deliver – an extension on the RoadTest time-frame was given due to a number of issues which were encountered that will be mentioned later in this RoadTest review. If you found this review interesting, useful, informative or helpful, please leave a like, rating, share or bookmark this review. If you have any questions or ideas, please leave a comment.
The evaluation board arrives in a small, thin, matte-finish colour cardboard box with some rather nice graphics and a short listing of components and specifications. Opening the box, we are given the steps necessary to unlock exclusive materials for the board, which requires the serial number of the kit (and in the fine print, a myInfineon account). The board itself is inside a static-shielding bag surrounded by bubble-wrap for protection in transit.
On top of that is the paperwork, including a test report signed off by the author of the application note for this board. I am surprised this board got out of the door, as the section 3 tests were not verified – note the missing “x” in the Yes column, although passing the latter tests should imply that the board was okay. This seems to suggest there may be a limited quality control process with these evaluation boards. The other documentation provided is a warning with regards to use and design changes. All other documentation needs to be downloaded from the website.
The top-side of the board is shown above. The board itself is somewhat unusually shaped, with parts taken out of the corners as if it were intended to slot into an enclosure with corner posts. As it sits on the desk, it seems a bit bare and perhaps even slightly dangerous as there is nothing to prop it up off the bench and components are populated on both sides.
The blue-coloured PCB is a relatively standard two-layer board, but designed with much care to make it compact while also ensuring isolation where necessary with many slots cut into the board. The mains input is made to a quick-disconnect pluggable terminal block, allowing the live and neutral lines to be disconnected. The through-hole marked PG seems to be intended for a protective earth (usually this would be marked PE or GND) which needs to be soldered in. Not allowing it to be interrupted is perhaps a good safety feature, however, it seems the only things that use the connection are a pair of suppression capacitors. In my case, where I intended to use the board in an isolated setting, I left this connection disconnected.
The input to the board is protected by a slow-blow 3.15A fuse and the input appears to be protected by a MOV, an inrush-current suppressing NTC, suppression capacitors and a common-mode choke line filter. This goes through a bridge rectifier and serves to charge the 100uF 400V-rated DC link capacitor. Aside from this, there is an optoisolator for the OCP, the IMC101T controller (just right of centre) and three half-bridge MOSFET drivers (in the lower third of the image) on this side of the board. This is supported by a number of standard passive components and two LEDs which indicate the status of the controller. The debug connections are made using an 8-pin 2.54mm dual-in-line header on the right edge. An input for voltage speed control is provided, along with 0V and 3.3V connections for easy connection of a potentiometer.
It should be noted that the use of the IMC101T means this board has no power factor correction. While probably not as important for small motor applications, it should be noted that the “bigger brother” IMC102T offers boost and totem-pole PFC capabilities.
Already just upon viewing this board, I have some misgivings about its design. While it is very neat and compact, it does not seem to make sense for evaluation purposes – the three phase outputs (U, V, W) are merely pads with through-hole vias placed somewhere not on the edge of the board. I don’t think it would have been too hard to make it a terminal block or a detachable quick-disconnect terminal block like the mains input – that would add to convenience and safety. Another key observation is the presence of a number of orange-coloured test-points across the board. Some of these test points are low voltage, while others are high voltage, but many of them are situated in close proximity to other test points or connections. Because of the need to use high-voltage differential probes on this board, the connections are not as slender as may be expected from a standard 10:1 oscilloscope probe. The large “clip” connections frequently do not make a mechanically stable connection with these test points and threaten to “flop over” and make contact with something else. See how close the +13V test point is to the neutral mains line and +3.3V test point, for example. This creates some anxieties while trying to perform measurements.
The underside is also populated with components including voltage regulators, the PFD7 MOSFETs, the shunt sensing resistors and over-temperature protection NTC thermistor. Behind the choke, there also seems to be a spark-gap arrangement.
Construction of the board was generally good, with the DC-link capacitor glued to the board for mechanical support. One of the suppression capacitors does not seem to be properly fitted before soldering resulting in a bent leg, but more interestingly, the earth-side connection shares a single hole. It seems this may be potentially improved with a better board design as this is soldered into a long trace leading to the other side of the board where the PG-terminal is marked, but if the protective earth were connected at the pad just adjacent to the capacitors, it may be more effective.
The board itself does not include a debug adapter. While ordinarily, the iMOTION Link is recommended for use with iMOTION controllers, the board is also listed as compatible with the XMC Link which was included for the purposes of this review. This low-cost isolated debug probe provides 1kV of DC isolation for further safety in case of failure of the target board, hopefully keeping the user and equipment safe. It comes packaged in a clamshell plastic package which easily unclips to release the adapter.
The adapter comes with a USB-A to micro-B cable, the debug adapter in its clear housing and two connection cables for the target. One cable is a smaller connector suited for use with many ARM-SWD targets, while the other is a standard 2.54mm dual-in-line connection which is used with this particular board.
The architecture of the XMC Link is clearly seen including the isolation that runs down the middle and the XMC4200 microcontroller that performs the interfacing. The board carries the logo of Samtec and Segger as well. Aside from the two debug ports on one end, the micro-USB connector is on the opposite end.
While the clear case of the unit is rather nifty, its design is perhaps a drawback as the clear bottom plastic plate has a habit of “popping” off the other half of the case, exposing the adapter PCB. If in the unlikely event that the PCB were to fall out of the housing and the target had an insulation failure, the isolation could be violated and damage to people or property could result.
Finally, in order to test the board, we need something to drive. This arrived in a separate box and was quite heavy.
The fan is the ebm-papst A2D200-AA02-01 three-phase AC PMSM axial fan. This unit has metal blades and was a little scratched and beat-up when I received it. The metal fan disk was not entirely straight in alignment, the two balance “clips” suggest it is perhaps also not intrinsically well-balanced. The date code suggests this was manufactured on 17th November (Week 48) of 2020 in Germany.
The motor had five mounting screw holes and because it has very little area to sit on a bench, it really needed a stand for safe operation. The unit came with all windings and earth broken out on separate wires with ferrules. Pairs of wires would have to be combined to form the delta-connection necessary for our evaluation board.
The Infineon EVAL_DRIVE_3PH_PFD7 board webpage hosts downloads including the individual datasheets for Infineon components on the board, application note documents for the board itself, a getting started guide and important safety and operating instructions. Additional software, datasheets, firmware and application notes can be obtained from the iMOTION page.
In order to receive access to all documents and obtain better support, it seems necessary to register a myInfineon account. The process was relatively straightforward until it came time to verify my e-mail address. Despite receiving the e-mail and clicking on the link numerous times, the system still continued to prompt me to activate my account. I had to wait a day or so for it to settle.
The next step is to register the product, and again, here the Infineon systems decided to have problems. I tried registering the product but only received a failure message. Again, it was a case of waiting another day and the issue seems to go away on its own.
For this product, the extra documents you gain access to are the PCB layout and BOM files which is good to have to hand. However, in return, I’ve received numerous e-mails from Infineon about their products … perhaps more than I would have liked.
Getting started with this board requires first breaking out the soldering iron and a scrap piece of three-core wire.
The connections on the board for all three phases are just pads to which wires can be soldered to. Because these also act somewhat as the heatsink for the transistors, it requires a fair amount of heat to achieve a good joint, but it isn’t all that difficult. My first attempt did not last long – I was a victim of some awful copper-clad aluminium wire (thanks China), so I had to redo the connections with a fresh piece of copper cable after they fractured.
The next issue was that of the heavy, metal-bladed fan. I did not fancy having a high-inertia fan on the loose on a bench where it could cause havoc and I could be tempted to “catch” it as it falls off the desk. Ouch!
Instead, I envisioned building a stand for the fan so that it would be suspended in the position it was intended to operate in, with free air access almost all around so that it would operate realistically, but also be held safely in position. The simplest way seemed to be to build a PVC pipe-based structure, so I sketched up a design and went straight to the hardware store, spending about AU$80 in the process. Can’t say I wasn’t invested in this review …
The structure was not perfect, but was adequate for our purposes. I decided the fan would mount on a screw cap, thus making fitment easier but also potentially allowing the stand to be reused in the future.
To mount the fan on the cap, I printed out a scale drawing of the mounting holes through some tweaking in Photoshop, marked the holes and drilled them out.
The maximum screw depth is 5mm, but the hardware shop only had 8mm countersunk screws, so with countersunk washers and the depth of the plastic, we would be able to comply with that requirement. After mounting the fan to the cap, it was screwed onto the stand tightly and a witness mark added to allow for any loosening to be observed.
As each winding of the fan is broken out, pairs of wires need to be grouped to achieve a delta connection. This was done using terminal blocks. The protective earth was left disconnected, as the system was to be run on an isolation transformer.
The wires from the board were then connected in phase order to the terminal block, completing the set-up. For my own testing convenience, I allocated it a small test-bench area along with a dedicated laptop for testing.
In order to set up the software to work with the hardware, the first step is to get the XMC Link debug adapter working. Interestingly, I found that to be mostly plug-and-play, with the adapter automatically detected and installed with WHQL drivers from Windows Update.
The device is detected with a VID of 0x1366 and a PID of 0x0105.
On Windows 10, the default WHQL drivers come from SEGGER and are dated 2nd August 2018 with a version of 6.0.2601.5. The driver file itself is named JLinkCDC_x64.sys and has a version of 220.127.116.11 debug.
However, if one is to follow the instructions to the letter, they should visit Segger J-Link Downloads page and obtain and install the latest version of the software.
After updating the driver at the point of review, the versions were 6th June 2019 with a version of 18.104.22.168950 and the driver file is named JLinkCDC.sys provided by ToriLogic GmbH & Co. KG with a version of 22.214.171.124.
Unfortunately, my experience with the software seems to show that updating the software resulted in more communication instability (as noted later in this review).
The next step is to install the MCEWizard software which can be downloaded from the iMOTION Downloads page. This software is used to generate the configuration file which is used to configure the motor drive later.
The process involves either loading an existing .mc2 configuration file or starting with a fresh configuration file, answering a series of questions (the default simplified workflow is illustrated above), calculating the parameters and exporting a text file. An example of a parameter text file exported from MCEDesigner from HV_FAN.ldf used later in this review is shown below.
##MOTOR1_PARAMS Custom_Design_Name Eval-M1-101T Mtr_Max_Speed 2730 Mtr_Rate_Amps 0.40 Mtr_Num_Poles 8 Mtr_Ke 36.00 Mtr_PWM 15 FastLoopRate 1 ##MOTOR1_REGS 0 #STRING 5SME072HXP0018(Welling-56-8) #VERSION 1 HwConfig 257 SysConfig 5 AngleSelect 2 CtrlModeSelect 2 PwmFreq 150 PwmDeadtimeR 48 PwmDeadtimeF 48 SHDelay 48 TMinPhaseShift 0 TCntMin 0 PwmGuardBand 288 FaultEnable 207 VdcOvLevel 2952 VdcUvLevel 984 CriticalOvLevel 3116 RotorLockTime 1000 FluxFaultTime 0 GatekillFilterTime 96 CompRef 1199 BtsChargeTime 150 TCatchSpin 0 DirectStartThr 1000 ParkTime 0 ParkAngle 0 OpenloopRamp 0 IS_Pulses 0 IS_Duty 4096 IS_IqInit 100 KpSreg 63 KxSreg 12 MotorLim 4096 RegenLim 205 RegenSpdThr 600 LowSpeedLim 819 LowSpeedGain 1397 SpdRampRate 82 MinSpd 600 Rs 2219 L0 10591 LSlncy 0 VoltScl 1818 PllKp 200 PllKi 16 PllFreqLim 209 AngMTPA 16384 FlxTau 1165 AtanTau 1414 SpeedScalePsc 9 SpeedScale 10549 SpeedScaleRcp 12723 SpdFiltBW 5461 PGDeltaAngle 171 IfbkScl 5805 KpIreg 2294 KpIregD 2294 KxIreg 481 FwkLevel 3040 FwkKx 32 FwkCurRatio 0 VdqLim 4974 AngDel 0 AngLim 456 IdqFiltBW 4096 Pwm2PhThr 3001 TDerating 1241 TShutdown 1241 CmdStop 0 CmdStart 0 CmdGain 0 AppConfig 8 NodeAddress 1 PrimaryControlLoop 2 PhaseLossLevel 22 TrqCompGain 120 TrqCompAngOfst 29000 TrqCompLim 2048 TrqCompOnSpeed 5000 TrqCompOffSpeed 6000 PolePair 4 FaultRetryPeriod 25603 OffSetAdj0 0 OffSetAdj1 0 HallAngleOffset 21845 Hall2FluxThr 540 Flux2HallThr 360 HallSampleFilter 288 KpHallPLL 0 HallSpdFiltBW 2048 HallTimeoutPeriod 1000 ##SYSTEM_PARAMS #STRING 5SME072HXP0018(Welling-56-8) #VERSION 1.0 ParPageConf 2048 ADCConf 1 InterfaceConf0 23 InterfaceConf1 0 UART0_Baudrate 0 UART0_IdleCount 10000 UART0_LinkBreakCount 10000 UART1_Baudrate 13587 UART1_IdleCount 10000 UART1_LinkBreakCount 10000 GKConf 4900 SW_Version 7 DACout 1489 DACout 0 DACout 0 DACout 1000 DACFiltBW 1000 SafetyEnable 0 FeatureID_selectL 65279 FeatureID_selectH 256 SysTaskTime 1 SysTaskConfig 123 AIN 5 AIN 6 AIN 7 AIN 21 AIN 22 AIN 23 AIN 0 AIN 17 AIN 1 AIN 2 AIN 3 AIN 19 GPIOs 53376 GPIOs 53380 GPIOs 1029 GPIOs 1030 GPIOs 1031 GPIOs 1032 GPIOs 1033 GPIOs 1034 GPIOs 1035 GPIOs 1037 GPIOs 1024 GPIOs 1024 GPIOs 1024 GPIOs 1024 GPIOs 1024 GPIOs 1024 GPIOs 1024 GPIOs 1024 GPIOs 1024 GPIOs 1024 GPIOs 1024 GPIOs 1024 GPIOs 1024 GPIOs 1024 GPIOs 1024 GPIOs 1024 GPIOs 1024 GPIOs 1024 GPIOs 1024 GPIOs 1024
Creation of the parameter .txt file is a “one-way” conversion of the answers to the questions in MCEWizard, as some calculations are made to convert the inputs to scaled values relevant to the hardware registers. If you’d like to tweak parameters later in MCEWizard, it is best to save an .mc2 file which contains answers to the questions instead, so you can change your mind later.
Unfortunately, the support for the EVAL_DRIVE_3PH_PFD7 is quite poor in this regard as there is no .mc2 system configuration file available and the application note instructions were written for a prior version of MCEWizard using selections which are not available in the present version. The motor parameters provided within the manufacturer’s datasheet and within the application note do not answer all of the questions within the configuration process, and generating a configuration with the best-known values did not result in anything more than a little acoustic noise and a twitch of the motor.
I suspect the reason is that the board configuration may not be entirely correct but there may also be motor parameters that are important that were not parameterised correctly despite the instructions provided. For example, it does not seem possible to measure Ld and Lq with what I have at home and my attempt at measuring Ke above results in a value around 9V/1000RPM which seems so far from the default 36V value that I begin to question it. Unfortunately, nearly-blind changing of parameters did not result in success either. There was also a subtle error in the application note which mentioned the IMM101 rather than the IMC101.
In my case, while I did eventually receive a combined .ldf file to load onto my drive, it was not properly configured either and I could only ever extract the parameters as a .txt file. Trying to learn what the differences were required staring at differences between .txt files, but not knowing what inputs were used to generate them.
The MCEDesigner software can also be downloaded from the iMOTION downloads page and provides the ability to interface, program, tune and debug the drive. In addition to the software, the latest firmware package also needs to be downloaded for the IMC101T.
When opening the software, the correct .irc file needs to be selected and the corresponding COM port selected for communications. Upon success, you will be greeted with the main window that offers functions and monitor traces. In the case your drive has an older firmware applied, then you will receive a warning and not be able to perform any functions except for uploading a binary.
In order to update the drive, the programming window can be accessed through the Tools menu and you can upload the parameters and firmware together. Once it succeeds, then the parameter values in the screen need to be updated for all registers to ensure the correct values for tuning and debugging.
The side-bar provides a full list of the registers and subfunctions available for the drive. Full register-level documentation is available in the iMOTION MCE Software Reference Manual in the downloads page.
The tuning of the drive is manually accomplished by changing register values and evaluating the drive’s performance. There does not appear to be any automatic tuning, however, such features rarely work well in real life scenarios. Editing most registers brings up a window that has some guidance as to the meaning of the register and helps to scale the value that you enter into the necessary format for the drive. Some registers are locked for safety and need to be unlocked before they can be modified.
Functions can be executed and the results are updated in the window – in this case, displaying the DC-Link bus capacitor voltage. Before functions are executed, MCEDesigner will confirm if you want to execute the function. You can also define your own functions and monitors.
The monitor traces feature allows for easier tuning and debugging by not requiring any external test equipment to take measurements and observe what the drive is measuring and thinking. The traces can be configured with two channels on a common sampling rate between 1 to 250 PWM cycles. The measurement can be triggered on a level, or fault, or rolling repeat while the results can also be logged to file. A scope window is displayed with live values, however, the update rate is still limited and the controls are relatively basic. In my experience, the trace window has a habit of freezing up after a while and sometimes takes a while to pop up once selected. Only one trace window is available at a time.
In addition to the aforementioned issues with documentation and configuration files for MCEWizard, there was perhaps an even bigger issue that plagued me – problems with programming and debugging the board.
As shipped, the board had a former version of the firmware and thus we are not able to work with the board until it is upgraded to the latest firmware. Unfortunately, while the programming menu seems straightforward, the process of loading the firmware proved problematic.
Attempting to program on two different Windows 10 machines on five different USB controllers (one USB 3.1, two USB 3.0, two USB 2.0) resulted in various errors programming the firmware and parameters. After a failure to program, the target board refused to respond.
I was afraid the board may have been bricked already, until I discovered a workaround that involved my older Windows 7 machine that was pulled out of retirement. For some reason, using that machine allowed the board to be programmed and debugged just fine.
After the board was programmed, I tried to debug the board on the Windows 10 machine and that went as well as you might expect …
… presenting yet more unhelpful error messages. This suggested to me that there was some issue with the J-Link CDC UART Port, perhaps in the drivers or firmware, or a timing bug of some sort. The failures were not always consistent – sometimes things would work for a minute before it would bug out. But this instability made tuning and debugging impossible.
Hoping it might have been a bug with the most recent version of MCEDesigner, I tried an older version download but encountered either errors during installation which stopped the install or errors upon launching the software. Perhaps it just cannot handle the newer firmware.
Another further issue is that even with the board programmed up … I couldn’t get more than just a twitch out of the motor and some acoustic noise. This means the PWM is working, but the parameters were not right. I tried tweaking them a lot, even reaching the limits of what the controller is capable of, but I wasn’t able to get any significant rotation.
Despite my best attempts at self-help and self-diagnosing the issues, I realised that I had encountered problems that can only be aided or solved by the vendor. My journey in attempting to obtain support can be summarised as follows:
Up until this point, I have not received any further communications from the official channels. I had contacted Randall Scasny (RoadTest Program Administrator) to try and expedite the case as this issue would affect the completion of the RoadTest report. He extended the review deadline and although he did communicate with his contact at Infineon (which initially had a bit of a misunderstanding), nothing seems to have eventuated from this avenue of inquiry.
It was not until 3rd September that I was contacted by someone who was willing to provide support outside of the official channels. At that late stage (17 days from RoadTest review extended deadline), I was eager to get any support that I could. To their credit, the support I received unofficially was very valuable in ironing out my understanding of the iMOTION platform and in attempting to resolve the observed performance issues which may contribute to future improvements to the support for this board. In this process, we were able to exchange ideas, demonstrate issues and conduct experiments to attempt to diagnose the issues, however, the issues are still not fully resolved at the point of publication.
I have a feeling from all of the documentation that Infineon prides itself on providing quality technical support for their products. My experience with their support has been rather negative, involving technical problems with their systems, long turn-around times, the inability to provide the requested parameter file despite multiple requests and the inability to properly diagnose and solve the issues with programming encountered with the XMC Link on my multiple Windows 10 machines. It is my expectation that if an evaluation board is used with a product (in this case, a fan motor) named within the evaluation board, that better levels of support would be available. If the application note claims that the evaluation board were used with that product, then the parameters and programming materials should be made available to assist engineers in achieving a more rapid start-up process. Furthermore, it should not come down to a well-meaning staff member to contact me directly at their own risk to provide support outside of official channels to get action on some of these issues.
The impression I get is that this particular EVAL_DRIVE_3PH_PFD7 board is not as well-supported as perhaps the other iMOTION boards. The choice of bundling an XMC Link instead of an iMOTION Link may have been contributory to the problems experienced. The documentation for the evaluation board barely makes any mention of the motor control aspects (e.g. dynamic speed control performance). It has been indicated to me that this board seems to be intended to demonstrate the PFD7 family of super-junction MOSFETs, but given the name of the board, it was not obvious. It furthermore results in a chicken-and-egg problem – if you can’t get the iMOTION controller going with your motor, there aren’t really any waveforms on the MOSFETs and drivers to measure!
In this regard, I feel that the more traditional controller/driver + inverter/power board combination is more flexible and more useful for evaluating the MOSFETs and drivers themselves. This would provide the possibility to mix-and-match different driving signals (e.g. from a signal generator) and provide ample opportunity for high-accuracy measurements without the interference and complexity of all the supporting components. This board appears to trend more towards a “solution-level” product, which may serve as an interesting reference for layout and density, but makes for difficult evaluation of individual components. As a result, it is hard to recommend this board as a first-step into evaluating an iMOTION-based system, EiceDRIVERs or PFD7 MOSFETs.
Fortunately, despite all of the problems, I still do have something to show for this RoadTest, thanks to the support I eventually received. This does not do the iMOTION controller any justice and the results point towards a sub-optimal configuration, but at least some motion was obtained.
These results are obtained using the HV_FAN.ldf combined programming file provided by Infineon technical support. There are obviously problems with the configuration, resulting in hesitant start-up, noisy flux-estimator speeds, incorrect speed capping and the ability to overspeed. I am convinced that the configuration is incorrect – it seems they have eight-poles configured for this four-pole motor and the scaling factors for the hardware are probably incorrect contributing to the observed noise. However, this does allow for demonstrating the MCEDesigner software capabilities and the output from the EVAL_DRIVE_3PH_PFD7 board. As this is most easily done by video – I have uploaded a short video to accompany this post. Apologies for part of the screen being cut-off in the video – I forgot my laptop had a native 1366x768 resolution but only captured the top left 1280x720 pixels.
As noted earlier, I was having various levels of programming and communications difficulties with the XMC Link and the board on my Windows 10-based machines. While my Windows 7-based machine could communicate and program the board properly, it is way too old and underpowered to help make the video.
I attempted to debug the issue somewhat to see what was going on.
With careful reading of the manual, it turns out that the communication between the IMC101T and the software occurs entirely over a TTL UART interface. This technically means that the XMC Link is being used as nothing more than a glorified, isolated USB to TTL UART adapter. When the communications work fine, it can be seen that pressing the stop button results in the command sequence on the left. Checking the width of the stop bit results in a baud rate of 115,200bps, a common PC baud rate that is supported by the IMC101T in autobaud mode. But after an incorrect programming attempt, the trace on the right was recorded and it seems that MCEDesigner has not picked up that the board is in some non-operational state and is trying to communicate with it anyway but not getting a response.
Knowing this, I decided to take a risk and use a non-isolated USB-TTL UART adapter based on an FTDI FT232RL, set to 3.3V. Note that this comes with a big risk if something goes wrong with the target – you could easily destroy your computer, create a risk of electrocution and/or fire. Because I was operating everything from an isolation transformer and was willing to take the risk (as I was operating everything remotely), I gave this a try.
With the bricked board, the FTDI-based interface detected it correctly in MCEDesigner and the programming of the combined file succeeded just fine. Running the board and traces worked more reliably compared to using the XMC Link, but was not entirely flawless as can be seen in the video.
This arrangement suggests that if you do have access to a board and no iMOTION Link or XMC Link, then you could potentially get away with a regular USB-TTL (3.3V) UART adapter but at the risk of not having any isolation (unless you have a USB isolator).
I was particularly interested in trying out the Vsp mode where an input voltage can be used to control the speed. There are pads on the board to allow connection of a potentiometer to provide this Vsp input.
Ordinarily, you would build your parameter file in MCEWizard’s Advanced Mode to select Vsp Control as the mode and then load that in using MCEDesigner. However, as I presently have no valid sets of answers to MCEWizard that would allow me to create a new parameter file that worked, I had to enable Vsp control in a different way.
After a bit of working with MCEDesigner, I realised that non-volatile register edits can be done, although some registers are locked against modification. In order to change them, you must first go to Register Structure Definitions -> Write Registers -> MCE Parameter Set -> Unlock_Parameter. Having done this, the static locked registers are available for editing. To allow Vsp control, the thresholds first need to be set – Motor Voltage Control -> CmdStart I set to 100, CmdStop I set to 80 and CmdGain I set to 280. These values were determined through a process of trial and error but represent ADC count values up to Vref (16383 counts). The CmdGain was trimmed back deliberately to try and avoid overspeeding and allow for better controllability. Because the motor is not capable of running very slowly, I also changed Motor Speed Control -> MinSpd to a value of 400rpm to ensure that the potentiometer range wouldn’t be wasted with speeds below the minimum stable value. I also increased SpdRampRate to 100rpm/s for quicker response. To actually activate the mode, it is necessary to rewrite Motor Control (Configuration) -> AppConfig to have a value of 9 (which enables both UART and Vsp control). After this, you can return to MCE Parameter Set -> Save_Parameter_Set and Lock_Parameter. After this, the Vsp mode should be operational. Had I been more adventurous, I could probably try changing initial angle sensing, catch-spin and fault retry registers too.
Look 'ma! No debugger! It took me a while to work all of this out, but it seems to work, so I now have a powerful, smoothly-variable fan for the upcoming summer season!
It took a bit of time for my contact to uncover any configuration files they could regarding this board. I was informed that the original parameter file could not be found, but they were able to offer me EVAL_DRIVE_3PH_PFD7.mc2 which was a configuration file for MCEWizard that should allow me to generate proper parameter files for this particular board.
Starting with the “Default Hardware Setting For New User” option, I input the motor parameters that we knew of and defaulted the remainder.
Unfortunately, upon loading the parameter file to the board, I was immediately greeted with a fault indication due to the DC Bus Overvoltage limit being set too low at 333V when the board could accommodate close to 400V and my mains voltage frequently pushes it up to about 350V. I modified the .mc2 file itself (instead of using the advanced mode) to increase the limits and was able to bypass this.
By trying different parameter variations (as the first one wasn’t quite right), I was able to get a confident start out of the motor and much cleaner estimated speed. But a new problem arose – the motor would reach the target speed and then suddenly stop, reverse slightly, begin twitching and then stop due to the ten-second rotor-lock protection kicking in. The below RPM over time plot made from data logged using the trace window.
I was informed (three days from review due date) to try following the motor tuning procedure in the iMOTION MCE Software Reference Manual for current feedback tuning. The motor tuning section in the manual is rather short and brief, but upon looking through the procedure, it seems it is not trivial. The first step is to verify the current sensing is good by measuring and comparing motor RMS current as measured by the board with that measured on an oscilloscope and the second is to measure the step response of the current flowing through the U-phase in a 0-degree rotor parked condition, also with an oscilloscope. The results would inform changes to the guard band, deadtime, delay and PI gains to improve the current drive and step response performance.
Unfortunately, this is where I hit a snag of sorts. I don’t have a clamp current probe with the bandwidth or accuracy needed to ensure the right result, but perhaps the best way to measure would be to introduce a shunt resistance. If I were to do that, then that could impact the motor’s behaviour (especially if it is only on one leg), so I would have to have three shunt resistances and measure across the shunt resistance to determine current. To do this safely, I would probably want to use my high voltage differential probe, but as a 10x setting is the lowest I can go, the shunt voltage might be a non-negligible portion of the actual operating voltage.
I opted to use 1-ohm, 1/4W, 1% resistors as shunt resistors as I had a bunch of these “on-hand” in the junk box. Current flow should be well under 1A as the rated motor current is about 0.25A, so power dissipation in the shunt should not be a big problem.
Unfortunately, even though I tried my best, I was not able to complete the first part of the tuning procedure as it requires the motor be running without load at a stable speed. Because of the strange “stop and reverse” behaviour, there was no set of parameters I generated that could result in the motor running at a stable speed. Likewise, with an integrated fan hub motor arrangement, removing the load of the fan blades is not a possibility either. Not being able to complete this first tuning part, I considered the second procedure, but the literature was a bit confusing to me. While the procedure to measure the step response without rotor movement seems fine (and involves quite a bit of manual register fiddling), how the measured step-response can be used to tune the P and I parameters is unclear. There are example graphs of measured step response at different step change rates, but how this is used to tune the parameters is not indicated. As a novice, I suppose becoming “lost” is not entirely unexpected. Unfortunately, this means the full potential of the IMC101T was not able to be demonstrated.
While I initially missed the whole point of the board which was to show off the PFD7 series of CoolMOS™ MOSFETs and the EiceDRIVER that drives them, I thought it would be a waste if I did not investigate this area.
The MOSFETs are perhaps an area where examining products on the market and their datasheets makes sense. I logged onto element14 AU and went searching for SOT-223 N-channel enhancement MOSFETs with a 600V rating and an Rds no more than 5Ω for power applications. Surprisingly, the result was pretty much a home run for Infineon’s products.
The comparison is grouped by family and sorted by ascending Rds within families. The leftmost is the PFD7 family with the reviewed unit using the IPN60R1K5PFD7S highlighted in yellow. The next family is the P7 family, followed by the CE family. Finally, the only product in this round-up that was not an Infineon was a STMicroelectronics ST6N60M2.
The table makes things quite clear – the PFD7 family’s biggest strength lies in its superior body diode performance. The voltage drop is a little higher, but the robustness and reverse recovery time and currents are leading the pack, resulting in less wasted energy. The PFD7 family’s threshold voltage is a little higher than the others, and the intrinsic gate capacitance seems average. Aside from this, the specific PFD7 transistor chosen has a higher Rds than others in the family, but is rewarded with a low gate capacitance, low gate charge and faster turn-on times, but the fall time specification seems poor. Price-wise, the PFD7 is a little more expensive in individual quantities, but the performance may justify this depending on the application. Another key feature is the integrated Zener diode on the gate, which would likely contribute to increased robustness and ESD resistance.
When it comes to MOSFET drivers, the situation is less clear. While there are many half-bridge or high-side and low-side drivers, it was not easy to shop for models that were capable of operation up to 600V. Many of the ICs I read the datasheets for were not capable of operating past relatively low DC voltages (e.g. 12V to 36V). Perhaps I was not searching all that widely, but in that respect it seems the Infineon 2ED28073J06F high-voltage half-bridge driver offering is perhaps a bit special.
It seems the board is configured for the ability to monitor the driver’s performance, but less-so that of the MOSFETs themselves. I had to set up an elaborate probing set-up to obtain sensible measurements. Channel 1 is set to monitor the high-side gate drive by measuring between the HU terminal and the U-phase output (no test point provided here, making it slightly difficult). Because this is not referenced to ground, a high-voltage differential probe was used. Channel 2 monitors the low-side gate drive by measuring between the LU terminal and GND. This does not need a high-voltage differential probe as the voltage is low and referenced to a common GND, however, because of the design of the board, a small voltage offset is expected as a leg shunt resistance is in series with the drain to ground connection of the low-side MOSFET. This offset voltage is expected to be small. Channel 3 monitors the sum of all shunts which is available at the Id terminal, an input to the OCP comparator. This should indicate the current through the bridge and also can be probed using a standard passive probe referenced to GND. Channel 4 monitors the voltage across U and V phases and also requires the use of a high-voltage differential probe. As this voltage has a lot of high-frequency components because of PWM, it is also low-pass filtered in a math channel M1. The resulting probe output is seen in the above oscilloscope trace.
Zooming into just a few switching intervals and reconfiguring the gate traces so they have a common scale and base, it can be seen that both high side and low side MOSFET gates are being pushed hard enough – with a 13V gate drive supply available, the measured voltage is about 11.8V on the high side and about 12.8V on the low-side. The slightly reduced drive on the high side is not unexpected, as this relies on a charge pump to hold the voltage above the DC-Link voltage rail (Vcc) and thus depending on the size of the capacitor and the charging efficiency, the drive voltage could be slightly impacted. It is well above 10V, indicating the MOSFETs should be driven plenty hard. Examination of the overall rise time shows both sides have rise times in the 5-7µs region, and fall times around 0.6µs. This is not as quick as the datasheet specifies, but perhaps has to do with differences in this specific application or the measurement method. Looking at a more zoomed in plot, there is a slight glitch measured on the high-side just after the turn-off which is probably not originating from the driver itself, but may be noise created by the switching of the MOSFETs on other phases which has been picked up by the active probe as it coincides with some sharp transitions in the Id channel.
Zooming in a little closer, a quick measurement of the dead-time shows that it measures about 1.02µs which matches the configured default dead time expected from the IMC101T. This suggests that the gate driver is faithfully reproducing the switching signal across the high and low sides.
I was able to reconfigure to monitor one high-side and all three low-side drives and found the rise and fall times to be very much consistent as is the drive voltage. Monitoring two high-sides (one with each differential probe) showed a subtle difference in gate voltage (perhaps a measurement error) and the presence of short glitches just after the turn off point (probably noise induced into the measurement).
Unfortunately, the equipment to hand does not allow for a more in-depth view of multiple driver channels at the same time and the design of the board does not lend itself to a finer-grained investigation of MOSFET performance without removing the MOSFETs and putting them into a dedicated test fixture.
The Infineon EVAL_DRIVE_3PH_PFD7 evaluation board combines an iMOTION IMC101T microcontroller with their 2ED28073J06F high-voltage half-bridge EiceDRIVER and IPN60R1K5PFD7S CoolMOS MOSFETs to create a sensorless field-oriented control motor drive solution. The board has been designed to be small and mimics a solution-level design, but in doing so, I feel that this board tries to achieve too much and inadvertently creates new problems.
The design of the board as a monolithic unit creates a chicken-and-egg situation. Until the user is able to get their motor-of-choice parameterised and configured correctly to run using MCEWizard, MCEDesigner and their choice of register tweaks, it is not possible to evaluate the performance of the MOSFETs or their drivers. The compact design also creates probing anxiety with test points unsuited for use with some types of differential probe clips and near other high-voltage points on the board. The components populated on both sides and lack of stand-offs or mounting holes makes for difficulty in safely positioning the board for testing. Finally, the design of the board also does not offer many possibilities for closer examination of MOSFET performance and seems more driver-focused.
Unfortunately, this was also met with a number of documentation and technical issues including the lack of up-to-date documentation covering the latest MCEWizard dialogues, the lack of an MCEWizard system configuration (.mc2) file and incomplete parameters for the named motor in their application note document making it near impossible for a novice such as myself to generate parameters that would actually get the motor to operate. This was complicated by issues with XMC Link communication causing problems with parameter, firmware and combined-file loading and occasional issues during interactive tuning and debug.
This was a very challenging RoadTest for a number of reasons and I believe the time I have invested in this has been disproportionate. The expectation for an evaluation board is that it would be a rapid path to functionality and ease the process of evaluating and implementing a design. Choosing parts that are named in an application note should naturally come with better support.
Infineon’s technical support was also not up to expectations, with the official channel suffering technical issues on attempting to submit my initial support ticket, long turnaround times and eventually silence. Initially provided files did not work, while later files were not optimally configured. The request for the parameter file or answers to MCEWizard they used to configure the motor for the application note seems both sensible and obvious, but it seems that the file remains elusive. It took a brave and dedicated person to contact me directly to provide support, although the problems with programming and parameter file generation still remain unresolved at the time of publication in spite of a one-month extension to the RoadTest review timeline.
Traditional iMOTION boards seem to be separated into microcontroller/driver and inverter/MOSFET boards which allow for easy mix-and-match or eschewing the control solution entirely while providing easy points for instrumentation. This board obviously does not follow this philosophy and I think that is a detriment as it makes evaluation of component parts more difficult – for example, if someone was more interested in the MOSFET and drivers, and did not want to or could not get the iMOTION controller working. One interesting aspect is that the IMC101T is perfectly happy to work with traditional hall-based sensing, but the board does not break out the possibility of connecting a hall sensor with compatible motors. I feel the insistence on field-oriented sensorless control makes getting started more difficult, especially with entirely unknown motors, so if evaluating the MOSFET and drivers is the aim, then this choice also works against it.
Once again, I would like to thank element14 and Infineon for selecting me as the RoadTest reviewer for this item.