New Black Magic Debug Maintainer

2 Replies

Hi everyone!

As some of you might know Black Magic Debug was created and maintained for many years by Gareth McMullin. He has created a wonderful tool that we all use and love. You might have also noticed that Gareth did not have much time to dedicate to the project for the last few years. He asked me a while ago if I would be able to take over the project and become an official maintainer of Black Magic Debug. I did not have the necessary resources to dedicate to the project until very recently. But it is finally time, from now on I am officially taking on the position as the Black Magic Debug maintainer. 🙂

I want to thank Gareth for putting the faith in me and creating this amazing project. I also have to say big thanks to Uwe Bonnes who stepped in while Gareth and I were unavailable to keep the patches and Black Magic releases going.

I have a lot of plans for the Black Magic project, software/firmware and hardware wise. You might have noticed I already spent some time catching up on and cleaning the GitHub issues. It is by no means finished and probably never will be, but I hope we can keep open issues and pull requests on a better level going forward.

To resolve the issue that the native Black Magic Hardware is currently not available due to chip shortages, I am working on the new revision of the native hardware. This should make them available again and allow us for more alternative chip choices. We are adding some cool new features to the new hardware while we are at it. (more information soon) I am also working on a tool that will help users manage the Black Magic Probe firmware, opening doors to more flexibility and versatility of the project overall. (also, more information about that soon)

A small teaser of the new native Black Magic Probe hardware V2.3a
3D Printed cases for BMP V2.3a

You can also expect that we will finally get a proper CI system including HITL (Hardware In The Loop) testing. Something we are in dire need to keep the stability expectations as high as possible. I was collecting a lot of hardware over the years and I want to put it together to some good use. We will also improve the contribution process and document the APIs better, this should hopefully make addition of new targets easier.

There is one more thing that I would like to mention. In the process of changing maintainership the GitHub organization that the project is under will be changing it’s name. As it is not developed by Blacksphere (Gareth’s consulting company) we will be renaming the org to the project’s name itself. It will serve as an umbrella for additional repositories related to the Black Magic Debug project. Don’t worry GitHub should redirect the old organization names to the new one. I hope it will not cause too much disruption. We will also finally be officially retiring the SourceForge project page to avoid confusion. This means the old unused mailing lists will be disabled.

If you have questions or concerns and want to get in touch with the project you have multiple options: open an issue on github, join the 1BitSquared Discord server and talk to us in the #blackmagic channel. If it is something you would rather discuss one on one, you can also write an email to: contact at black-magic org where you will be able to reach the core developer team.

I am excited to work with you all to bring the Black Magic Debug project to the next level.

Stay safe, cheers,
Piotr Esden-Tempski

My Streaming Setup and Electronics Tools Collection

Leave a reply

Hello everyone!

As many of you ask about the tools I am using for twitch streams as well as what electronics related tools I am using. I decided it was time to put together a blog post for that. I will likely keep updating this specific post when my streaming setup evolves or I need to add more content. This blog post is derived and updated version of the Gist that I posted a while ago.

This post is currently reflecting the gear I am using in May 2020. If you think anything is missing from this list or it is not up to date any more. Feel free to ping me and I will do my best to update the list! 🙂

Computer

Currently I use a scratch built PC for streaming, here is the list of the major components:

  • AMD RYZEN 7 3700X 8-Core
  • Gigabyte X570 Motherboard
  • 64GB of RAM
  • Gigabyte Radeon RX 5600 XT GPU
  • EVGA SuperNova 650 G3 modular power supply
  • Noctua NH-U14S 140mm SSO2-Bearing CPU cooler
  • Fractal Design Meshify C Black Compact Mid Tower case
  • Two 1080p Dell monitors I had since years

For the complete build and the exact parts used you can find the NewEgg build here: https://newegg.io/a1664311

Cameras

Lighting

Capture Devices

Audio

Software

  • Main Streaming software: OBS
  • Linux Browser view used for overlays and plugins
  • Free Plugins/overlays from Streamlabs
  • AlertBox: Displays alerts of new followers, subscribers, bit donations and more
  • ChatBox: Displays the twitch chat messages as video overlay
  • Cloudbot: Provides commands like `!uptime` and automatically sends out an invite to the Discord server.
  • Key and Mouse visualizer: TrayKeys
  • Text Editor: Sublime Text
  • ToDo List Sublime Text Plugin: PlainTasks
  • PCB Design Software: KiCad
  • FPGA Tools:
  • Logic Analyzer framework/software: Sigrok/Pulseview

Other Gear

1BitSquared and other stuff

If you like what you see and would like to support the streams and development of new open source devices, but you already have all the 1BitSquared hardware you need, you can support me through Patreon and/or Twitch subscriptions.

You can reach me through twitter and on our 1BitSquared Discord server. I hope this list is useful.

Cheers,
Piotr

Upgrading a T962a Reflow oven (old)

3 Replies

This post is the old version of the T962a Reflow oven upgrade documentation. A more up to date version of this post with additional information and pictures can be found in the 1BitSquared forum. The following text is being left here for historical reference. 😀

Hey!

Many people ask on a regular basis what Reflow oven I am using. To answer that question I use two fully upgraded/modified T962a reflow ovens. You can get them from ebay for around $300 give or take. I heard some people had some success using toaster ovens with modifications for reflow but I personally do not trust that solution enough from not only the safety standpoint but also from the ability to follow a reflow temperature curve in a repetitive manner that I can trust. That also means you will need the T962a and not the less powerful T962, you will need the power to be able to reliably follow a reasonable reflow temperature curve.

That said the T962a is completely useless when you get it and you need to make a few modifications to it. If you do not make those modifications you will create a safety and health hazard. Also you will likely burn up your pcb’s or evaporate the flux from your solder paste before it reflows creating cold solder joints.

The closest thing that I could find that could be an out of the box working replacement is about 10x more expensive than the T962a including the modifications.

This are the supplies you will need:

And these are the following steps you need to perform to modify your oven.

  • Open the oven
  • Remove all the masking tape and replace it with Kapton tape (pay attention to the masking tape that is hiding under the insulation in the front of the oven attached to the “ruler” shaped cover above the oven’s drawer, you need to replace that too)
  • Make sure that the whole case of the oven is connected to the earth ground of your power connector using the multi-meter. You might need to scrape off some paint under the back panel screws to create a connection between the earth and the bottom half of the oven.
  • Re-flash the controller board with the Unifiedengineering firmware: https://github.com/UnifiedEngineering/T-962-improvements/wiki
  • Build the Thermocouple interface board and mount it in the oven: https://github.com/UnifiedEngineering/T-962-improvements/wiki/Better-thermocouple-interface (you can use the oven without the TC interface to reflow the TC interface, but it might be better if you have some other place you can reflow the board in, but it should work for that one time :D)
  • Replace the small cooling fan for the controller electronics with the new “silent” fan.

If you have all the supplies that modification should take no longer than one afternoon and it is really worth it!

Notes about usage:

  • Pre-heat the oven to 40C before use.
  • Put down scrap PCB material under the board you are reflowing so that it is not sitting directly on the metal tray. If you don’t do that the tray will suck out valuable heat out of your PCB and cause problems.
  • Use only the center 1/3rd of the oven tray. The outer area of the reflow tray will not have the same temperature as the center and you will have consistency issues around the edges of your PCB’s. This is a good reason to design your boards as small as you can so that you can squeeze a bunch of them into the center of the oven. ;D

Hope this helps.

Cheers,
Esden

libopencm3 Discovery

Leave a reply

Hi everyone,

As promised in the previous post. Here is a short write up how to download, compile and upload your first example program using libopencm3 and a STM32F4 discovery board.

Very similar process will apply to any other evaluation boards that employ an STM32 microcontroller and Black Magic Probe JTAG/SWD programmer. Like for example Lisa/M, Lisa/MX, Lisa/S, Apogee and so on.

Step 1

If you did not already do that, download and install GCC ARM Embedded. You might have already done it if you were “fixing” your Discovery board.

You can download the compiler from here: https://launchpad.net/gcc-arm-embedded

Unpack it into your home directory:

cd ~
tar xfvj ~/Downloads/gcc-arm-none-eabi-replace this with the version-mac.tar.bz2

You should add the binary directory of the newly unpacked compiler package to your system. Obviously to do this you add the directory to your PATH environment variable. If you don’t know what that is you should learn a bit more about your Unix/Linux basics. 🙂

export PATH=~/gcc-arm-none-eabi-someversion/bin:$PATH

To make this addition persistent you can also add that to your .profile, .bash_profile or .zprofile depending on the shell and setup you use.

Step 2

Download libopencm3-examples. You can find this repository at https://github.com/libopencm3/libopencm3-examples

git clone git@github.com:libopencm3/libopencm3-examples.git

Step 3

Build the libopencm3 examples. The repository contains libopencm3 as a submodule so you will have to initialize and update the submodule before you can compile the library itself as well as all the different examples.

cd libopencm3-examples
git submodule init
git submodule update
make

This will take a bit as there is a lot of examples included in that repository. In the past the examples were part of the main library itself but there became so many of them that we had to split it off. Otherwise the build and clone process just took too long.

Step 4

Prepare your environment. To make your life easier you should set up your .gdbinit configuration file. This will make the firmware upload and debug process so much easier. Just add the following lines to the .gdbinit file:

set target-async on
set confirm off
set history save
set mem inaccessible-by-default off
tar ext /dev/cu.usbmodemSOMESERIAL1
mon version
mon swdp_scan
#mon jtag_scan
att 1

Note: On linux the cu.usbmodemSOMESERIAL1 becomes ttyACM0.

For reference here is the breakdown of what the commands inside of the .gdbinit file mean:

  • set target-async on: Enable background execution commands.
  • set confirm off: This disables the really annoying “are you sure” questions. 🙂
  • set history save: This forces GDB to save the command history.
  • set mem inaccessible-by-default off: This is one of the most important commands here. Very often when you are trying to debug your code on a microcontroller you have to read the content of memory mapped registers. If you don’t set this option the debugger will prevent you from doing so as it has no idea that this memory is actually accessible. On a PC having the option on makes total sense but on a microcontroller it is mostly a burden.
  • tar ext /dev/cu.usbmodemSOMESERIAL1: tell gdb to connect to Black Magic Probe
  • mon version: Print version of the Black Magic Probe.
  • mon swdp_scan: Scan for devices using SWD protocol.
  • att 1: Attach to the first process. On a microcontroller you will have only one process…

Step 4

Upload fancyblink example. The simplest example for the STM32F4 Discovery board is the fancyblink example. It is also very easy to upload. As long as your Discovery board is “fixed” and uses the BMP firmware.

cd examples/stm32/f4/stm32f4-discovery/fancyblink
arm-none-eabi-gdb fancyblink.elf
load
run

Now the LEDs on the Discovery board should be blinking. You can interrupt the execution of the program by pressing <Ctrl>-C. You can continue the execution by running cont.

Here is a short reference of GDB commands that you might find useful when playing around with code:

  •  load -> load the binary from the provided elf file. (Note: it detects if the elf file changed on the hard disk and loads a new one if available. So you don’t have to quit GDB every time when you recompile your code)
  • run -> start the execution of your firmware
  • backtrace -> print the call stack trace of the current line of code being executed
  • make -> runs make command in the directory you started gdb. Very useful if you want to update the binary you are running really quick.
  • break filename:lineno -> you can add a breakpoint inside your code. GDB will stop the execution of the program as soon as the line is hit by the firmware.
  • step -> execute one single line of code and return back to the command line
  • next -> same as step but it does not enter into the functions called and skips them. Useful if you want to step over functions you know take forever and you are not interested in what they are actually doing. 🙂
  • print variablename -> print the content of a variable
  • print/x variablename -> print the content of a variable as HEX
  • list -> prints the context of the line being executed at the very moment
  • kill -> if used in a GDB script it will reset the MCU and exit GDB. Very useful as last command of a GDB script.

I hope this will be helpful for you.

Cheers,
Esden

P.S. Big thanks to Jack Ziesing for proofreading and introductory paragraph and sparking the work on this article. It is a great help! 🙂

Black Magic Discovery

2 Replies

Hey everyone!

Today I had to fix another STM32F4 Discovery board. By fixing I mean replacing the STLink firmware with Black Magic Probe firmware. I do that on a semi regular basis but as I have not done it in a long time I did not remember the process anymore. Obviously this calls for a blog post with some step by step instructions on how to do it, so that I have a reference in the future. Also you might find it useful yourself.

First of all let’s explain what we are trying to do. The objective is to replace the STLink SWD (Serial Wire Debug) firmware with Black Magic Probe firmware.  The board is setup by default to use a smaller chip to run the STLink firmware to talk to the main stm32.  We need to change the smaller chips firmware.  The initial adjustments to the board are needed to be able to access the programming pins of the smaller chip and replace it’s contents to Black Magic Probe firmware so that we can use GDB (GNU DeBugger) to program and debug the board instead of the very unstable and unreliable proprietary STLink protocol. The adjustments needed to access the small chips programming pins need to be reversed once the firmware is changed to Black Magic Probe firmware, resulting with an stm32 f4 discovery board with Black Magic Probe firmware ready to use.

For the “Fixing” process I use a genuine Black magic probe, I have one of those very early ones with a 0.1″ header that is very useful in this particular case. You can also use a Black Magic Probe Mini with a PCB adapter, make an adapter cable or you can use another Discovery board that has already been “fixed”.

Step 1

First step is to change the two solder jumpers on the bottom of the discovery board.

Jumper modification for SWD programming.

Jumper modification for SWD programming.

Remove the 0Ohm resistor/jumpers marked with red circles, and close the jumpers marked with blue circles.

Note: The easiest way to do that is to use a soldering tip, add a bunch more solder over the resistor and swipe them of. After that is done use solder wick to make sure there is no short on the “red” jumper. You can discard the 0Ohm resistors. It is much easier to just add a small blob of solder to close the “blue” jumpers, it is easy to remove them later in the process by just using some solder wick.

Step 2

Remove the SWD and slave MCU jumpers as indicated by the red circles in the photo.

STM32F4 Discovery board Jumpers for updating the programmer chip firmware

STM32F4 Discovery board Jumpers for updating the programmer chip firmware

Step 3

Attach jumper wires to the Black Magic Probe header.

Black Magic Probe Serial Wire Debug connections for Discovery board "fixing"

Black Magic Probe Serial Wire Debug connections for Discovery board “fixing”

Standard JTAG/SWD 20Pin 0.1″ header

  • Black wire – Pin 14 (GND)
  • Orange wire – Pin 9 (TCLK/SWCLK)
  • Yellow wire – Pin 8 (TMS/SWDIO)

In case you are trying to figure out which pins these are on a standard ARM Cortex 10Pin 0.05″ header. Here you go:

Standard JTAG/SWD Cortex 10Pin 0.1″ header

  • Black wire – Pin 3, 5 or 9 (GND)
  • Orange wire – Pin 4 (TCLK/SWCLK)
  • Yellow wire – Pin 2 (TMS/SWDIO)

Step 4

Attach the Black Magic Probe to the discovery board.

STM32F4 Discovery board Serial Wire Debug connection for "fixing" the on board programmer firmware

STM32F4 Discovery board Serial Wire Debug connection for “fixing” the on board programmer firmware

  • Black wire (GND) – Pin 3 of the SWD (CN2) header
  • Orange wire (SWCLK) – Pin 2 of the ST-LINK/DISCOVERY (CN3) header
  • Yellow wire (SWDIO) – Pin 4 of the ST-LINK/DISCOVERY (CN3) header

Step 5

Now you can connect the discovery board and the Black Magic probe to your computer via USB. The order should not matter, but usually I tend to connect the usb wires to the laptop before connecting the SWD wires between the two devices, just to make sure we don’t have some strange current loop that powers one or the other via IO pins, which might be problematic.

Step 6

Now we turn our attention to the software. You can obviously do these steps before you wire everything up but this is the order I followed.

The process requires a few dependencies that you should install using either apt on Linux or homebrew or macports on OS X:

  • Python
  • pyserial

In my case I use OS X and homebrew so I needed to run the following two commands:

brew install python pip install pyserial

Step 7

Download and make the an arm gcc compiler “findable”. I recommend using GCC ARM Embedded as it is maintained by the ARM developers themselves and they seem to generally know what they are doing. 🙂

So download it from here: https://launchpad.net/gcc-arm-embedded

Then unpack it into your home directory:

[code language=”text” gutter=”false”] cd ~ tar xfvj ~/Downloads/gcc-arm-none-eabi-replace this with the version-mac.tar.bz2 [/code]

Then you should add the binary directory of the newly unpacked compiler package to your system. Obviously to do this you add the directory to your PATH environment variable. If you don’t know what that is you should learn a bit more about your Unix/Linux basics. 🙂

export PATH=~/gcc-arm-none-eabi-someversion/bin:$PATH

To make this addition persistent you can also add that to your .profile, .bash_profile or .zprofile depending on the shell and setup you use.

Step 8

Download blackmagic firmware source code. You can get it at https://github.com/blacksphere/blackmagic

The easiest way is to clone the github repository, look for the small window at the center right of the github page for the git repository url. If you have a github account choose the ssh url but if you refuse to do so then you can go with the https one too. 🙂

If you did not learn about GIT and GitHub yet this is the perfect time to take a break from all of this here and come back after you have caught up on your homework. 😀

git clone git@github.com:blacksphere/blackmagic.git

Step 9

Now let’s build the firmware. This consists of three steps:

  1. Fetch the libopencm3 submodule
  2. Build from the toplevel so libopencm3 is built
  3. Build the blackmagic firmware for the stlink
cd blacksphere
git submodule init
git submodule update
make
cd src
make clean
make PROBE_HOST=stlink

Step 10

We can finally connect to the hardware we wired up before and erase the pesky stlink firmware. When the discovery boards ship, the firmware is read and write protected on the STLink chip. So to be able to overwrite the firmware we will have to unlock the chip. Thanks to Gareth there is a small python script that can do that for us. You just have to call the following command inside the src directory of the blackmagic repository and it should be able to remove the write protection:

../scripts/hexprog.py -s -d /dev/cu.usbmodemSOMESERIAL1 -r blackmagic.bin

In the case you are on Linux you can leave out the -d device parameter. For reference the -s parameter tells hexprog to use Serial Wire Debug instead of JTAG and -r tells it to unlock and erase the target chip.

If you skip any of those two parameters it will not work for you.

Step 11

Flash the bootloader. We are getting very close. To upload the blackmagic bootloader you use arm-none-eabi-gdb.

arm-none-eabi-gdb blackmagic_dfu
target extended_remote /dev/usbmodemSOMESERIAL1
monitor swdp_scan
attach 1
load
exit

This sequence of commands attaches to the virtual gdb server that is provided by the Black Magic Probe on it’s virtual serial port 1. (The second serial port is the USB to serial interface located on the back of the BMPM) We then tell the monitor (this is the BMP) to scan using Serial Wire Debug as our protocol. Next we attach to the virtual process number 1. (As we are on the embedded systems there usually should only ever be 1 process unless you run an RTOS) We load the firmware from the elf file that we passed on to gdb earlier and exit GDB.

Simple right? 😀 (Believe me that is definitely simpler than setting up and making OpenOCD work with Eclipse)

Tip: To make things easier for the future you can add the following to your .gdbinit file:

set target-async on
set confirm off
set history save
set mem inaccessible-by-default off
tar ext /dev/cu.usbmodemSOMESERIAL1
mon version
mon swdp_scan
#mon jtag_scan att 1

Note: On Linux the cu.usbmodem device name will be /dev/ttyACM0 instead.

After setting up the .gdbinit file the upload process becomes quite a bit shorter:

arm-none-eabi-gdb blackmagic
load
exit

Step 12

Upload the black magic firmware itself. Here you have two options. Either you can use the same process as before using GDB or you can use the now uploaded DFU bootloader to upload the Black Magic Probe firmware payload. Using GDB you would run the following:

arm-none-eabi-gdb blackmagic
target extended_remote /dev/cu.usbmodemSOMESERIAL1
monitor swdp_scan
attach 1
load
exit

Alternatively you can upload the firmware using a DFU script. Before you do that though you should disconnect the genuine Black Magic Probe from your computer as you want to make sure the script flashes the Discovery board and not your BMP. To do that you will need to install python libusb as an additional dependency. But having done that you can then run the following to upload the firmware:

./scripts/stm32_mem.py blackmagic.bin

Step 13

Put everything back together. Now you just have to do four things:

  1. Disconnect your Black Magic Probe and Discovery board from your computer as well as each other.
  2. Remove the solder blobs you have added on the back of the board.
  3. Add solder blobs to where you removed the resistors at the very beginning.
  4. Put the jumpers back to where they were on the front of the Discovery board.

You are pretty much done now. If everything went well you should have your “fixed” discovery board. Follow to the one additional step below to test that.

Step 14

Plug in your Discovery board into your computer. The dual color led next to the USB connector should be solid Green. If it is blinking Green it means the bootloader is running and the board is expecting to be flashed with the firmware. This can happen if you still have the power jumper disconnected that provides power to the “slave” STM32F4 chip. This is actually very useful if you want to upgrade the Black Magic Probe firmware on your discovery board. 😀

Additionally if everything went well if you are on Mac OS X a /dev/cu.usbmodemSOMESERIAL1 and /dev/cu.usbmodemSOMESERIAL3 should appear. If you are on linux you should be able to find ttyACM0 and ttyACM1 in the /dev directory.

I hope this write up is useful for you and the future me. 🙂 I am planning to write another blog post on how to build and upload an example firmware onto the slave processor. So hold on to your hats! 🙂

Cheers,
Esden

P.S. Big thanks to Jack Ziesing for proofreading and introductory paragraph and sparking the work on this article. It is a great help! 🙂

Lisa/S, SuperbitRF, 1 BIT SQUARED

2 Replies

Hi everyone,

Again it was a while since I posted something here. I just wanted to write a quick update on what I’ve been up to lately.

I am working very hard on Lisa/S and SuperbitRF. The goal of the project is to develop the smallest and lightest possible UAV controller system without compromising functionality.

lisa_s_top

The Lisa/S board is only 20mm x 20mm and weighs about 3g with a lot of integrated sensors.

  • 3 Axis Gyroscope
  • 3 Axis Accelerometer
  • 3 Axis Magnetometer (Compass)
  • Barometer (Altimeter)
  • GPS Receiver

Just like Lisa/M it’s bigger sister. Lisa/S is powered by the STM32F103 ARM 32bit microcontroller. Providing quite a lot of processing power for your UAV needs. On top of it all the board has 4 MOSFET solid state switches. They make it possible to use the board directly on the tiny brushed motor quadcopters, nano helicopters and fixed wing airplanes. I am quite excited how much I managed to put onto that tiny footprint. Usually much bigger boards don’t even include a GPS receiver on the board.

Another feature of Lisa/S that I think is worth mentioning is that it has a CYRF footprint.

CYRF is a module that I developed as part of the system. It contains the CYRF6936 2.5GHz transceiver chip. It is connected to the MCU on Lisa/S through SPI. The particular transceiver is the one at the heart of all the Spektrum transmitter and receiver systems and many others like Walkera Devo. It is very exciting because we have direct access to that chip from the autopilot and can implement compatibility to a lot of 2.4GHz RC gear available out there.

Our current software implements support for some Spektrum RC transmitters and as a bonus we can simultaneously connect to a laptop using the USBRF dongle. This removes the need for having two radios on your vehicle thus saving weight.

All of these items are currently available for pre-order in the 1 BIT SQUARED shop. We are working on finalizing the production process of the first batch of Lisa/S, CYRF and USBRF. We are projecting they will be available in the shop by the end of May. We have put a lot of effort into making these boards, if you are interested you can read more about it in the 1 BIT SQUARED blog.

Last but not least 1 BIT SQUARED is my own company that I founded early last year. I want to develop and produce hardware and software that I am excited about and would like to share with others that are interested in the field of airborne robotics. If you like open hardware and software and want to support me directly the shop is the most direct and easiest way to do so.

Cheers,
Esden

Black Magic

Leave a reply

A few months ago I met a great guy Gareth MacMullin in the libopencm3 channel. He was working on a new Open-Source and Open-Hardware JTAG solution called Black Magic Probe(BMP). I got one of those and instantly fell in love with it.

OpenOCD is great in a sense because it supports lots of targets and probes but that is its disadvantage too. It is very often difficult to set up and tends not to work properly in many cases. The approach of BMP is quite different. Instead of the probe being quite dumb and using OpenOCD to do the JTAG magic the BMP uses a microcontroller (STM32F1) and implements a GDB server inside the controller. This solution cuts out the middleman and talks JTAG as well as the new Serial Wire Debug (SWD) protocol itself. Requiring only a working GDB on the computer.

The BMP supports several Cortex-M3 targets and more devices are being added fairly quickly. The first time I tried it with an STM32 it just worked. No command line parameters just:

arm-none-eabi-gdb some_elf_file
target extended-remote /dev/ACM0
mon swdp_scan
att 1
load
run

It shocked me how fast the loading process was. Because it is not one of the FTDI chips and does not have to bitbang all of the JTAG protocol over USB it can run much much faster. I know there are commercial devices like JLink that have logic inside them but they cost arm and a leg if you don’t want to just get the educational version of it.

One more thing comes to mind when you realize that the BMP supports SWD. You only need three pins to be able to use it GND, SWDIO and SWCLK. That decreases the required real estate on the PCB significantly. I am not sure what the status of OpenOCD support for SWD is now but it is work in progress as far as I understand. On BMP it just works.

Since I started using the BMP there were several interesting developments that Gareth added. The BMP is not only offering one serial port for the GDB extended remote interface but also a second one providing a TTL level UART interface. The BMP also supports tracing by now using the TRACESWO pin. This provides a reasonably high speed tracing. Gareth also wrote a plotter for this feature that plots the contents of traced variables in your code.

Early versions of BMP were 2.5cm X 5cm the current version called Black Magic Probe Mini (BMPM) is smaller, the same size as the FLOSS-JTAG I made a while ago, it is mere 1.5cm X 3cm, packing in all the power of the BMP what makes it great for doing embedded stuff on the go, for example in the subway.

So to wrap things up, it is a high grade, Open-Source and Open-Hardware device. For $60 this thing is a steal!

Shameless plug: On 1 BIT SQUARED store you can order the Black Magic Probe.

There are also some other distributors listed on the BMP page too. So check it out! I bet you will love it. 🙂

Quadshot – an aerobatic blend of RC quadrocopters and airplanes

Leave a reply


Hi everyone,

As you probably notice I am very busy lately. Together with some friends we were working on the Quadshot an aerobatic blend between a quadrocopter and an airplane.

It takes off and lands vertically like a quadrocopter as well as it can fly forward like an airplane using its wing to add additional lift extending flight time.

We submitted the project to Kickstarter and we are very happy to see that we got such a great response. The Kickstarter funding runs for another three days and if you pledge you can get a Quadshot at a discounted price as a reward.

At it’s heart Quadshot is using the avionics and software framework of Paparazzi. We developed the additional necessary controls for Quadshot and released them. So Quadshot has Open-Hardware electronics and Open-Source firmware making it a great platform for research and hacking.

Having an autopilot makes it also very easy to fly for a beginner RC pilot.

I hope to find some more time in the future to get into more details about Quadshot. But till then check out the following links:

Cheers Esden

Open-BLDC and the CLogic story

11 Replies

Castle ICE HV to Open-BLDC Mod Tutorial Step 10

Hi,

It was again a while since my last post, but as always I was quite busy. 🙂

The last news about Open-BLDC was about its V0.3 iteration. A lot has changed and happened since then. I was realizing that I am getting more and more inquires where people were asking about obldc being able to control very different sizes of motors, ranging from 12V and 10A up to 48V and 200A.

This requirement does not really ask for different logic and controls but it definitely asks for many different power stages. Open-BLDC was designed to be modular from the beginning but still to accomodate that kind of a power range it would be necessary to design and create quite a big lineup of hardware.

Around that time I had the opportunity to take a look inside a dead motor controller from Castle Creations just to realize that these guys seem to know what they are doing and that they went with a modular design too. To make a long story short I decided that it will be better to buy one of their of the shelf motor controllers and retrofit them with my logic. That is how CLogic was born.

As it seems other manufacturers are selling ESCs that have the same interface between the logic and the power stage too. Tekin for example. But my guess is that they are just OEM of castle themselves. But who knows. 🙂

Turingy also came out with an ESC that seems to have the same interface, the Turingy dlux. I ordered a few of them to take a look for myself and see if CLogic will fit in there. That would be a great source of cheep power stages. 🙂

CLogic has most of the functionality the Open-BLDC v0.3 had. Because of the size constrains I had to get rid of the dedicated i2c and PPM connectors, but I added isolation on the CAN interface that should provide additional safety when used on a 50V and bigger systems. The i2c and PPM interfaces are still available either over the new AUX connector or through the UART interface connector.

The new AUX connector gives the possibility of easily connecting encoders or hal sensors for sensored operation. So the interfaces stay very flexible with added flexibility due to the big variety of power stages you can use, while being very very compact.

Sure some people complained “The power stages are not Open-Source!!!”, yes that is true. Also these systems start at a higher power and weight class than some of you would want to operate them. That is why there is CPico Power. It is a very small, low power and a hopefully cheep power stage that we are putting together for those who want it all fully open! So no worries. 🙂

I think that wraps up the news about the new direction Open-BLDC is going. I hope you like it. I am looking forward to your comments.

Cheers Esden

FLOSS-JTAG V1.0 Released and Available

Leave a reply

Hey everyone,

As you might know some time ago I have developed a small JTAG adapter based on the FT2232H chip. I gave it the name FLOSS-JTAG as the idea was that it should be absolutely OpenSource and OpenHardware.

You can find the project at GitHub and some more info at it’s random projects wiki page.

FLOSS-JTAG not only has the high speed 24MHz FT2232H chip (there are some designs based on my idea that are using a low speed version of the same chip). It provides the new standard 0.05″ pitch 10 pin Cortex JTAG header as well as a TTL level serial interface on it’s second interface.

I am glad to announce that I have reached the V1.0 with it. All necessary files to make your own are in the GitHub repository. But if you don’t want to go through the pains of ordering PCB, sourcing parts, assembling QFN SMD packages you can also purchase it in the Joby Robotics online shop.

At Joby Robotics you get a cable assembly to connect the FLOSS-JTAG to a target. This allows you to debug and connect to targets that are difficult to reach otherwise. You also will get a cortex connector to old standard 20pin 0.1″ pitch connector adapter.

The adapter is small and will make it also easier to debug targets that are difficult to reach.

You can get precrimped Molex Picoblade wires in 10 different colors at Joby Robotics too. This way you can easily build a UART cable that connects FLOSS-JTAG to a device.

I am very happy that FLOSS-JTAG is finally easily accessible to anyone who needs it.

FLOSS-JTAG works perfectly together with Openocd and Summon-ARM-Toolchain.

Cheers Esden