Andrew Olson

I've recently got pretty interest in building my own brushless motors.  So over the past week or so I've collecting stators out of DC motors that I thought I would use but never have.  They are only 3 tooth stators.  That means that they will be very simple to wind and won't have the best performance.  I'm not to concerned about that at the moment.  I'm more interested in building a few and seeing how different windings(# of turns and wire gauge) affects their performance.

Some stators: (from left to right) 12 tooth that I found in the Mechatronics Lab last year, small 12 tooth(6 useable) from an old HDD, three 3 tooth from some DC motors, super thin 12 tooth form older HDD.   You can also see part of a ST Discovery board I just got.

I narrowed down my stator selection to the above.  Most of the 3 tooth stators were to small to make into reasonable outrunners.  I also pulled to more stators out of some old HDD motors. 

I need to head out the Electronics Flea Market at De Anza and pick up a bunch of CD-ROM Drives to get some more useful stators.  Those drives seem to have a good supply of stators.  Lots people use them for RC airplanes and they are a lot of good threads on rewinding them on RCGroups.

I might experiment also with building my controller and implementing different control schemes.

Time to buy a bunch of magnets and wire, and start machining!

I've been working on a GameBoy Cartridge memory dumper for the past month or so.  A cartridge memory dumper reads the memory from the cartridge and saves it an external file.  It is a way to make backups of cartridge based games.  There are two types of memory that can be read, ROM and RAM.  ROM is well the ROM.  It's Read Only Memory.  The game and other data like sprites are stored in ROM.  RAM is where game saves and runtime data is stored.  Below is my journey to dump the memory of my Pokemon Red cart.  I also have a pretty neat idea on how this could be used in another way but that's for a another project post. 

Hardware

I'm using the Cygni Dev board from TehoLabs for this project.  This project is a way to help me learn some more about TI's LM3S MCUs.  I also have a GameBoy cartridge connector that I pulled out of an GBA that my friend gave me.  The connector has 32 pins.  It has 16 address pins,8 data pins, read, write and a couple other pins. To interface the MCU with the connector, the Cygni has enough pins to connect each pin on the connector to a pin on the MCU.  If I used a MCU with a smaller pin count, I could have used shift registers or some I/O expander in order to connect all the pins.

Software

One of my goals for the software of this project was to make it very portable.  I accomplished this by having one file that handled the high level dumping and communication and another file that handled hardware interfacing; specific addressing/data lines, UART and MCU initialization.  That one if someone wanted to port it to another MCU all they would have to do is change 4 to 5 functions that deal with previously mentioned things.

The hardware file deals with serial com and controlling the I/O pins like I mentioned before.  This was handled very easily with the use of the StellarisWare software library.  A vast majority of the hardware level software that you would normally write for a MCU has already been written for you.  StellarisWare has drivers for all of the periphals, to use them you just have to find the right functions to use rather than digging through the data sheet to figure out what to set the correct registers to.   To continue on, the readCart and writeCart functions set address lines to the given address and either read the data at that address or write to the address.  The initialize function is straight forward and just initializes the hardware that is used.  The UART functions are just wrappers for the StellarisWare functions so that the main program file can be platform independent.

The main file sits in a loop waiting for commands from the PC side program.  Once it receives a command it executes that command.  The scan command, reads certain memory location on the GameBoy cart to get information like ROM size, RAM size, Game Tile, Cartridge type.  The ROM size is used to determine how many 16k Banks the cart has.  The number banks is used latter when dumping the ROM to switch ROM banks the correct number of times.  All of the scanned information is sent back to the PC side program, mostly for debugging purposes.

-> Code as a Gist <-

Results

I ran the the scan function from my Python script and it came back with the correct info on the first run!  That made my confident that the whole dump would work, so I ran that command.  I had to wait around 30-60 seconds for the whole dump.  SLLOOOW! Anyway when it finished I took a look at the ROM in my text editor.  Everything looked correct to me however when I tried to run it in a GameBoy Emulator nothing happened.  So I compared the ROM I had dumped with one I downloaded.  It turned out that for reason I wasn't reading the 8th bit of the data bus.  After a little digging through my code at first and then the MCUs datasheet, I found that that pin(PB7) requires unlocking in order to change its configuration.  So it was stuck as an output and never changing to an input.  I didn't feeling like figuring out the unlocking sequence but luckily I had one extra pin.  I switched the upper data bus bit to that pin and added code to read/write that pin.

With those changes I tried dumping the ROM again.  This time it did read the upper bit and the dumped ROM matched the one I had downloaded.  It also ran in the emulator as you can see in the following picture.

Success!

 Pokemon is the only GameBoy Game I have so I can't really test it with any other games.  I some GBA games but I'd have to rewrite the program to read those.  I might do that down the line depending on the complexity.

With this under my belt, I'm thinking about making a SNES Flash Cart or something else that relates to videogames.  Most likely something else because a Flash Cart would be intense but it would be a good learning experience.

Oh I finally got an edge finder for my mill and an indicator for my mill/lathe.  So expect some projects soon.

So for the past 2 years I've had a CD stuck in the head unit of my car and it doesn't have an external input.  Long story short, I wanted a simple amp that takes external input that I could use in my car or in the garage, so I designed a board using the TDA7381 amp chip.

The TDA7381 is 4ch 30W amp that is meant for car audio applications.  It won't pump out the full 30W at car voltage levels but that is alright.  Any way the circuit is simple and has a low component count.  I made one or two changes to the app circuit per this site.  Here it is.  Any suggestions are welcome!!

I like things symmetrical, at least partially

I checked the DortbotPDX PBC order service(laen's) and it has been majorly revamped!  It is now OSHPark.com and it looks great!  The interface is super nice and I love how it lets you upload eagle files, then shows you every layer from the gerbers so that you can check to make sure everything is correct.  That feature and the awesome purple boards are what make it my favorite PCB fab house. 

I'm also making a sweet case with an integrated heatsink for it on my mill.

Some of you may remember some posts I made back in January about the Cygni Dev Board.  The posts turned out to be more focused on setting up OpenOCD and using the Bus Pirate as a JTAG programmer.  In this post I hope to cover how to flash a simple program onto the Stellaris LM3S3N26 ARM MCU.  This MCU line is made by Texas Instruments.

Back in January I successful got the Bus Pirate to work as a JTAG programmer and flashed the example blinky program from TehoLabs onto the Cygni.  I pretty much didn't touch the board until a couple weeks ago when I got interested in seeing if I could use the bootloader instead of the JTAG since it is cumbersome hooking up 6 wires from the BP to the Cygni to program it.  So I went through TehoLabs walkthrough and got to part where it says 'Hold User Switch and press Reset.'  I did that but pressing the user switch cause my whole board to shutdown.  Bad sign.  I figured out that when I pressed that switch it was shorting my board out.  Yikes!  So I examined the whole board trying to find the solder bridge/shorted connection.  I took a look at the data sheet and discovered that the pin that the user switch is connected to is right next to VCC.  I immediate looked at that area on the chip and sure enough there was a bridge between the pins.  I found it kinda funny that the bridge was on that particular pin.  I don't think I would have discovered that I had a bridge it it was on any other pin.

With that fixed I tried holding that switch while pressing reset to get into the bootloader.  I didn't get anywhere with that, the LED kept blinking.  I then realized that the bootloader TehoLabs was talking about was their own that would be programmed in Flash and not ROM.  I had never Flashed the bootloader onto my chip so pressing the user switch and resetting was not going to do anything.  *Face palm*

I researched some more about the ROM bootloader and found out that it runs when the chips Flash is empty.  It also runs if you program a register with a Pin and a level to check at start up, which is standard for other bootloaders.

In order to get the ROM bootloader working again I had to perform a mass erase using JTAG.  And then in order to keep the ROM bootloader working the first program I load onto the chip would have to be one that writes the correct valve to the BOOTCFG register.

I'm still very new to programming ARM processors but luckily the LM series ships with an insanely help library of functions, hardware drivers and utilities called StellarisWare.  Also they work across different chips, so porting code from another LM3S is cake.  They also have tons of examples which reduces the learning curve for programming ARM chips.  After a little google search I found some code to write for another chip that writes the BOOTCFG register.  It was written using the cross platform defines and functions so it would be a breeze to port.  It the post it had been confirmed to work.  I added the original blinky program to the code to get me some feedback as to whether or not it worked.  I compiled it with a version of TehoLabs' makefile that I have edited to help learn about makefiles.  I got a few errors but those went after I figured out what header files I needed to include.



So in order to flash this onto the board I used TI's LMFlash utility.  It has a pretty straight forward GUI; select the type of programmer, select the bin file and program.  That's what I did and the LED came on indicating that the BOOTCFG register had not been previously written to but my program had just written to it.  I power off reset the device and the LED went off either meaning that the chip went into the bootloader or skipped over the BOOTCFG code since it is now written.

To test this ROM bootloader out, I loaded the blinky example from TehoLabs with it.  It worked.  The chip got into bootloader mode and was programmed.

Main take-away points
- If the Flash is empty the ROM bootloader executes and you can use a simple serial adapter and LMFlash to program.
- Program the BOOTCFG register in order to be able to activate the ROM bootloader upon reset.
- Use the ROM bootloader to load programs or other styles of bootloaders
- Use JTAG if nothing else will work
- StellarisWare is really helpful

Onto ARM development!!