StefanSch

As far as I can remember, the G2553 has a very small serial buffer. Just try to reduce the number of byte to send, e.g. AT:
Instead of Enter AT commands:

G2553 has a Hardware Serial Interface,  so do not use the Software implementation. 
Serial BTSerial.....
Should work
 

Yes, of course you can do that. Just for the Launchpad the numbering is always done on the boarder of the PCB = Pin Headers of the board, as this is the point where a typical user would connect something.
If you prefer for your own board to have the device pin numbers used - you can do that.
Doing the updates as you mentioned above should do that 🙂
To get the board in the GUI you need to
- add a device in the variants folder - as just discussed with the update of the pins_energia.h file
- add a section into the boards.txt file (located in the folder above)
 in a section the name before the dot needs to be identical (all lines need to start with that) and this name needs to be unique
So take the existing MSP430F5994 part, replace the name before the dot and the name = display name in the selection drop down menu
 
 

Thanks, for the feedback.
I have already implemented the fixes based on your findings and planning for an update release of this package.

It looks like that the compiler setting for the large memory model is not set correct.
can you open the platform.txt file in
c:/users/johnw/appdata/local/energia15/packages/energia/hardware/msp430elf/2.0.7/platform.txt
and change line 21 from
compiler.mlarge_flag=-mlarge -mcode-region=upper
to
compiler.mlarge_flag=-mlarge -mcode-region=either
 

Yes,  this is the right file
(- as the energia-1.8.10E23 did not got a update on the MSP430 tool chain - then it would be in
c:\Users\USERNAME\AppData\Local\Energia15\packages\energia\hardware\msp430
- just for completeness)
Yes, update both lines
 

When using the latest version of Energia the wire (I2C) has now the function
setClock
to set to 400k use setClock(400000UL);

To solve the UART issue go to the pins_energia.h file for the selected device MSP-EXP430G2452LP
and try to update / modify this lines:
static const uint8_t DEBUG_UARTRXD = 4;  /* Receive  Data (RXD) at P1.2 */
static const uint8_t DEBUG_UARTTXD = 3;  /* Transmit Data (TXD) at P1.1 */
This seems to be wrong in the current version but i have no idea why this worked before as i could not find an update where this has been changed.
 
 
To solve the issue with I2C you need to select the other I2C interface with
setModule(0);
The default mapping of the I2C interface to the pins 8 and 9 change a while ago but with the setModule you still can select the other I2C interface if available.
 

this issue got already fixed a while ago - unfortunately the fix did not get merged into the master branch.
Just did the update there so it will go into the next release.
Meanwhile you can fix this locally with patching the wiring.c file. In the function InitClock update the first lines to:
void initClocks(void) { #ifdef __MSP430_HAS_BC2__ #if (defined(CAL_BC1_16MHZ) || defined(CALDCO_16MHZ_)) && F_CPU >= 16000000L BCSCTL1 = CALBC1_16MHZ; DCOCTL = CALDCO_16MHZ; #elif (defined(CAL_BC1_12MHZ) || defined(CALDCO_12MHZ_)) && (F_CPU >= 12000000L) BCSCTL1 = CALBC1_12MHZ; DCOCTL = CALDCO_12MHZ; #elif (defined(CAL_BC1_8MHZ) || defined(CALDCO_8MHZ_)) && (F_CPU >= 8000000L) BCSCTL1 = CALBC1_8MHZ; DCOCTL = CALDCO_8MHZ; #elif (defined(CAL_BC1_1MHZ) || defined(CALDCO_1MHZ_)) && (F_CPU >= 1000000L) BCSCTL1 = CALBC1_1MHZ; DCOCTL = CALDCO_1MHZ; #else #warning No Suitable Frequency found! #endif #endif  

For the non-iso char in the hardware.cpp file i am responsible but I am also not sure how this characters went in but i am sure that this is related to windows.
(for the other files i do not know)
I was quite sure that this was already fixed because it was already highlighted a while ago but looks like it got lost.
 
I also did the update for the I2C library and understand that this did break some older codes but forward looking in made the platform for being compatible across all platforms. Therefore i tried to get the option in to select the interface to make an easy switch back to the old pins.
Looks i have missed some cases - even if i tested this on all launchpads which was a long and boring work !!!
(As already mentioned by Robert this is an open source project and my contribution into this project is done in my private time)
 
Still trying to understand why i have not see the issue with the multi byte and the G2553 register swap not during the testing but thanks a lot for identifying and pushing the fix.
 
There is just on point i would like to clarify - this did not happen on a hidden server:
See issue #651 and pull request #686 where this changes has been pushed to git and merge into the master quite a while ago.