BasicPI

I really like CubeMX for what it tries to do, but having used it for a while on different MCU’s I also realize that the code it generate is not very mature. On some MCU’s it works well, on others it don’t even compile or as in the example of STM32F105RB temporary brick the MCU. The F105 is also part OpenOCD since CoIDE behaves better.

This creates an issue because I am not sure wherever to continue with CubeMX drivers or roll back to old ones. Luckily I do not depend directly on either as I use my own HAL wrapping in C++, but I need a driver library to fuel this wrapper and it is not really a path forward to use an old library that is going obsolete.

Moving on to IDE discussion SW4STM32 is a possible path forward as IDE, but I am not convinced. I will use it because it integrate nicely with CubeMX making it an easy path for HW testing, but I am far from convinced I will use it for actual Projects.

EmBitz 1.11 looks very promissing being build on Code::Blocks. The only libraries supported out of the box is however the old standard libraries, but EmBitz does also support other MCU’s. I am however not sure exactly how active this project is + I want to go back and investigate using Code::Blocks itself.

Updated Article!

I am quite happy with the 5 port Com Hat I made for Raspberry PI, but I want to use a STM32F405RG and maximize usage of all it’s IO capabilities. This will be an upgraded Hat with a few more features included:

• Replace F105 with the faster and more capable F405 including 1Mb Flash, 192Kb SRAM, ticking at 168Mhz with an ARM 32-bit M4 core. This change will allow Python and .NET to be used as well.
• Add a RTC w/battery connector.
• Add a SPI Flash
• Add a SD/TF Card. I will use a 4 bit MMC version.
• 2 x CAN ports as before
• 4 x Serial ports. 2xRS485, 2x RS232 or TTL. My first thought is 2 x RS485, 2 x RS232 and 1 x TTL, but lets see.
• 1 x SPI port
• 1 x I2C ports
• SPI, I2C and available pins as separate extension port. Maybe even throw in a UART TTL here.
• 1 x USB
• Limit leds to 1 or 2 pin’s max. We can signal through blink sequences.

I have the pins to do this, so it remains to se if the space of a Raspberry PI Hat will allow for this. I will need to use 3 sides with JST Micro connectors for this one.

PSU here will either be USB or RPI Connector, but I will add a 2 pin 5V power as well.

I am a heavy user of STM32F105RB/RC, but I have not used it much with SW4STM32 before. SW4STM32 (System Workbench for STM32) or ac6wb as it also is called is based on eclipse and uses OpenOCD to connect to the MCU’s Serial debugger. A few days ago while testing CANUSB I noticed problems. First on one MCU, then on a 2nd, 3rd, 4rth and 5th as I just continued bricking MCU’s to rule out that it was the batch.

The library and code here is generated with CubeMX, so I am not sure if it is the generated code, OpenOCD or SW4STM32 that trigger the problem.

I just brought the original MCU back simply by erasing flash with STM32 ST-Link Utility. It worked fine with CoIDE, but as soon as I try SW4STM32 OpenOCD will brick it. Some times it works fine a few times before it suddenly break and I need to bring it back with STM32 ST-Link Utility.

Adding to the story – I downloaded the code generated by CubeMX manually and the same happened. OpenOCD ir SW4STM32 do have a bug because it is not capable of programming the MCU while CoIDE has no problems. But, even STM32 ST-Link Utility cannot connect after code is started, so I need to do a connect under reset – meaning the problem here is the code generated from CubeMX.

This is not the first time CubeMX hits me in the face with a non-mature code example. The tool is great, but I am not able to trust it’s code at precent.

I tried to generate a test project from EmBitz as well, but that uses old libraries for a start and it don’t even compile as it miss the main header file. It just proves to me that I need to manually assemble the HAL myself file for file. I would like to use the newer CubeMX, but I do question their maturity Level.

It also raises a question wherever I should just move on to STM32F405RG. F105 is a real good MCU, but it is less supported than F103 and F405. It cost 50% of a F405, but it is nothing a F105 does that F405 can’t do better. In schematics it is only 2 capacitors that differ the design and they are drop in replacement of each-other on electric levels – obviously F105 have a few less capabilities than F405. I am not ready to give in on F105 just yet, but I am reaching a point where the added cost has to be weighted against time usage and support. And the only argument so far in favor of STM32F105 is that it cost a bit less than F405.

I have never used the STM32 Server or this link utility before because the IDE’s mostly do the job. But, I have discovered something strange…

After flashing code on a STM32F105RB a few times from SW4STM32 the chip would not download anymore. It happened systematically on 5 different MCU’s, but after using this utility to erase the MCU it worked again.

This is the cost for a single unit from ST’s own site. Buy 1 million and you get 3.8USD, but you are still not close to the stated cost on their sides. And adding to this you get 20.- USD P&P and Customs and Handling fees.

A single MCU would actually cost me ca 50.- USD if I purchased from here. I think not!

Norway is threatening to start charging MVA on 1st cent for anything imported. It will be a return to the stone age for people like me. It is not the MVA, but the handling fee of 15.- USD they put on everything that will kill electronics import. The did this in Sweden earlier with devostating effect.

Dealing with STM32F105RB I just had the strangest error. ST-Link started failing on my CANUSB adapter and as I tested on a Rx breakout it failed there to. Moving to F405 it works fine and moving to a 3rd board with F105 it works fine.

Two different boards with the same MCU failing at the same time? I guess I just experiencied Murphy’s Law. Another explenation might be that I finally killed MCU’s with static electricity? If so it would be the first time in the last 6 years! It can also be that I am paying the price for picking up cheap MCU’s from various sources. I seriously which ST could provide a way to sell MCU’s in low volumes for prototyping.

A trick I use is that I connect GND to the ground plane to avoid ground loops. But, what I need to watch out for is isolated icelands that is not connected. I realized that the EDA don’t check this, so I check it manually by using MSPaint to paint the ground plane. In this case it is ok as all areas used actually are connected to ground.

The illustration above show the number of connectors we could need on the Train Control System. I intend to use 1.25mm JST Micro connectors, but space is very limited so this will be a challenge.

• #1 is the 6 pin programmer port. It is no way to get the programmer with USB connection on the controller so I create a 6 pin program port and a separate programmer board. The intention is to wire this up so we have access to the port below the train. Once this is coded we can also use the Wifi for updates. 
• #2 is the 2 pin power port
• #3 is the 2 pin Motor port. 
• #4 is the 2 pin Super-Cap port. Super cap is like a small battery that will keep the system alive as we move over track gaps. 
• #5 is the extension port to a 2nd controller board.

To optimize this I plan to reduce this to two connectors. One for Motor, Power and Super-Cap and a 2nd for Programming/Extension. I believe 2 connectors are doable, but I need to draw the packages and make a PCB layout before I actually know.

This is an early mockup of a ESP32 based adapter for Raspberry PI. I like this early mock-up’s because they give me an idea about what we can get away with. in this case I can add 3-4 connectors top-left to get some extra IO, but I will still have plenty of space.

I need to connect and experiment with CAN and UART’s on ESP32 before I finalize this board. But, I do like this form-factor. I can probably also squeeze this down to a smaller format dropping the IO connectors.

I added 1 x CAN, 1xRS485 and 1xUART. The later is perfect for HMI etc. This will as mentioned work as a RPI Hat or stand-alone Wifi connector. The good thing about ESP32 is that it is still a decent, low cost breakout even if you do not use Bluetooth or Wifi.

The release of Raspberry PI 3A+ is a good host for a mini level system due to it’s powerfully 4 x 64 bit CPU, but as the RPI itself do not contain any com connectors we need to use an adapter card. I decided to try ESP32 because that makes it dual purpose. ESP32 can act stand-alone using it’s own Wifi or just gateway to Raspberry PI for more power and to enable a RS232, RS485 and CAN port.

I use the GPIO and SPI port to communicate with Raspberry PI and CAN or RS485 for the rest of the network – or I just use the ESP32 as host for lower cost – depending on Application.