BasicPI

I was rather pleased with routing MC3P60V because it is a dense, functional design. But, as I reviewed the design I found this. The error here is that this is 60V and I used 0603 packages. 0603 usually hold 6ich V, so I will either need to upgrade to larger 60V or try something else.

 My first thought is to use 2 x 1206 components in series to achieve 60V, but I need to check around what I can get and actual size of components. I have 2 of these cap circuits related to DRV8301.

And looking at the current PCB you can see that I am a bit out of space. I have a heat-sink that cost 1ich USD and that is perfect size, so I seriously do not want to change size on this design.

I am a big fan of things that just work, which is why I have stuck to Coocox and CoIDE for years. But, as it now looks like this tool is dead I basically need to move on.

Coocox had a very good concept and was one of the few Eclipse based IDE’s I liked, so it is sad to see them go. But, I understand they could not make money from their business model and in the end gave up. Their site is now down and I am stuck with version 1.7.8.

Looking at alternatives I find the following:

SW4STM32 is free and supported by CubeMX. I will discuss CubeMX a bit later.

Em::Bitz is free and have reached version 1.1. This originate from Code::Blocks and was previously Em::Blocks that now is forked into Em::Bitz. The drivers supported here are only the old drivers, but you can dowload and set up new ones as well.

TrueStudio is a commercial IDE, but it has a fully free version for STM32 as well. It is also supported from CubeMX and is Eclipse based.

I will be evaluating these options over the next days and share my findings with you. The one I am curious on is EmBitz. This is unlike the others based on Code::Blocks and written in C++. I mention this because performance do matter and I hate tools that forces me to care about Java versions installed on my computer. Why should I as a user need to care about what my tools are programmed in? But, using a Java based tool you often need to do that. The other issue is that C++ developers tend to have a better gasp of what is needed for Embedded C/C++ development. With one exception – CoIDE will be missed. Their concept was good.

I have a load of motor controllers that I want to continue on, but to focus on the more advanced ones.

MC4X60V50A

This is an early draft of rev 1.1 of the MC4X controller. Notice the heavy wiring at right to support 50A + all components top-side so I can add heat-sink on the PCB. All transistors have pad’s and being cooled at bottom. Two temp sensors added between MOSFET’s.. INA194 as Current Sensors, CAP’s on the PCB etc.

The results from the previous 1.0 version was actually so promissing that I am looking forward to this one. But, it is still work in progress.

MC3P60V50A

This has been in the pipe a few weeks. It is a dedicated 3-phase controller. It is 15mm more narrow than MC4X60V50 and uses DRV8301. I want to do an upgrade before I ship for this – some of the small capacitors are 0603 and need to support 60V – that will not work + I need a better place to mount the main capacitor.

Comparing MC3P and MC4X I must admit that I get a lot of functionality for those 15mm extra. MC3P is a bit smaller, but MC4X can do the same and more. I still want to do MC3P because I want to play with DRV8301. ANother change is that I consider putting wires on top so I can use a 100x25mm heat-sink on PCB-bottom.

Another concern is that I on this planned thick PCB lanes on power – simply creating a thick solder path. I am considering upgrading that to wires like I did on MC4X.

MC3X60V3A

This is the smaller of the 60V design. First test failed at 35V, but I have been advised to make a change on the DC/DC that I want to try out.

MC3P28V3A

This is the smallest based in DRV10983. It works, but I am not impressed over DRV10983 speed regulation. I will find more time to play with the I2C interface on this, but I need to see a better controller if I am to continue with it.

I finally got revision 1.1 of these boards yesterday, so I can get on with this adapter. The main error on 1.1 was lack of crystal and I realized I needed the crystal for USB as I tested.

I like CubeMX, but I fail to undestand “designers” that want to create a “HAL” and only do low level, MCU specific interface. In this example I would have liked a function to select bitrate, but are left with setting up loads of timing details.

Even more annoying was that the generated project for STM32F105RB do not want to compile due to lack of files. This is where auto-generation and I usually separate.

The config system in CubeMX allows you to configure and generate code for all components you have included, including FreeRTOS and libraries. This page show the config for FreeRTOS and it allows you to create a list of Tasks as well as message queues.

The folders on top are

• Config Parameters
• Include Parameters
• User Constants
• Task & Queues (shown here)
• Timers and Semaphores
• FreeRTOS Heap Usage

The reason why I like this is because I don’t know FreeRTOS and within a few clicks I am using it and on my way into functionality. FreeRTOS is also included in ESP32 IDE supporting multiple cores and have been around for years.

This shows the STM32CubeMX for my 3 x RS-X PLC Module. I find this tool to be quite usefully as it allow you to set up the clock, configure each function and wire the MCU. It also generate a nice PDF document with all details as well as a starting project with all init code as well as FreeRTOS should you want it.

The generated code opens in System Workbench for STM32 and the only complain is that they only support C. But, you should be able to get C++ with a bit of manual work.

It all works well with a low cost ST-Link, so you are on your way blinking a status led within minutes.

System Workbench for STM32 is far behind CoIDE and CooCox, but I still use CoIDE 1.7.8 and as CooCox seems to be down (?) I need to move on. My main concern is lack of C++ support which sadly is very common in many embedded IDE’s. Returning to STM32CumeMX, this tools is free from ST and a big time saver. It download latest drivers and give you working examples on how to initialize the MCU. It also warns you about wiring conflicts and does the job of setting up the complex clock.

Been a lot of motor controllers lately so I finally decided to assemble part of my PLC system. What you see here is the motherboard with a simple RS-X module connected. Not all components are assembled yet, but processor is alive. This board have 3 x fully galvanic isolated RS485 circuits and a 2 x 10Mbps backbone. It was selected because it’s a good, simple starting point for SW development.

The STM32F405RG is excellent for Plain. With it’s 1Mb Flash and 196Kb SRAM it is an excellent test bench. I need to make a similar module for CAN, but that can wait.

I must admit it is a bit of nostalgia to work with something that looks like one of the computers I assembled in the 80ts.

I only ordered one module because I want to play with the mechanical design a bit before I start adding modules. I notice far more issues with a physical module than with a 3D module.

The MCU is currently ticking on 8Mhz using the internal RC, so it will be interesting to see if I got this right and are able to tick the MCU at 168Mhz with 3 x 180Mhz DC/DC converters on the same module.

Investigating the issue one option is that what snapped the TSP54060’s is that my PCB tracks are to close for 60V. You need close to 3000V per cm to create an arch and that is 30V per 0.1mm. I can’t see a weak point, but those pins are 0.2mm apart. A bit of extra solder tin on them is all that is needed and 35V is suddenly dangerous. Again I can’t really see anything, but I realized that a MSOP might be to small to actually support 60V safely.

I will try a different circuit, but I will also knock up a few test circuits with different DC/DC designs to see if I can find a stable 60V design. In the meanwhile I will test on 24 and 12 V because I also want to test he actual motor driver. I also realize that as DRV8313 also have 0.2 mm between pins and I actually limited that to 0.15mm as I widened the tracks – I might have a second 60V issue here. Now 60V was never a main objective on this small controller and I am not sure this is the problem, but standards indicate that I need more distance.

I received the MC3X60 Motor controller PCB’s yesterday and as always it is awesome to see how small my designs are. As this is the first time I use TSP54x60 I instantly assembled this to test and was pleased to see 3.4V out.

This circuit worked well giving 3.4V out with input from 12 to 30V, but TPS54060 snaps as I try 35V input.

I received MC3X60V yesterday and was very pleased to see the DC/DC actually working. I had to adapt values to E24/E48 series – R7 became 240K, R6 became 75K, R4 became 33K, but it gave 3.4V out which is fine. I can adjust it back with a E48 combination of R4/R5 later, but the requirement is actually 3-3.6V. As I turned up the Lab PSU Input it works perfect up to 30V input, but snaps as I try 35V. Exact same behavior on two different TSP54060 chips so far. 

This was a bit disappointing because it should not have snapped before I reach 65V, but I will test with TPS54160 and TPS54260 as well. I will also solder up a 2nd circuit. I also detected that the circuit behaved strange if I did not have a 1000uF capacitor over the 60 attached. I have double checked the circuit and components – it is only the TPS54060 that snaps.

My first thought is that I have gone wrong by leaving pin 3 and pin 6 floating. Pin 6 can be left floating it states, while pin6 is an output signal.

Regardless – I also have TSP54160 and TPS54260 chips to test + I only planned to develop with 12V anyway, so I can continue on two paths here (1) testing 60V PSU and (2) testing the rest of the motor Controller.

Don’t worry, I will get to the bottom of it. But, as usual I am my own enemy and don’t make breakout boards I can test new circuits With easily. It is straight on a dense, small design. I am a bit spoiled as I get things working most of the times 🙁

Every year around christmas I tell myself that next year I will have electronic christmas decorations, and as next year arrive it’s forgotten until it’s to late. A combination of STM32F030 and ULN2003 is excellent for a very small x-mas tree PCB with blinking LEDS and home made tree lights. In fact I have done this circuit before as a PWM driver with a single ULN2003, so what I will do is to make multiple PCB’s with LED strings connected through a RS-X (12V + RS485). These can then be wired in the x-mas tree and controlled by RS485 connection and 12V LED driver.

STM32F030F4 is excellent for this purpose, it cost 0.4 USD from AliExpress and all I need are sufficient to cover 20-40 of these. A 5A LED Driver should be more than sufficient. We make a harness with connectors up the tree where each decoration connect to this is a star network.

Application can be constant or random patterns as a start to make it simple. In fact I could make a small ESP32 control system with RS485 at bottom so I get the entire c-mas tree on Wifi or bluetooth. This could be a lot of fun.

The cost of this will be 2-4.- USD per PCB, around 10.- for the control system and a bit for the wiring. I probably end up spending around 100.- USD for a very attractive x-mas tree light system.

I can probably use up to 200mA per ULN2003 and a quick calc is that a single LED uses around 5mA, so in short – I will run out of space and LED’s before I run out of power. But, we should limit each decoration to ca 250mA max – I will probably need far less.