TM32F1xx, some advice August 14, 2015

I have worked with the ST Micro ARM Cortex-M3 micro-controllers. I used to like them pior to Broadcom; here is some advice to help you along.

• Yes, you really need all those capacitors. These things run at 75MHz or better. Put the caps close to the pins.

• These things are more easily damaged by ESD than one might think. Yes, I know they’re supposedly marketed for automotive applications. Yes, I know the data-sheet says class blah blah blah. You need to do more, I had a product whose only vulnerability was the battery compartment and I still had to do more. I found this helpful

• Build your own cross compiler from scratch! You will learn things about C/C++ that you need to know to be a good embedded systems engineer. I have some stuff like crt0 and linker scripts on this site. Yes I cut and pasted them but I was about 3/4ths of the way through writing them from scratch before I found prettier ones on-line and no, I did not waste my clients time, I was able to solve deep problems with other people’s projects at the same client because I understood this stuff. I stood on the shoulders of giants and here’s a link to one of those giants 🙂 The Olimex site also has some info for building a cross compiler.

• I like and recommend the Olimex boards but I had some ESD (Electro Static discharge) when I blindly based my board on their design (see above) which inturn was based on a reference design. So don’t be lulled into a false sense of security, add mitigation to your design. I used a TVP diode between VDD and VSS on the line coming from the battery clip.

• I have the FlySwatterII and the Olimex ARM-USB-OCD-H, I prefer the latter mostly because it can provide power.

• Use the ST micro provided libraries sparingly, sometimes it’s easier to understand the peripheral and write your own code than to try to sort out their library madness or HAL.

• ...and don't get me started on the Xilinx board suport code, Crayon, it's written in bloody Crayon!

• OpenOCD and gdb are awesome. Yes gdb has a steep learning curve, no it’s not pretty, but it is the most powerful debugger known to man… The only thing I’ve ever seen that was close ran on a VAX when I was a kid. I find cgdb helpful. I sometimes use the layout stuff but it’s a bit young (read buggy) but helpful. Seriously, learn to cope with gdb it can do things no other debugger can.

• Read the errata these things have a surprising number of hardware bugs!