colotron

@@colotron The machine has an inherent resolution of 1200 dpi (~0.02mm) so I am able to work with 0.2mm tracks - however I use 0.25mm as default for most designs. The PCB outline (fom Edge.Cuts i KiCad) in the example board above is ~0.1mm. For consistent results I think presensitized boards will be the best choice. I am using Riston which is not always easy to attach perfectly - sometimes I have to touch up some tracks due to dust under the film causing breaks. So I think the practical limit is not what the machine is capable of but rather the properties of the emulsion used.
 
Etching is definitely a lot better than what I could achieve with toner transfer, and soldering is easier but could be due to the fact that I now add a solder mask which I also expose in the printer. The solder mask is cured at 140 deg. C for about 1 hour. I have found that it is important to vigorously rinse the mask in running water after development to reduce/avoid oxidation during curing. I have also tried tinning solution, when fresh it gives a nice shiny finish that is easy to solder, but it does not store well...
 
All in all I find it a lot easier to make my own boards now - no more frustration from toner transfer failures and it is great to be able to add a solder mask.
 
You will find more photos and details in the referred tread.
 
Terje

Here are the files for my PCB Exposer/Printer, it is the complete package including mechanical design files.
 

The printer itself.
 

Example - a power control PCB for Raspberry Pi - 40 x 40 mm.
 
Code includes driver for MCP4725 DAC, buffered serial port driver, stepper motor control and command parsing for the MSP430G2553 used as the main controller.
 
Code and design files:
 
PCB Exposer - controller code for MSP430G2553.zip
PCB Exposer - desktop application.zip
PCB Exposer - mechanical design files in Vectric format.zip
PCB Exposer - schematics and PCBs.zip
 
Desktop application is coded in C#, schematics and PCBs in KiCad format.
 
There is some more information to be found in this tread:
http://forum.43oh.com/topic/4990-what-are-you-doing-right-now/page-5
 
Terje
 
 

Yup, you can only go to LPM0 with USB active.
That's because the USB host (the computer) sends periodically package polling if the slave (msp430f5510) have something to read or to write.
Then, you always need the capability to get polling packages from the host, and answer those (NAK if you don't have nothing to do, but still sending something).
And to talk with the host you need the USB oscillator/clock working, so you can't shutdown the clock system further.
See Programmers_Guide_MSP430_USB_API.pdf 11.1.6 Use of Low-Power Modes
 
 
In your sleep/timing function of interest you should check out the usb state -for msp430 parts with usb module- using USB_getConnectionState().
 
I guess something like:
//Add to your function of interest int sleepMode = LPM3_bits; ... #if THERE_IS_USB_MODULE if( ST_USB_DISCONNECTED != USB_getConnectionState() )   sleepMode = LPM0_bits; #endif .... //sleep //__bis_SR_register(LPM0_bits + GIE);    //enable interrupts when sleeping __bis_SR_register(sleepMode + GIE);    //enable interrupts when sleeping __no_operation();

Saw this on DP and checked out the author's blog. Neat way of producing a inexpensive, small form factor wireless data acquisition node. Two AA cells and the board all in a cheap three cell AA enclosure. Would be cool to see this adapted to a TI MCU.
 
http://johan.kanflo.com/the-aaduino/

Hi,
Just read your blog and noticed you used gnuarmeclise site only for info, not installing, not taking any benefit of this package: templates for micros,   newlib use, managed make, detailed settings, bin file generation for Tiva, so on.
Also, useful for users is the EmbeddedRegisterView package, allow to see content of peripheral registers by names, not searching in memory vies by addresses.
L 

Ok, I modified slightly the optional sentence
 
 
Nice to know. I did a lot of things before arriving to a valid build of the whole toolchain, due more to my lack of knowledge than the process itself. Hopefully I can save somebody time and nerves

I recently installed openOCD on my computer and was able to get command line debugging working. Reading the gdb tutorials, I started doubting whether this was something I wanted to learn and wanted to see if I could get a GUI debugger working instead. I started fiddling around with Eclipse on my Mac and wanted to get a complete Tiva IDE. I followed a great tutorial for installing Stellarisware on Linux at http://kernelhacks.blogspot.com/2012/11/the-complete-tutorial-for-stellaris_25.html
 
Perhaps because of the changes from Stellarisware to Tivaware and/or Linux to Mac, there were many things that needed to be tweaked, adjusted, and fiddled with. But in the end, everything works!
 
First, off, I have Energia.app in /Applications. I installed openOCD using macports and installed Eclipse IDE for C/C++ Developers. Make sure gdb and openOCD are working properly before trying to get it to work in eclipse. I will describe here the changes from the tutorial above-- do all the other steps in the tutorial above.
 
I copied the TivaWare files extracted on a Windows machine (because TI distributes this as an EXE file!) to ~/Projects/TivaWare_C_Series-1.1 (you can choose elsewhere but will need to change paths accordingly). I also created a folder for openOCD in ~/Projects/openocdDir containing the file ek-lm4f230xl.cfg which contains
# # TI Stellaris Launchpad ek-lm4f120xl Evaluation Kits # # http://www.ti.com/tool/ek-lm4f120xl # # # NOTE: using the bundled ICDI interface is optional! # This interface is not ftdi based as previous boards were # source [find interface/ti-icdi.cfg] set WORKAREASIZE 0x8000 #set CHIPNAME lm4f120h5qr set CHIPNAME lm4f230h5qr source [find target/stellaris_icdi.cfg] Step 6: in Cross Settings, change Prefix to arm-none-eabi- and set Path to /Applications/Energia.app/Contents/Resources/Java/hardware/tools/lm4f/bin/
 
Step 7: Same except define PART_TM4C123GH6PM instead of PART_LM4F120H5QR. I don't know if this makes a difference but be consistent.
 
Step 8: set include path to /Users/pjkim/Projects/TivaWare_C_Series-1.1
 
Step 9: Misc section. Set other flags to "-c -fmessage-length=0 -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -ffunction-sections -fdata-sections -MD -std=c99 -Wall -pedantic"
 
Step 9.5: Change Cross Gcc Linker to ld. I think it defaulted to gcc for some reason.
 
Step 10: Linker Libraries. Leave Libraries blank. Change search path to /Applications/Energia.app/Contents/Resources/Java/hardware/tools/lm4f/lib/gcc/arm-none-eabi/4.7.1
 
Step 11: Linker Misc. Change linker flags to "--gc-sections -T../LM4F.ld"
 
Once everything is done, check your flags. If you click on the "Cross GCC Compiler" item under Tool Settings, you can see "All options:" it should look like 
-DARM_MATH_CM4 -DTARGET_IS_BLIZZARD_RA1 -DPART_TM4C123GH6PM -I/Users/pjkim/Projects/TivaWare_C_Series-1.1 -O0 -g3 -Wall -c -fmessage-length=0 -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -ffunction-sections -fdata-sections -MD -std=c99 -Wall -pedantic Check the Cross GCC Linker options. They should be something like this.
-L/Applications/Energia.app/Contents/Resources/Java/hardware/tools/lm4f/lib/gcc/arm-none-eabi/4.7.1 --gc-sections -T../LM4F.ld You will need to supply a linker description file LM4F.ld in the main folder of your project. You can copy any one of the .ld files from the TivaWare examples folder. You basically needs this in the file:
* This is part of revision 1.1 of the EK-TM4C123GXL Firmware Package. MEMORY { FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x00040000 SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00008000 } SECTIONS { .text : { _text = .; KEEP(*(.isr_vector)) *(.text*) *(.rodata*) _etext = .; } > FLASH .data : AT(ADDR(.text) + SIZEOF(.text)) { _data = .; *(vtable) *(.data*) _edata = .; } > SRAM .bss : { _bss = .; *(.bss*) *(COMMON) _ebss = .; } > SRAM } Go back to the appropriate sections to fix any errors. My username is pjkim. Change to yours. This should give you a working IDE for compiling your projects into an .elf and .bin file. Get this working before going to the next step,  "Flashing Programs."
 
Step 3: He was flashing the Release version which doesn't include the debug symbols in the .elf file. I chose to use the Debug version for this reason. Name "Debug flash." Location "/Applications/Energia.app/Contents/Resources/Java/hardware/tools/lm4f/bin/lm4flash" Working Directory: "${workspace_loc:/${project_name}/Debug}" and Arguments: "${project_name}.bin"
 
This should give you compile and flashing capabilities.
N.B. lm4flash in the current version of Energia (0101E0010) is broken. You will need to replace it from the prior version or as I did, build from source (https://github.com/utzig/lm4tools).
 
The last part of the puzzle is in IDE debugging. This part works now but it was tricky to get working and I am not exactly why it is so fidgety. If it is not working properly, I suggest trying to isolate the problem by running openocd in a terminal window and gdb from eclipse. If this works, do it the other way around, run openocd in eclipse and connect to the board using gdb in a terminal window. That way you can narrow down where you need to fix things.
 
Debuggin:
 
Step 2: Location: "/opt/local/bin/openocd" Working Directory: "/Users/pjkim/Projects/openocdDir" and Arguments: "--file ek-lm4f230xl.cfg" You will need to create a openocdDir folder and put in the file ek-lm4f230xl.cfg. The contents are:
# # Comments go here # source [find interface/ti-icdi.cfg] set WORKAREASIZE 0x8000 set CHIPNAME lm4f230h5qr source [find target/stellaris_icdi.cfg] Step 7: There is a known bug in gdb or openocd that can cause connection problems. The workaround is described in http://www.verious.com/tutorial/the-complete-tutorial-for-stellaris-launchpad-development-with-gnu-linux-ii
 
Get the target.xml file from http://pastebin.com/download.php?i=0Lu3Bu0R and rename it. Put the file in your Project/Debug folder. If anyone knows how to do this better/automatically, I would appreciate it.
 
Change the Initialization commands to
set tdesc filename ../target.xml target extended-remote :3333 monitor reset halt And you should have a working IDE. Here is a screenshot of the IDE in action:

 
Wouldn't it be nice if TI could package all of this into a .dmg file?

Sorry for the self-promotion, I'm working on a mspgcc 4.7 toolchain installation guide on ubuntu 14.04 amd64, maybe it can help you:
http://www.colotronics.blogspot.com.ar/2014/08/msp430-toolchain-in-ubuntu-1404-with.html

I followed an instruction from:
http://www.colotronics.blogspot.com.ar/2014/08/msp430-toolchain-in-ubuntu-1404-with.html

Down the page:
# OPTIONAL TILIB v3 installation of msp fet430uif debugger, ignore if you do not have it

I also need to install
sudo apt-get install libusb-1.0

Then I have to do mspdebug tilib --allow-fw-update several times. Maby as su.
Now it sees my msp430fr5969 Launchpad with EnergiTrace.
Now I think the fun starts!

 

It happens to me also, I have to do
mspdebug tilib
several times before a connection is established with the debugger. I don't know why, but doesn't represent a huge problem neither.
This is a screenshot of the errors:
 

 
After several of those the communication is established normally, without doing anything in between other than execute mspdebug tilib.
In fact, the last message is a normal initialization, but I don't have any msp430 connected to the debugger, thats why error = 5.
 
If the udev rules are defined you don't need to use su.
The allow-fw-update thing is needed one time only, after the installation of TILIB on the PC.
 
I will add the libusb-1.0.0 dependency, thanks for the observation

Sorry for the self-promotion, I'm working on a mspgcc 4.7 toolchain installation guide on ubuntu 14.04 amd64, maybe it can help you:
http://www.colotronics.blogspot.com.ar/2014/08/msp430-toolchain-in-ubuntu-1404-with.html