B@tto

Hi,
 
I'm not sure to understand very well your issue : FR5969 is already available on Energia. All you have to do to program it is to connect ground and Spy bi wire lines to a programmer (a launchpad for example, on board MCU of course disconnected removing jumpers) to be able to program it with energia.

Hi Rei,
 
I just tested your library, I had to tune delays :
 
#define DELAY_START_BIT 95///< start bit #define DELAY_SEND_BIT 93 ///< data bits #define DELAY_STOP_BIT 93 ///< stop bit */   Maybe because digitalWrite() is a little bit faster since you wrote this.   But note that my timing are just base on my experiment, I didn't any measure, just experiment different timings. This ones worked.

Hi everyone,
 
I built a library to drive RTC_A feature of some MSP430/CC430.
 
It's available here : https://github.com/battosai30/RTC_A
 
Feel free to test and comment
 
Remark : I haven't tested part about counter mode and I will upload an example soon, but it's very simple to use. Tested calendar mode on my eZ430 chronos and everything seems to go well.

Hi,
 
Is it really for G2533 or you wanted to say G2553 ?

I finally found it
 
So, I used srecord : http://sourceforge.net/projects/srecord/?source=typ_redirect
 
I don't know why, but conversion with python-msp430y-tools is not good : I compared files generated by each of them, and it's not the same result ... Syntax seems to be the same but hex values are not ...
 
To make conversion (on windows), I simply dezipped srecord in my c: disk, and copied my .hex in the same folder. After I launched a command line prompt, and type :
srec_cat test.hex -i -o Firmware.txt -titxt my hex was obviously named test.hex, and ti-txt generated is called firmware.txt and located in the same folder.
 
To make it easier, I made a .bat file with this command (for neophytes, just create a text file, type the previous command in it and rename the file with a .bat extension instead of .txt, after you just have to double-click on it to automatically make a conversion from a .hex named test.hex).
 
After this conversion upload by BSL and TI firmware upgrade tool worked perfectly

Hi everyone,

It just needed some simples modifications but it works now I worked on two different libraries : the one provided by adafruit, and the one provided by 43oh for SSD1306 Booster Pack.

Note that Adafruit is very heavy compared to 43oh : ~19ko vs ~3.5ko 
But it's not the same possibilities ... And the same driving method.

I haven't tested all functions, and only in hardware SPI mode, on F5529 Launchpad. 
43oh based : https://github.com/battosai30/Oled_SSD1306
Adafruit based : https://github.com/battosai30/Adafruit_SSD1306

Should be able to. Chances are either a wiring error or error in your board (bad solder joint, missing a pullup resistor** or maybe the RESET line has a capacitor on it?)
 
** - I can't recall offhand if the FR5xxx series need a pullup resistor on RESET or not. Newer MSP430's like the F5xxx series do not and all others did (47K).

Read section 40.2.3 of the User's Guide.

It's for the USB peripheral.
 
Sent from my Galaxy Note II using Tapatalk

Hi,
 
No problem on my side with MSP432, W7 and Energia 16

Have someone investigate more about this issue ? 
 
I continued with Energia in CCS, and I tested a lot of things, without any success. I also found, I think, errors but correcting them did not do any change for i2c.
 
With debugger I checked registers : everything seems ok, the status eUSCI register shows a busy status and it never changes. 
 
I tried native code supplied by TI in my previous post => no reaction. 
 
All this problem is very strange, it's like no clock is supplied to eUSCI => maybe a problem about clocks ?
 
EDIT : I got it !!! I have no explanation for now, but the problem is initiating START manipulating UCB0CTLW0 register. If you do :
 
UCB0CTLW0 |= UCTXSTT; 
 
It will not work, with :
 
UCB0CTL1 |= UCTXSTT; 
 
I got interruption. 
 
Normally it would be the same, but I don't know why, it's not. To discover that, I simply used an example code provide by TI in Ressource Explorer :
 
//****************************************************************************** //  MSP430FR59xx Demo - eUSCI_B0 I2C Master RX multiple bytes from MSP430 Slave // //  Description: This demo connects two MSP430's via the I2C bus. The master //  reads 5 bytes from the slave. This is the MASTER CODE. The data from the slave //  transmitter begins at 0 and increments with each transfer. //  The USCI_B0 RX interrupt is used to know when new data has been received. //  ACLK = n/a, MCLK = SMCLK = BRCLK =  DCO = 1MHz // //    *****used with "MSP430FR59xx_euscib0_i2c_11.c"**** // //                                /|\  /|\ //               MSP430FR5969      10k  10k     MSP430F5969 //                   slave         |    |        master //             -----------------   |    |   ----------------- //           -|XIN  P1.6/UCB0SDA|<-|----+->|P1.6/UCB0SDA  XIN|- //            |                 |  |       |                 | 32kHz //           -|XOUT             |  |       |             XOUT|- //            |     P1.7/UCB0SCL|<-+------>|P1.7/UCB0SCL     | //            |                 |          |             P1.0|--> LED // //   P. Thanigai //   Texas Instruments Inc. //   Feb 2012 //   Built with CCS V5.5 //****************************************************************************** #include <msp430.h> volatile unsigned char RXData; int main(void) {   WDTCTL = WDTPW | WDTHOLD;   // Configure GPIO   P1OUT &= ~BIT0;                           // Clear P1.0 output latch   P1DIR |= BIT0;                            // For LED   P1SEL1 |= BIT6 | BIT7;                    // I2C pins   // Disable the GPIO power-on default high-impedance mode to activate   // previously configured port settings   PM5CTL0 &= ~LOCKLPM5;   // Configure USCI_B0 for I2C mode   UCB0CTLW0 |= UCSWRST;                     // Software reset enabled   UCB0CTLW0 |= UCMODE_3 | UCMST | UCSYNC;   // I2C mode, Master mode, sync   UCB0CTLW1 |= UCASTP_2;                    // Automatic stop generated                                             // after UCB0TBCNT is reached   UCB0BRW = 0x0008;                         // baudrate = SMCLK / 8   UCB0TBCNT = 0x0005;                       // number of bytes to be received   UCB0I2CSA = 0x0077;                       // Slave address   UCB0CTL1 &= ~UCSWRST;   UCB0IE |= UCRXIE | UCNACKIE | UCBCNTIE;   while (1)   {     __delay_cycles(2000);     while (UCB0CTL1 & UCTXSTP);             // Ensure stop condition got sent     UCB0CTL1 |= UCTXSTT;                    // I2C start condition     __bis_SR_register(LPM0_bits | GIE);     // Enter LPM0 w/ interrupt   } } #if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__) #pragma vector = USCI_B0_VECTOR __interrupt void USCI_B0_ISR(void) #elif defined(__GNUC__) void __attribute__ ((interrupt(USCI_B0_VECTOR))) USCI_B0_ISR (void) #else #error Compiler not supported! #endif {   switch(UCB0IV)   {     case USCI_NONE:          break;         // Vector 0: No interrupts     case USCI_I2C_UCALIFG:   break;         // Vector 2: ALIFG     case USCI_I2C_UCNACKIFG:                // Vector 4: NACKIFG       UCB0CTL1 |= UCTXSTT;                  // I2C start condition       break;     case USCI_I2C_UCSTTIFG:  break;         // Vector 6: STTIFG     case USCI_I2C_UCSTPIFG:  break;         // Vector 8: STPIFG     case USCI_I2C_UCRXIFG3:  break;         // Vector 10: RXIFG3     case USCI_I2C_UCTXIFG3:  break;         // Vector 12: TXIFG3     case USCI_I2C_UCRXIFG2:  break;         // Vector 14: RXIFG2     case USCI_I2C_UCTXIFG2:  break;         // Vector 16: TXIFG2     case USCI_I2C_UCRXIFG1:  break;         // Vector 18: RXIFG1     case USCI_I2C_UCTXIFG1:  break;         // Vector 20: TXIFG1     case USCI_I2C_UCRXIFG0:                 // Vector 22: RXIFG0       RXData = UCB0RXBUF;                   // Get RX data       __bic_SR_register_on_exit(LPM0_bits); // Exit LPM0       break;     case USCI_I2C_UCTXIFG0:  break;         // Vector 24: TXIFG0     case USCI_I2C_UCBCNTIFG:                // Vector 26: BCNTIFG       P1OUT ^= BIT0;                        // Toggle LED on P1.0       break;     case USCI_I2C_UCCLTOIFG: break;         // Vector 28: clock low timeout     case USCI_I2C_UCBIT9IFG: break;         // Vector 30: 9th bit     default: break;   } }  

I investigated a little bit more, playing with Energia in CCS, so with debug. The micro stay exactly stuck here :
 
line 446 of twi.c , twi_writeTo() function:
/* Wait for the transaction to complete */ while(twi_state != TWI_IDLE) { __bis_SR_register(LPM0_bits); } I placed breakpoints in interrupt routines : simply nothing happens. As it's the part in twi.c where i2c start condition is called, I had interrupt enabled on start (UCSSTTIE) ==> still no interrupt.
 
To resume : twi_state value is managed by ISR, but no ISR seem to happen, so twi_state is never set to TWI_IDLE, so the while() condition is never good and we stay here.
 
Note : during this part, twi_state value is 0x02

I have an Adafruit I2C RTC that I will try with the FR5969.  I thought I had used it successfully in the past but when I pulled it up again this evening I didn't get it going right off the bat.  Will try again and let you know if I am successful.
 
UPDATE
=======
I couldn't get the RTC to work when I tried again today - I do a Wire.begin() and then it calls a library where it freezes.
 
I then tried with a LCD that has an I2C backpack.  I got it running on the F5529 and moved it to the FR5969.  It doesn't freeze completely but gives garbage on the LCD that changes from time to time.  I checked the wiring and it seems correct. 
 
So I am unsuccessful getting I2C to work on the FR5969 as well.  I am using Energia E0015.

Hey guys,
 
Some news : at this moment I was not looking for it but I found this http://www.alphamicrowireless.com/media/433544/gtop%20module%20application%20note%20-a00%20_mt3339%20series_.pdf
 
The hardware design application note ! So I think my troubles comes from my tracks : a large major part of the surface under the GPS module is GND plane, but some tracks pass througth it. I think it's the only explanation ... For now I stop to work with this module.
 
Now I'm working with SIM808 which has, looking to its specifications, an MT3339 as GPS chip (the specs are exactly the same). Only one UART needed and all the job is done by the SIM808, you just have to parse the GPS message when position is ok  
 
But I also noticed that I still have this big error on position. After spending almost an afternoon, I found the solution : https://labs.mediatek.com/forums/posts/list/124.page  I just needed to convert to "real" decimal coordinates, so multipliate decimal parts by 100/60
 
Hope it will help

Hey guys,
 
Some news : at this moment I was not looking for it but I found this http://www.alphamicrowireless.com/media/433544/gtop%20module%20application%20note%20-a00%20_mt3339%20series_.pdf
 
The hardware design application note ! So I think my troubles comes from my tracks : a large major part of the surface under the GPS module is GND plane, but some tracks pass througth it. I think it's the only explanation ... For now I stop to work with this module.
 
Now I'm working with SIM808 which has, looking to its specifications, an MT3339 as GPS chip (the specs are exactly the same). Only one UART needed and all the job is done by the SIM808, you just have to parse the GPS message when position is ok  
 
But I also noticed that I still have this big error on position. After spending almost an afternoon, I found the solution : https://labs.mediatek.com/forums/posts/list/124.page  I just needed to convert to "real" decimal coordinates, so multipliate decimal parts by 100/60
 
Hope it will help

Good news
 
Try to first let it stay fix during 10-20 minutes. After that, normally it will be able to fix very quickly (few seconds) in a limit of 2 hours

Hi,
 
It's for MSP430 which have USB peripheral, such as F5529. 
 
To compare, it's like Arduino leonardo for example.

Hi,
 
It's for MSP430 which have USB peripheral, such as F5529. 
 
To compare, it's like Arduino leonardo for example.

Sounds like a good idea/workaround ... I made some MT3329/39 boards last year and had the same problems on some boards (I tried different designs). I were not able to meet all the design recommendations regarding ground plane etc. given in the data sheet, so this could be a problem with my designs, too. Sometimes it took minutes (10-20) until I had a fix. On other boards/designs I got a fix in less than one minute.
 
So I will try your workaround as soon as I find some time ...
 
Best wishes

When you tested it away from the board, was it still getting it's power from the same supply? I'm wondering if it is a decoupling issue (or something simpler like your power supply is having a voltage drop under the load of both the GPS and the MCU).
 
Do you have the power to both the MCU and the GPS adequately decoupled with capacitors situated as close as possible to the power pins of the IC's?  Generally I would use decoupling capacitors of 0.1uF and 10-47uF with the MSP430. The 0.1uF covers the system clock frequency range, while the larger capacitor covers the frequencies used by the low speed oscillator (VLO clock or the crystal), UART etc. Using a GPS, I'd probably also put in a 0.001uF to cover the gigahertz range of frequencies that GPS uses.  These are typical values - the actual theory behind optimal decoupling capacitor values is quite complex, but the figures above will do the job fine on most designs.

Hi, thanks for your answer.
 
In the original conception, I use a 1

A good blog about msp430 for beginners (it's where I started to learn how to program msp430 in fact) : http://mspsci.blogspot.fr/2010/12/tutorial-12-making-comparisons.html

If you still want to use timers, you can look on this blog, very interresting for beginners who want to "code hard" and understand how msp430 really works behind Energia :
 
http://mspsci.blogspot.fr/2010/08/tutorial-09-timers.html
http://mspsci.blogspot.fr/2010/08/tutorial-10-something-completely.html
http://mspsci.blogspot.fr/2010/08/tutorial-10-b-interrupt-examples.html
 
TI also provides a lots of example codes 

The best way to find this kind of things is to search the .h corresponding to your micro in \hardware\tools\msp430\msp430\include
So you will find the global defines like the one you were looking for, and for the peripherals 

Hi everyone,
 
I'm working on Energia CC430 support. It's the first time I do this kind of work, it allowed me to understand a lot of things but not everything of course So I have a lot of questions !
 
So for now where I am : I'm working on a eZ430 - Chronos 433 mhz (==> CC430F6137). I program it with the ez430 USB stick (I will see later for upload using radio BSL). 
 
For now I just tried to get something working, I made a pin_energia.h creating a new MSP430 variant. I edited the board.h and I had to modify wiring.c to get the clock system working  :
 
Original line 168 :
 
#if defined(__MSP430_HAS_UCS__)
 
Modified to :
 
#if defined(__MSP430_HAS_UCS__) || defined(__MSP430_HAS_UCS_RF__)
 
I used some function from the eZChronos firmware provided by TI to test if the system was running, here is the code : 
https://github.com/battosai30/CC430_EnergiaSupport/blob/master/Test/Heart.cpp
 
Upload using Energia integrated in CCS v6 ==> IT WORKS the heart on the LCD is beating !
 
Now I am trying to understand if my modification of wiring.c is enought, and if other Energia features are OK.
 
All files are here : https://github.com/battosai30/CC430_EnergiaSupport
 
Now my questions :
 
1) What is interesting me the most is the radio core. TI provides some interesting low level libraries I can re-use, but I don't know how to integrate it directly in the core. I plans to work on others features like LCD_B, AES ... I think it would be better to directly integrate it and to do not have to add a library each time.
 
2) I found some defines in msp430's pins_energia.h :
 
#define TWISDA_SET_MODE  (PORT_SELECTION0 | PORT_SELECTION1 /* | INPUT_PULLUP*/) /* do not enable the pull ups for this device */ #define TWISCL_SET_MODE  (PORT_SELECTION0 | PORT_SELECTION1 /* | INPUT_PULLUP*/) #define DEBUG_UARTRXD_SET_MODE (PORT_SELECTION0 | PORT_SELECTION1 | INPUT) #define DEBUG_UARTTXD_SET_MODE (PORT_SELECTION0 | PORT_SELECTION1 | OUTPUT) #define SPISCK_SET_MODE (PORT_SELECTION0 | PORT_SELECTION1) #define SPIMOSI_SET_MODE (PORT_SELECTION0 | PORT_SELECTION1) #define SPIMISO_SET_MODE (PORT_SELECTION0 | PORT_SELECTION1) #define DEBUG_UART_MODULE_OFFSET 0x0 I don't really understand what they mean ...
 
3) How the PMAP is used in Energia ? I found a PMAP maping in fraunchpad pins_energia.h but I did not found where it's used.
 
4) I just need a confirmation : function "const uint8_t digital_pin_to_timer[]" is used to define pins PWM compatible ?
 
5) In wiring.c init() :
 
/* Clear P2.6 and P2.7 bits to default to GPIO */ #ifdef P2SEL2 P2SEL &= ~(BIT6|BIT7); #endif Why this lines ? Thanks !