spirilis 1,265 Posted November 8, 2012 Share Posted November 8, 2012 Buy @ The 43oh Store. So I got a couple samples of the F5172 (has 5V-tolerant I/Os, 32KB flash + 2KB SRAM, Timer_D can run up to 256MHz with FLL) this past summer and had nothing to do with them. Original idea was to make an Arduino-variant since it has around 12 5V-tolerant I/Os, but I decided against that when I first read about TI's 40-pin XL standard. EDIT: Link to newest revision of this design: http://forum.43oh.com/topic/2828-msp430f5172-launchpad-xl/page-4#entry31194 Between last night and this morning I did some marathon CAD, and came up with my F5172 LaunchPad. Let me know what you think:(OSHpark mockup images, I'll most likely use Seeed and make them red.)Bottom:Notes:1. The board includes "mount" headers (female headers pointing down) to plug into the Emulation layer on the MSP430 LaunchPad rev 1.5. As I understand it, TI does *not* support the use of the LP's SBW for programming or debugging F5xxx devices but I've heard it does in fact work, maybe with some limitations (on the E2E forums someone was complaining step-by-step execution didn't work).2. The board includes the MSP-FET430UIF 14-pin header, SBW-only (and wired in accordance with slau278k's recommendations for SBW on F5xxx and F6xxx devices). A 3-pin jumper is there to select VCC TOOL (sourced from the FET tool) or external power.3. To align with TI's recommendations for the 40-pin XL pin functions, some ports have been duplicated to more than one LP pin. There is a vertical bar next to the pin label if it's also used elsewhere in the 40-pin layout.4. The device includes an FTDI FT232RL chip for the serial port. TXD and RXD LEDs are attached to CBUS0/CBUS1 and CBUS2-4 from the FTDI are broken out to a header. I now have headers in place to disable the TX/RX circuit from the chip.5. An LDO TPS77333 regulator (similar to MSP430 LaunchPad) is included for providing 3.3V power off the 5V USB feed. LDO_EN lets you enable/disable this and LDO_RST connects the RESET line to the F5172's RESET so the LDO can keep the chip halted until the LDO has built up its output voltage.6. LEDs on P1.7 and P3.6 (both PWM-able) have been included, I was thinking of using a white LED with P1.7 and blue LED with P3.6.7. P2.7 is not broken out to any of the LP pins, so it's specially designated for the SW1 button which also has a hardware debounce circuit. Should be idle-high, active-low (low when pressed).8. The 5V tolerant pins are enabled by switching the "VIO" header to 5V.9. XTALs are on the bottom, there are footprints for a tuning fork crystal and a HF through-hole crystal with its load capacitors nearby.10. AVcc exists on these chips so I set up an LC filter for it, L1 (10uH SMD) and C9 (10nF SMD).11. The F5172 datasheet, page 33, note 3 has not been adhered to--if VIO jumper is set to 5V it will probably get power before the LDO has spun up the 3V3 rail. We'll see if that matters (I doubt it)... jsolarski, RobG, bluehash and 2 others 5 Quote Link to post Share on other sites
spirilis 1,265 Posted November 8, 2012 Author Share Posted November 8, 2012 Heh also noticed a slight error, my 2-pin jumper footprints are putting an outline on the bottom solder mask layer, not the silkscreen... (thought I'd fixed that before, guess not) Quote Link to post Share on other sites
spirilis 1,265 Posted November 8, 2012 Author Share Posted November 8, 2012 Ah and one more thing to note--the bottom 3 pins on the outer LP headers do not correspond to Interrupt-capable pins, apparently the TI boosterpack standard designates that they should just be CapSense-capable. The use of Capacitive Touch with this board requires the Timer_D + Comparator_B method, detailed here: http://www.ti.com/li...1a/slaa481a.pdf and should have the advantage of being extremely fast (measuring the pulse width of a few cap sense oscillations, rather than timing a longer time-period of oscillation) Quote Link to post Share on other sites
spirilis 1,265 Posted November 8, 2012 Author Share Posted November 8, 2012 Completed my todo's, updated the images with the new changes. Quote Link to post Share on other sites
bluehash 1,581 Posted November 8, 2012 Share Posted November 8, 2012 Completed my todo's, updated the images with the new changes. If people are interested. Will sponsor. Quote Link to post Share on other sites
spirilis 1,265 Posted November 9, 2012 Author Share Posted November 9, 2012 So another thing I found out is that the F5172 isn't in the default list of supported devs with mspdebug, but after a short email convo with Daniel Beer it sounds like it's in the Olimex debugger supported list but not the TI (rf2500, uif) supported list. But it should be straightforward to port it over--might require a patch to mspdebug at most to get it working. So in the meantime I may build a short breakout board for the chip (with toner-transfer process at home) and try my new MSP-FET430UIF out on it to see what needs to be done. Also updated the images again, turns out I had the FET430 pinout backwards and now it's fixed (with cable orientation marks on the silkscreen). I just received my MSP-FET430UIF today. (Getting it working on OSX has been a pain in the ass so far....) Quote Link to post Share on other sites
spirilis 1,265 Posted November 10, 2012 Author Share Posted November 10, 2012 FYI- I went ahead and ordered a run of 10 boards from Seeed. I also did a quick BOM draft with the prices I've been paying from Mouser and eBay for the components.... Altogether it looks like this would be a $25 board if sold through the 43oh store. A bit pricey but there's a lot going on there (and it required the use of the Seeed 10X10 size, plus there's an FT232RL, etc). Quote Link to post Share on other sites
GeekDoc 226 Posted November 10, 2012 Share Posted November 10, 2012 Looks really good! I'll bet you could get it down to $20 with higher volume pretty easily. I'm sure they'd sell! (Probably 2+ for me!) Quote Link to post Share on other sites
spirilis 1,265 Posted November 10, 2012 Author Share Posted November 10, 2012 Also made a Mouser order last night, so by the time the boards are here I should have everything I need to build out all 10. I was thinking of a few small details: 1. Not going to populate the LaunchPad mount headers, but supply two 1x3 female headers so the user can do so at their leisure. 2. Will include a 32KHz XTAL but not solder it down in case the user prefers to use a high-frequency XTAL instead. 3. FTDI CBUS header up top (J1) won't be populated, those are programmed with the FTDI EEPROM tool anyway and are just there in case the user has some cool ideas of what to do with it. 4. Not going to include the 40-pin LaunchPad headers, the user should buy what they want from the 43oh store at the same time, that way I'm not laying out more than I need to and the user has a choice of whether they want stackable headers, male headers or female headers pointing up. The cost of the headers in the 43oh store is basically comparable to what I'd be spending from mouser anyway. Everything else will be populated and some jumpers included where necessary. This brings the price down to $24 fwiw (letting the user choose their style of LP headers) Also, I've attached the schematic to this post. Quote Link to post Share on other sites
spirilis 1,265 Posted November 10, 2012 Author Share Posted November 10, 2012 Oops, forgot to actually hit the 'Attach This File' button, try this one... DipTrace Schematic - F5172_LaunchPad_draft1.pdf Quote Link to post Share on other sites
spirilis 1,265 Posted December 4, 2012 Author Share Posted December 4, 2012 Boards came: Was oddly tired last night, went to sleep at 7:30, didn't have time to solder one up... Maybe tonight! jsolarski and RobG 2 Quote Link to post Share on other sites
spirilis 1,265 Posted December 5, 2012 Author Share Posted December 5, 2012 Ladies and Gentlemen, I present to you... The Birth of a LaunchPad. I've managed to see the FTDI chip, install the Windows 7 drivers and have the FTProg find it/let me tweak the EEPROM, and I have used my MSP-FET430UIF in a Linux VM running 'tilib' (it has the v3 drivers on it) recognize it as an F5172. MSP430_GetNumberOfUsbIfs MSP430_GetNameOfUsbIf Found FET: /dev/serial/by-id/../../ttyACM0 MSP430_Initialize: /dev/serial/by-id/../../ttyACM0 Firmware version is 30205004 MSP430_VCC: 3000 mV MSP430_OpenDevice MSP430_GetFoundDevice Device: MSP430F5172 (id = 0x00ae) 3 breakpoints available MSP430_EEM_Init Chip ID data: 30 80 30 Available commands: = erase isearch prog setbreak sym alias exit load read setwatch verify break fill locka regs setwatch_r cgraph gdb md reset setwatch_w delbreak help mw run simio dis hexout opt set step Available options: color gdb_loop iradix fet_block_size gdbc_xfer_size quiet Type "help <topic>" for more information. Press Ctrl+D to quit. (mspdebug) As I understand it, mspdebug v0.21 should allow detection of the F51xx devices by other means, e.g. the MSP-EXP430G2 launchpad. I have not populated the LaunchPad SBW-mount headers on this yet (female headers that point down), but I am going to try jumper-wiring it to my v1.5 LP in a minute and see if it works. Haven't uploaded any code yet, gotta figure out how the F5xxx series work (the Unified Clock system, etc). Another pic with the various jumpers populated: The LEDs down at the bottom are White and Blue. Can't wait to get those going, and if I'm not mistaken the port pins they correspond to are driven by the V_I/O which can be set to 3.3V or 5V (see the "VIO" jumper in the upper left corner) so they can be driven brighter. edit: Only the white LED (P1.7) is driven by VIO, the blue one (P3.6) is not. It is definitely brighter with VIO=5V. RobG and xpg 2 Quote Link to post Share on other sites
spirilis 1,265 Posted December 5, 2012 Author Share Posted December 5, 2012 Looks like mspdebug 0.21 doesn't detect it out of the box at the moment: Trying to open interface 1 on 005 Initializing FET... FET protocol version is 30394216 Set Vcc: 3000 mV Configured for Spy-Bi-Wire Device ID: 0x3080 fet: unknown device msg28_data: [0x1a bytes] 30 80 30 10 08 0a b5 5b 94 46 26 00 27 00 f8 fe ae ef 91 04 11 00 1a 00 04 05 fet: identify failed Trying again... Initializing FET... FET protocol version is 30394216 Set Vcc: 3000 mV Configured for Spy-Bi-Wire Sending reset... Device ID: 0x3080 fet: unknown device msg28_data: [0x1a bytes] 30 80 30 10 08 0a b5 5b 94 46 26 00 27 00 f8 fe ae ef 91 04 11 00 1a 00 04 05 fet: identify failed More work to be done there. Quote Link to post Share on other sites
spirilis 1,265 Posted December 5, 2012 Author Share Posted December 5, 2012 Daniel Beer had given me advice on forcing mspdebug to use the Olimex hardware list, which is more complete, and it works: Ok, let me know what you find. In the meantime, there's a quick hack that should probably get your chip working anyway. Take the latest git version of mspdebug, and look for the function do_identify() in drivers/fet_core.c: static int do_identify(struct fet_device *dev, const char *force_id) { if (is_new_olimex(dev)) return identify_olimex(dev, force_id); ... If you comment out the first if statement, so that the function always invokes identify_olimex(), then it will use the more comprehensive Olimex database even with TI debuggers. The Olimex database contains support for the F5172. I haven't tested this though, so let me know if it works. Doing that to the mspdebug 0.21 source (he wrote this email before 0.21 was released FYI), I get a recognized F5172: Trying to open interface 1 on 005 Initializing FET... FET protocol version is 30394216 Set Vcc: 3000 mV Configured for Spy-Bi-Wire Using Olimex identification procedure Device ID: 0x3080 Code start address: 0x8000 Code size : 32768 byte = 32 kb RAM start address: 0x1c00 RAM end address: 0x23ff RAM size : 2048 byte = 2 kb Device: MSP430F5172 Number of breakpoints: 3 fet: FET returned NAK warning: device does not support power profiling jsolarski 1 Quote Link to post Share on other sites
spirilis 1,265 Posted December 5, 2012 Author Share Posted December 5, 2012 K I really don't know what I'm doing with the UCSCTL registers, for the most part, but using the F51x2 sample code's "MSP430F51x2_UCS_04.c" example to configure XT1 (32.768KHz xtal, which I have soldered) I've come up with an example -- but XCAP_3 doesn't work, it barely gets the crystal starting. XCAP_2 and XCAP_1 works OK though. Probably too much capacitance or interference from the long traces and vias for the XTAL, and the fact that my AVcc L-C filter passes overtop too. Next board run I make will have this redesigned & cleaned up. For now I can get it past the clock init and have it flashing the white LED, although it's flashing a lot faster than I intended (need to examine my timings and toss my logic analyzer on there for some frequency counting tonight) /* F5172 Hello World * * Initialize the F5172 and flash the white LED in an S.O.S. format */ #include <msp430.h> #include <stdlib.h> #include <string.h> int main() { WDTCTL = WDTPW | WDTHOLD; // Init LEDs P1OUT &= ~BIT7; P3OUT &= ~BIT6; P1DIR |= BIT7; P3DIR |= BIT6; P1SEL &= ~BIT7; P3SEL &= ~BIT6; P1DS |= BIT7; P3DS |= BIT6; P3OUT |= BIT6; // Init XT1 32.768KHz PJSEL |= BIT4|BIT5; UCSCTL6 &= ~XT1OFF; UCSCTL6 = (UCSCTL7 & ~XCAP_3) | XCAP_1; // Wait for XT1 to stabilize do { UCSCTL7 &= ~XT1LFOFFG; } while (UCSCTL7 & XT1LFOFFG); // Initialize DCO to 2.45MHz __bis_SR_register(SCG0); // Disable FLL control loop UCSCTL0 = 0x0000; UCSCTL1 = DCORSEL_2; UCSCTL2 = FLLD_1 | 74; __bic_SR_register(SCG0); // Re-enable FLL control loop /* Worst-case settling time for the DCO when the DCO range bits have been * changed is n x 32 x 32 x f_MCLK / f_FLL_reference. See UCS chapter in 5xx * UG for optimization. * 32 x 32 x 2.45 MHz / 32,768 Hz = 76563 = MCLK cycles for DCO to settle */ __delay_cycles(76563); // Loop until XT1 & DCO fault flags have cleared do { UCSCTL7 &= ~(XT1LFOFFG | XT1HFOFFG | DCOFFG); SFRIFG1 &= ~OFIFG; } while (SFRIFG1 & OFIFG); // DCOCLK stable at 2.45MHz - Configure MCLK, SMCLK, ACLK. UCSCTL4 = SELM__DCOCLK | SELS__DCOCLK | SELA__XT1CLK; UCSCTL5 = DIVM__1 | DIVS__4 | DIVA__1; P3OUT &= ~BIT6; // Proceed with main program while(1) { P1OUT |= BIT7; __delay_cycles(49000); P1OUT &= ~BIT7; __delay_cycles(24500); P1OUT |= BIT7; __delay_cycles(49000); P1OUT &= ~BIT7; __delay_cycles(24500); P1OUT |= BIT7; __delay_cycles(49000); P1OUT &= ~BIT7; __delay_cycles(24500); __delay_cycles(49000); P1OUT |= BIT7; __delay_cycles(196000); P1OUT &= ~BIT7; __delay_cycles(49000); P1OUT |= BIT7; __delay_cycles(196000); P1OUT &= ~BIT7; __delay_cycles(49000); P1OUT |= BIT7; __delay_cycles(196000); P1OUT &= ~BIT7; __delay_cycles(49000); __delay_cycles(49000); P1OUT |= BIT7; __delay_cycles(49000); P1OUT &= ~BIT7; __delay_cycles(24500); P1OUT |= BIT7; __delay_cycles(49000); P1OUT &= ~BIT7; __delay_cycles(24500); P1OUT |= BIT7; __delay_cycles(49000); P1OUT &= ~BIT7; __delay_cycles(24500); } return 0; } PS- What is it with all the HTML div's showing up there? Seems like the ipboard upgrade solved one problem and added another! Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.