Tuesday, October 4, 2016

STM32CubeF4 gcc makefile example for FreeRTOS

Following along from my earlier blog post STM32CubeF4 gcc makefile example, I modified the Makefile to work with one of the FreeRTOS examples included in the STM32CubeF4 (v1.13.0). This particular example flashes some LEDs on the STM32F469 Discovery board. The biggest wrinkle I ran into was having to add an _exit function. I grabbed a syscalls.c from elsewhere in the STM32CubeF4 tree and #if 0'd out some timezone functions which were failing to compile. You can find my repository with the Makefile, syscalls.c and instructions here.

Thursday, July 14, 2016

Bringing up MicroPython on the GHI Electronics G30TH

I noticed that GHI Electronics makes a number of devices using the SM32F4 fmaily of processors, which also happens to be supported by MicroPython.

The G30TH caught my eye, which is basically a breakout board for the STM32F401RET6 which has 512K of flash and 96K of RAM.

Provide 3.3V

The board includes a USB connector, but doesn't include any onboard regulator, so you'll need to provide 3.3V to power the board.

I happened to have a Pololu 2842 in my drawer, so I decided to use that.

Being paranoid, I put a piece of kapton tape over the bottom of the regulator since it would be coming in contact with the metal housing on the USB connector. The Kapton tape makes the white silkscreen look yellow in the photo below:

While I still had access, I soldered a piece of wire to the VIN signal on the regulator, and then I soldered 2 header pins to the 3V3 and GND pins:

VOUT on the regulator connects to 3V3 on the G30TH, and GND on the regulstor connects to GND on the G30TH. The red wire connects from VIN on the regulator to V+ on the G30TH. V+ on the G30TH connects to VUSB on the USB connector.

Now if you plug in the USB connector, both the PWR and USB LEDs should light.

Build the firmware

You can grab the micropython source code using git:
git clone https://github.com/micropython/micropython.git
and then install the G30TH board defintion into the tree:
cd micropython/stmhal/boards
git clone https://github.com/dhylands/G30TH.git
cd ..
Finally, build the firmware (from within the micropyton/stmhal directory):
make BOARD=G30TH

Get the Board into DFU mode

I used a wire jumper to connect from 3V3 and pressed it on the B0 (BOOT0). Since I used a female to female jumper wire with a single header pin plugged in one end:

I also used a short 6" USB cable to plug it into a USB extension cable. I found plugging the 6" cable into the extension to be quite a bit easier than plugging into the Micro B connector on the board. I could then hold the jumper on B0 with one hand and plug the USB cable into the extension with the other and get the board into DFU mode.

With the board in DFU mode, lsusb should show an entry like this:
Bus 001 Device 014: ID 0483:df11 STMicroelectronics STM Device in DFU Mode
and running dfu-util --list should report something like this:
$ dfu-util --list
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [0483:df11] ver=2200, devnum=14, cfg=1, intf=0, alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="377A364D3234"
Found DFU: [0483:df11] ver=2200, devnum=14, cfg=1, intf=0, alt=2, name="@OTP Memory /0x1FFF7800/01*512 e,01*016 e", serial="377A364D3234"
Found DFU: [0483:df11] ver=2200, devnum=14, cfg=1, intf=0, alt=1, name="@Option Bytes  /0x1FFFC000/01*016 e", serial="377A364D3234"
Found DFU: [0483:df11] ver=2200, devnum=14, cfg=1, intf=0, alt=0, name="@Internal Flash  /0x08000000/04*016Kg,01*064Kg,03*128Kg", serial="377A364D3234"

Unprotect the device

The firmware on the G30TH is protected, so the first thing that needs to be is to unprotect the device.

IMPORTANT: Once you unprotect the device (which will erase it) there's no going back to the .NET firmware that came with it (since I don't believe that firmware is distributed anywhere). So don't expect to "try" MicroPython and go back to using .NET later.

The device can be unprotected using dfu-util:
dfu-util -s :unprotect:force -a 0 -d 0483:df11 -D build-G30TH/firmware.dfu
Note that DFU requires the -D option even though it won't be using the firmware file. Unprotecting the device has the side effect of erasing it.
$ dfu-util -s :unprotect:force -a 0 -d 0483:df11 -D build-G30TH/firmware.dfu
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Deducing device DFU version from functional descriptor length
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Device disconnects, erases flash and resets now
Unprotecting the device also resets the device, so you'll need to put it back into DFU mode once more.

Flash MicroPython

Now that the device is back in DFU mode once again, we can flash MicroPython:
make BOARD=G30TH deploy
If you've never flashed MicroPython before, there may be additional steps required. The wiki page for programming the STM32F4 Discovery Board should have the information required.

Once MicroPython has been programmed, then you can use your favorite terminal program to open /dev/ttyACM0 and get a REPL: (I often use usb-ser-mon.py)
$ usb-ser-mon.py 
Waiting for USB Serial Device ...
USB Serial device with vendor 'MicroPython' serial '377A364D3234' connected @/dev/ttyACM0
Use Control-X to exit.
MicroPython v1.8.2-13-g08eac74 on 2016-07-14; G30TH with STM32F401CE
Type "help()" for more information.

Sunday, February 21, 2016

Raise3D N2 - Custom Spool Holder

The filament spools that came with my Raise3D printer are 200mm in diameter, 70mm thick, and have a central hole about 55mm in diameter.

I happen to have alot of spools of PLA which are 162mm in diameter, 85mm thick, and has a central hole diameter of 31mm.

Needless to say, my spools won't fit on the N2 spool holders. So I went and designed a spool holder using OnShape. I put the files on thingiverse and on my github account.

This shows the spool holder mounted in the printer:

And with a spool on it.

I can't close the door with this spool holder mounted, but that isn't really an issue for PLA.


As I notice people creating variations, I'll include them here:
Shorter 65mm shaft

Setting the date, time, and timezone on the Raise3D N2

UPDATE: It turns out that later versions of the firmware now have the ability to set the timezone, date and time. I currently have version installed. To change the timezone, click on the little gear icon in the upper right corner, which will bring up "Settings". Then chose the "Other" category and finally, "Date & Time". You need to press on the > over on the right hand side.

Touch the > over on the right of the Timezone line, and then in the search box start typing the name of your time zone city. You can find a list of time zone cities here (note that this list has the timezone name shown first).

I start to type van and then clicked on "Vancouver, Pacific". Once entered, then press the back < and then enter the date and time.

Restart (either by using Settings -> Machine -> Restart, or by power cycling) and your timezone and date/time should be correct.

The following is the original blog post, which I'm keeping for reference.

This is a bit technical. If I glossed over something, feel free to ask questions. Hopefully the good folks at Raise3D will fix their firmware to allow the date/time/timezone information to be entered.

I noticed when printing files from the sdcard or MMC card, that the time was being reported in UTC, and that the timestamp on internal files was from 2015.

Since you can ssh into the root account on the printer, I decided to see if I could correct this. The printer uses busybox, but it appears to be using glibc rather than uclibc.

With glibc, you can set the default timezone by making /etc/localtime be a special timezone file or a symlink to a special timezone file.

I run Ubuntu on my desktop, and it had an /etc/localtime which was a file (not a symlink). It mostly contains binary data (if you do a hex dump you'll see your timezone strings buried in there). For convenience, I put a copy of the /usr/share/zoneinfo directory tree in my github account. Many of the files are symlinks. For example, I normally use America/Vancouver as my timezone, and if I find that file, it shows ../Canada/Pacifc and ../Canada/Pacific is not a symlink, but a real file. So I downloaded the Canada/Pacific timezone file to use as my timezone file.

First thing to do is to verify your current timezone:
ssh root@
replace with the IP address of your printer. In my case it showed UTC as the timezone and a year of 2015.

I entered Control-D to quit from the ssh sesseion and then copied the Canada/Pacific file from my github repository (download the raw file) to the /etc/localtime file on my printer:
scp Pacific root@
Now restart the printer. If you now ssh into the printer then the date command should show the correct timezone, but will still show the incorrect time. You can correct the time by ssh'ing back into the printer and using the date command. To set the date, you need to call date with a bunch of numbers in the format MMDDhhmmYYYY where MM is the 2 digit month, DD is the 2 digit date, hh is the 2 hour time (in 24 hour format), mm is the minute, and YYYY is the 4 digit year. For example:
186 >ssh root@
root@raise3d:~# date 022023562016
Sat Feb 20 23:56:00 PST 2016

Tuesday, February 16, 2016

Raise3D N2 Printer - Unpacking and First Print

I ordered a Raise3D N2 printer as part of a KickStarter campaign. All of the Canadian orders were container shipped to the good folks at filaments.ca and then shipped out to individuals.

Mine finally arrived. Wow, that's a huge box (about 28" x 29" x 32").

It was fairly easy to unpack. My outside door is 36" so it came in through that easily, but with the cardboard cap and bottom on, it wouldn't quite fit through a 30" door opening (at least not without removing the door), so I unboxed it in the hallway and then moved it. The printer was very well packed, and the cardboard only had minor gouges and scratches on the bottom.

The buildplate was covered in BuildTak, but they didn't do a very good job applying it. Mine had at least a dozen bubbles on it. I used a rounded piece of plastic to smooth out the bubble and pricked each one with a pin to allow the air to escape.This photo was taken from the back (glass side).

Here's a photo from the BuildTak side before I removed the bubbles. It probably took me half an hour or so to remove all of the bubbles.

IdeaMaker (Raise3D's slicing software) is currently only available for Windows and Mac (they claim that a Linux version is forthcoming - I hope). I had to install windows on one of my laptops so I could run IdeaMaker. I tried running in a VM, but it immedialtely crashed. As far as I can tell, you can use any slicing software you like, so you should be able to use other slicers as well.

Here's a video of my very first print. I normally don't print a raft, but it seems to have added one. I expect that this is just a setting in the software someplace. I decided to do a Marvin as my first print. I made no adjustments to the printer before printing this. I upgraded to the dual extruder option, and my printer came with one spool of red PLA and one spool of yellow PLA. I printed the Marvin using the red PLA.

The printer comes with a builtin touch screen. Here's a shot while it was part way through printing.

The windows software can connect to the printer over the network and upload files to internal storage. It turns out you can ssh into the printer too. The printer contains a processor running linux to manage the network and touch screen, and also has a processor for doing the realtime control. Unfortunately, the root account on the linux side of things has no password (which is bad). If you set a root password, then the windows software will no longer connect remotely to the printer. Hopefully, they'll add an option to use passwordless ssh login so that I can set a root password.

Here's a shot while printing.

The build platform has 2 leadscrews, one on the middle of each side.

A shot through the front door, while printing.

The finished print. I let the build plate cool down to about 29C and was able to remove the Marvin by hand. This was sliced using medium settings (0.15mm layer height) in the IdeaMaker software.

A shot of the teeny tiny Marvin in the middle of the build plate (you can supposedly print 12" x 12" x 12").

Marvin removed from the build plate. I was able to remove the Marvin from the raft by hand.

The filament cooling could definitely be improved. There were some droops on the back due to insufficient cooling. Fortunately, it looks like it will be possible to wire in an additional fan or 2. I recommend signing up for the Raise 3D Mailing List. There have already been several mods posted.

That's all for now. I look forward to using this more.

Sunday, April 26, 2015

OX - More clamps and a TinyG firmware issue

I printed some clamps and knobs on my 3D printer:

I put them together like this:

You can find the stl files here, and the original OnShape CAD files here.

I used a cut piece of 1/4"-20 allthread for the stud. I used a punch to damage the bottom thread so the stud would stop at the bottom:

 This shows the stud being stopped. If it works its way through, I just bang on it some more!

4 clamps seems to work quite well for holding sheet stock down.

I started to cut a larger piece and my z-axis wound up dropping as it was cutting. I forgot to take some photos, but this was the aftermath:

After some vacuuming:

This was caused because the z-axis stepper was disabled while it was cutting, and then the cutting forces wound up pulling the head deeper and deeper into the cut.

I was running TinyG firmware version 438.02. I hooked up an LED to the Z-axis enable line on the TinyG board and sure enough, I could see the stepper driver being disabled while X & Y were still moving. I had the power management setting for all 4 motors set to 2, which is supposed to keep the motor enabled while any other axis is moving.

I asked about this over on the ChiliPeppr Google Plus group and it seems it was a firmware issue. So I downloaded the 440.14 firmware, flashed it, and immediately lost all of my settings. Sigh.

That created another diversion, and I went off and wrote a python program for archiving, restoring and viewing configuration files. You can find Config.py here. I've only tested it under linux, but it should work under Windows and Mac as well. Let me know if you have any suggestions, comments, issues, etc.

With the new firmware installed and my settings restored, I was able to cut the piece, and the z-axis stepper stayed energized through the entire cut. Here's a short video of the start of the cut:

That was cut with 1.5mm depth of cut 800 mm/sec travel, and max RPM (which I believe is around 12,000 RPM). This was the finished cut.

The flip side was white vinyl, and since I was using an up cut endmill, I put the good side down so it would have a clean edge:

That's all for now.

Saturday, April 11, 2015

Spray Can Tube Clip

I seem to forever lose those little (often red) tubes that come with my spray cans (normally with lubricant os some sort).

I've tried using elastics, but they often seem to disinegrate, so I decided to print something that would hold the little red tube instead:

Just stick the tube in:

and clip it to the can:

I created the file in OpenSCAD, and set it up to that you can easily customize various parameters (most likely can diameter and tube diameter, plus a few more). You can find the files on thingiverse.