spirilis 1,265 Posted December 5, 2012 Author Share Posted December 5, 2012 Ah, had my delay numbers an order of magnitude off... Still getting occasional stuck crystal even with XCAP_1 and XCAP_2. I guess this XTAL layout is broken. Quote Link to post Share on other sites
spirilis 1,265 Posted December 5, 2012 Author Share Posted December 5, 2012 Tapping my fingers on the external load cap pads always seem to un-stick it, so I'm going to try external load caps next. I don't have any (and need to find the proper values for them) so I'll order some off ebay (vendor nearby who ships free and it gets here within 2 days). Quote Link to post Share on other sites
spirilis 1,265 Posted December 7, 2012 Author Share Posted December 7, 2012 Redesigned it with a much better XTAL layout. Other changes: SW1 P2.7 now sources its pullup from VIO rather than 3V3, since P2.7 happens to be one of the VIO-driven (i.e. 5V-tolerant) I/O pins. Big oversight on my part previously. Power LEDs for 3V3 and 5V (5V will be blue, 3V3 green, 1K on the green LED and 2.2K on the blue LED so the blue doesn't overwhelm), also switching to a 220R resistor for the white LED on P1.7 so it can be driven harder from the 5V source. Now fits in a 5x10cm form factor; doesn't matter for 10-qty orders from Seeed but it's much cheaper for 50 or 100-qty orders. This still uses the FT232RL, I am going to do a quick revamp based on this design with the FT230X. I intend to make a run of 10 of these and future designs use the FT230X. The boards I already made I think I am going to scrap. Having an XTAL that doesn't stabilize, and P2.7 being sourced from the wrong voltage header, is just a bad idea. I am going to use the one I built out to gain familiarity with the F5172 chip at least. If you guys come up with a good logo for the 43oh boards I'll include it on the top silkscreen... I don't plan to order these just yet, might wait a few days. New schematic: DipTrace Schematic - F5172_LaunchPad_draft3_FT232RL.pdf OSHpark gerbers: OSH_43oh_F5172_draft3_0.zip Seeed/ITead gerbers: Seeed_43oh_F5172_draft3_0_5x10.zip Top: Bottom: Automate, bluehash and RobG 3 Quote Link to post Share on other sites
spirilis 1,265 Posted December 10, 2012 Author Share Posted December 10, 2012 Think I got some good final designs ready. Will post the gerbers & images tomorrow. I just put "43oh.com" in the top soldermask in the lower left corner for now... Got the FT232RL design, and an FT230XS variant all put together. Did some reinforcement vias + touchups for the GND plane, as some parts of the GND plane were getting choked down to a 0.3mm trace or whatnot... beefed them up and used extra static vias to reinforce the connections. Quote Link to post Share on other sites
spirilis 1,265 Posted December 12, 2012 Author Share Posted December 12, 2012 Posting both FT232RL and FT230XS variations: F5172 LaunchPad draft3_0 (FT232RL)- Schematic: DipTrace Schematic - F5172_LaunchPad_draft3_FT232RL.pdf OSHpark gerbers: OSH_43oh_F5172_draft3_0.zip Seeed/ITead gerbers: Seeed_43oh_F5172_draft3_0_5x10.zip Top: Bottom: ---------------- F5172 LaunchPad draft3_1 (FT230XS)- Schematic: DipTrace Schematic - F5172_LaunchPad_draft3_1_FT230X.pdf OSHpark gerbers: OSH_43oh_F5172_draft3_1.zip Seeed/ITead gerbers: Seeed_43oh_F5172_draft3_1_5x10.zip Top: Bottom: Will make an order of the draft3_0 edition soon so I can use up my FT232RL inventory. edit: Done, 10 boards in the queue... bluehash, RobG and jlumme 3 Quote Link to post Share on other sites
spirilis 1,265 Posted December 13, 2012 Author Share Posted December 13, 2012 draft3.0 boards are in production according to Seeed. Quote Link to post Share on other sites
TheDirty 33 Posted December 13, 2012 Share Posted December 13, 2012 Why are you populating both sides? It looks like you have plenty of room to put all parts on a single side for easier assembly and it's just nicer to have everything on one side. Quote Link to post Share on other sites
spirilis 1,265 Posted December 31, 2012 Author Share Posted December 31, 2012 Boards are in, one complete, its XTAL seems to stabilize reliably every time now: bluehash and CorB 2 Quote Link to post Share on other sites
bluehash 1,581 Posted December 31, 2012 Share Posted December 31, 2012 Another sibling to the LP family. Quote Link to post Share on other sites
SugarAddict 227 Posted December 31, 2012 Share Posted December 31, 2012 Where do I send the monies? Lol Tapatalk Mobile Device Quote Link to post Share on other sites
RobG 1,892 Posted December 31, 2012 Share Posted December 31, 2012 Ditto Quote Link to post Share on other sites
timotet 44 Posted December 31, 2012 Share Posted December 31, 2012 well done! Quote Link to post Share on other sites
spirilis 1,265 Posted January 2, 2013 Author Share Posted January 2, 2013 So these things are only supposed to go like ... 24 or 25MHz? Probably a good guide, but I can personally vouch for the fact that you can drive the core (or at least I have driven mine) up to 56MHz without visible crashing. At 57MHz, the LED blinks successfully a few times and then crashes (LED stays on hard). Above that, DCO will stabilize but the CPU crashes hard after that. Pretty funny seeing that in action! Here's my code: (clockinit.c, computes UCS registers based on requested clock speed) /* Initialize the UCS clock in the F5172 */ #include <msp430.h> #include <stdint.h> #include "vcore.h" uint16_t _dcorsel_compute_f5172(unsigned long); uint16_t _flld_compute(unsigned long); uint8_t ucs_clockinit(unsigned long freq, uint8_t use_xt1, uint8_t vlo_as_aclk) { unsigned long attempts = 0; //, divided; uint16_t flld; static uint8_t did_vcoreup = 0; UCSCTL4 = SELM__DCOCLK | SELS__DCOCLK; if (vlo_as_aclk) UCSCTL4 = (UCSCTL4 & ~SELA_7) | SELA__VLOCLK; if (use_xt1) { PJSEL |= BIT4|BIT5; UCSCTL6 &= ~XT1OFF; UCSCTL6 = (UCSCTL6 & ~(XCAP_3|XT1DRIVE_3)) | XCAP_0 | XT1DRIVE_3; if (!vlo_as_aclk) UCSCTL4 = (UCSCTL4 & ~SELA_7) | SELA__XT1CLK; // Wait for XT1 to stabilize do { UCSCTL7 &= ~XT1LFOFFG; attempts++; } while (UCSCTL7 & XT1LFOFFG && attempts < 1000000); if (attempts == 1000000) return 0; // XT1 FAILED } else { UCSCTL6 |= XT1OFF; UCSCTL7 &= ~(XT1LFOFFG | XT1HFOFFG); UCSCTL3 = SELREF__REFOCLK; } // Using frequency, determine which VCore level we should achieve. // Set Vcore to maximum if (!did_vcoreup) { SetVCoreUp(1); SetVCoreUp(2); SetVCoreUp(3); did_vcoreup = 1; } // Initialize DCO __bis_SR_register(SCG0); // Disable FLL control loop UCSCTL0 = 0x0000; // Determine which DCORSEL we should use UCSCTL1 = _dcorsel_compute_f5172(freq); // FLL reference is 32768Hz, determine multiplier flld = _flld_compute(freq); UCSCTL2 = ((flld/2) << 12) | (uint16_t)(freq / 32768UL / flld); __bic_SR_register(SCG0); // Re-enable FLL control loop // Loop until XT1 & DCO fault flags have cleared do { UCSCTL7 &= ~(XT1LFOFFG | XT1HFOFFG | DCOFFG); SFRIFG1 &= ~OFIFG; } while (SFRIFG1 & OFIFG); // DCOCLK stable return 1; } inline uint16_t _dcorsel_compute_f5172(unsigned long freq) { if (freq <= 1000000) return DCORSEL_0; if (freq <= 2000000) return DCORSEL_1; if (freq <= 6000000) return DCORSEL_2; if (freq <= 10000000) return DCORSEL_3; if (freq <= 16000000) return DCORSEL_4; if (freq <= 20000000) return DCORSEL_5; if (freq <= 25000000) return DCORSEL_6; if (freq <= 130000000) // This should never be reached return DCORSEL_7; return 0; } inline uint16_t _flld_compute(unsigned long freq) { if (freq <= 32000000) return 1; if (freq <= 64000000) return 2; if (freq <= 128000000) return 3; return 1; } vcore.c, sets the VCore levels in a stepped manner: #include <msp430.h> #include "vcore.h" void SetVCoreUp (unsigned int level) { if (level > VCORE_MAX_LEVEL) return; // level is 0-3 // Open PMM registers for write access PMMCTL0_H = 0xA5; // Make sure no flags are set for iterative sequences //while ((PMMIFG & SVSMHDLYIFG) == 0); //while ((PMMIFG & SVSMLDLYIFG) == 0); // Set SVS/SVM high side new level SVSMHCTL = SVSHE + SVSHRVL0 * level + SVMHE + SVSMHRRL0 * level; // Set SVM low side to new level SVSMLCTL = SVSLE + SVMLE + SVSMLRRL0 * level; // Wait till SVM is settled while ((PMMIFG & SVSMLDLYIFG) == 0); // Clear already set flags PMMIFG &= ~(SVMLVLRIFG + SVMLIFG); // Set VCore to new level PMMCTL0_L = PMMCOREV0 * level; // Wait till new level reached if ((PMMIFG & SVMLIFG)) while ((PMMIFG & SVMLVLRIFG) == 0); // Set SVS/SVM low side to new level SVSMLCTL = SVSLE + SVSLRVL0 * level + SVMLE + SVSMLRRL0 * level; // Lock PMM registers for write access PMMCTL0_H = 0x00; } And lastly, my main.c: /* 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> #include "vcore.h" #define DELAY_100MS 1600000UL uint8_t ucs_clockinit(unsigned long freq, uint8_t use_xt1, uint8_t vlo_as_aclk); int main() { WDTCTL = WDTPW | WDTHOLD; // Init LEDs P1OUT &= ~BIT7; P3OUT &= ~BIT6; P1DIR |= BIT7; P3DIR |= BIT6; P1SEL &= ~BIT7; P3SEL &= ~BIT6; //P1DS |= BIT7; //P1DS &= ~BIT7; P3DS |= BIT6; // Init MCLK output (PJ.1) PJDIR |= BIT1; PJSEL |= BIT1; P3OUT |= BIT6; if (!ucs_clockinit(56000000, 1, 1)) LPM4; P3OUT &= ~BIT6; // Proceed with main program while(1) { P1OUT |= BIT7; __delay_cycles(DELAY_100MS*3); P1OUT &= ~BIT7; __delay_cycles(DELAY_100MS*2); P1OUT |= BIT7; __delay_cycles(DELAY_100MS*3); P1OUT &= ~BIT7; __delay_cycles(DELAY_100MS*2); P1OUT |= BIT7; __delay_cycles(DELAY_100MS*3); P1OUT &= ~BIT7; __delay_cycles(DELAY_100MS*2); __delay_cycles(DELAY_100MS*8); P1OUT |= BIT7; __delay_cycles(DELAY_100MS*8); P1OUT &= ~BIT7; __delay_cycles(DELAY_100MS*5); P1OUT |= BIT7; __delay_cycles(DELAY_100MS*8); P1OUT &= ~BIT7; __delay_cycles(DELAY_100MS*5); P1OUT |= BIT7; __delay_cycles(DELAY_100MS*8); P1OUT &= ~BIT7; __delay_cycles(DELAY_100MS*5); __delay_cycles(DELAY_100MS*8); P1OUT |= BIT7; __delay_cycles(DELAY_100MS*3); P1OUT &= ~BIT7; __delay_cycles(DELAY_100MS*2); P1OUT |= BIT7; __delay_cycles(DELAY_100MS*3); P1OUT &= ~BIT7; __delay_cycles(DELAY_100MS*2); P1OUT |= BIT7; __delay_cycles(DELAY_100MS*3); P1OUT &= ~BIT7; __delay_cycles(DELAY_100MS*2); __delay_cycles(DELAY_100MS*40); if (UCSCTL7 & XT1LFOFFG) { UCSCTL7 &= ~XT1LFOFFG; P3OUT |= BIT6; } else { P3OUT &= ~BIT6; } } return 0; } Quote Link to post Share on other sites
spirilis 1,265 Posted January 6, 2013 Author Share Posted January 6, 2013 Ok so, I'll be selling these through the 43oh store for $25, shipping them over to bluehash this week... Here's a quick rundown of the board and its features: You will receive the board mostly soldered but with no LaunchPad headers--remember to buy the appropriate headers from the 43oh store, and remember this is a 40-pin XL model so it requires 4 sets of 1x10 headers... Included and not-soldered is a 32.768KHz XTAL and two 1x3 female headers: The 1x3 female headers are used to allow this to mount on top of a v1.5 LaunchPad to steal its SBW emulator. In order to set this up, these female headers should be soldered pointing down (if you don't use stackable headers, the F5172 LP doesn't sit level on the desk btw): In order to use this, remove the rightmost 3 jumpers from J3 on the TI (Value-Line v1.5) LaunchPad: Mount the F5172 LP board on top so the bottom 1x3 header clasps the GND/GND/VCC header on the LaunchPad below, and the upper 1x3 should mount on the top set of exposed pins in J3: The USB connection should go to the TI LaunchPad underneath to access its emulator. If you wish to power the F5172 from it, make sure the "LP_PWR" jumper is installed. Alternately, the MSP-FET430UIF style 14-pin header comes pre-soldered. It's wired for SBW, not 4-wire JTAG. If you use the FET430UIF programmer, remove the LP_PWR jumper and move it over to the FET_PWR one on the right. The jumper installed in the "ON" position connects Vcc to VCCTOOL, allowing the FET430UIF tool to power the Vcc rail. The jumper installed in the other position (not explicitly labeled due to space constraints) connects Vcc to VCCTARGET, so the FET430UIF has the correct voltage level to drive its level shifter (or optoisolator, whatever it's using). You'll have to power the F5172 board by some other means (e.g. separate USB connection to the F5172 LP, with LDO_EN enabled) when using that setting. LDO_RST connects the TPS77333's RESET output to the chip's RST line, so it holds the chip suspended until the 3.3V rail is stable. LDO_EN shorts the EN pin on the TPS77333 to GND so it enables it; removing it should disable it, but I've found that doesn't always happen. I think I was supposed to put a pull-up resistor on that line and I didn't. Wasn't quite clear when I read the datasheet... I am going to do that on future revisions of this board. If you absolutely need to disable the LDO, run a jumper wire from the right pin in "LDO_EN" to the 5V rail. Note that with no power going to the 5V rail, it seems the Vcc (3.3V) rail passes some voltage over to it via a diode inside the LDO I guess. With 3.6V from the TI LaunchPad powering Vcc (LP_PWR jumper installed), the 5V rail shows ~3.1V or similar (and you'll see the 5V status LED up top light somewhat dimly). The VIO jumper sets the voltage source for the DVIO pin on the F5172 chip. DVIO is used to drive certain pins, including all of PORT2, see the silkscreen for the list.... And here's a visual list of which LP pins are driven by DVIO: Just be very careful when using other boosterpacks and such that you don't accidentally fry a chip with the wrong VIO setting... They all ship with the VIO jumper installed to the left (DVIO = Vcc). Seems most of the DVIO-enabled pins are timer outputs anyhow. The white LED (D1) is connected to one, and I used a 220R resistor for it so it gets nice & bright. The blue LED (D2) has a 1K resistor and its pin is driven by DVcc, so it's much dimmer. Note these chips have a Port Mapper feature so you can remap the peripherals to different ports, I *think* that means you can, for example, remap USCI_B or USCI_A to some DVIO-enabled pins to, say, talk native 5V I/O to an Arduino or other 5V-native MCU (e.g. join it to an existing Arduino project that uses I2C or SPI). Out of the box, those USCI pins aren't DVIO-driven. The LaunchPad header layout is designed so its default port-mapper peripheral config roughly matches the requirements stated for 40-pin LaunchPads in this wiki page: http://processors.wiki.ti.com/index.php/BYOB For those that are curious, the choice of ports for the lower 3 pins on each outside header--GPIO (Cap Touch Capable)--have been populated with ports housing Comparator_B channels, with the intention that someone looking to design a Capacitive Touch interface will use the Timer_D+Comparator_B technique outlined in this TI application note: http://www.ti.com/lit/an/slaa481a/slaa481a.pdf The FTDI chip is programmed to report a MaxPower of 500mA, and the TXEN/RXEN jumpers attach it to the correct USCI ports (per the default port mapping). Note that all references to "TX" (TXEN, TXD LED) refer to MCU transmits, and "RX" (RXEN, RXD LED) refer to MCU receiving ... It's worded from the standpoint of the MCU, not the PC host or FTDI chip or whatever. So the TXD LED is called "RXLED" in the FTDI EEPROM config, and vice versa. These chips are capable of a BSL as I understand it, and the default ports for that is P3.6/P3.5. I haven't tried this myself but I suppose you could remove the TXEN & RXEN jumpers and attach the left pin of each jumper to their respective BSL pin (TXEN -> P3.5, RXEN -> P3.6). In addition the unused FTDI CBUS pins are broken out up top; see the bottom-side silkscreen for the exact layout. Perhaps the RST/TEST lines could be driven by those to activate the BSL somehow. XTALs... Pads are there for the 32.768KHz XTAL and the F5172 also supports a High Frequency XTAL, so there are PTH holes for higher frequency crystals. Load capacitors C12/C13 are unpopulated 0603 pads on the bottom of the board. P2.7 isn't broken out to any of the LaunchPad pins, its only connection is to SW1 down below. It has a hardware pullup & debounce circuit built in, active-LOW (HIGH=unpressed, LOW=pressed). The P2REN pullup setting does not need to be enabled for this. Demo firmware has been loaded onto all of these, running at 16MHz relying on the REFO (built-in trimmed 32.768KHz oscillator) to drive the FLL. The blue LED (D2, P3.6) will light briefly (and I mean, it's barely a hint of a flicker) until the REFO+FLL+DCO is fully stable at its target speed (16MHz). The firmware should flash the white LED in an S.O.S. morse-code sequence; pressing SW1 should toggle the display of that LED sequence on/off. USCI_A0 is configured to spit out "F5172 LAUNCHPAD DEMO 115200" every ~3 seconds; the serial bitrate is 115200/8/N/1. If you submit text to it (terminating by a \r char; \n's are ignored) it should spit it back out at you with a sequence number at the beginning so you can verify that it's receiving properly over the serial port. Lastly, all the GPIO ports are set to HIGH unless they're being used for other stuff (e.g. UART or the D1/D2 LEDs; P3.6, aka D2, is left off). Source code for the demo (compiled with mspgcc, and a copy of the binary "main.elf" included): f5172_demo.zip Anyway I hope these are useful to folks, I've had fun designing it and I'm looking forward to fixing/improving some of the minor details in future revisions. I think this chip has potential, particularly with that Timer_D (256MHz) module. bluehash, Rickta59 and GeekDoc 3 Quote Link to post Share on other sites
Nytblade 24 Posted January 9, 2013 Share Posted January 9, 2013 I see I am not the only one to experience the 'joys' of the UCS. :thumbup: Good clean coding style. I am going to attempt to port my wiznet DHCP client to your board. My code is too bloated to fit on the original MSP430 Launchpad. However, if I can get it working, people could use Rob's ethernet boosterpack with your board and have automatic IP address assignment via DHCP. I think that would be useful. I can post the code to a simple telnet server or webserver with DHCP support. Do you know if it is possible to have the pins sticking out on both side with your board like they do with the C2000 Launchpad? Or a female header on the bottom like the Stellaris Launchpad? How do they solder that I wonder..? (I don't have one in front of me right now...) spirilis 1 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.