Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Reputation Activity

  1. Like
    StefanSch got a reaction from alphanumeric35 in AT Commands with Software Serial on MSP430   
    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:
  2. Like
    StefanSch got a reaction from alphanumeric35 in AT Commands with Software Serial on MSP430   
    G2553 has a Hardware Serial Interface,  so do not use the Software implementation. 
    Serial BTSerial.....
    Should work
  3. Thanks
    StefanSch got a reaction from JasonL in MSP430FR5994 pins_energia.h misunderstanding   
    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
  4. Thanks
    StefanSch got a reaction from Rei Vilo in MSP430 use FRAM above 0x10000   
    Thanks, for the feedback.
    I have already implemented the fixes based on your findings and planning for an update release of this package.
  5. Thanks
    StefanSch got a reaction from Rei Vilo in MSP430 use FRAM above 0x10000   
    It looks like that the compiler setting for the large memory model is not set correct.
    can you open the platform.txt file in
    and change line 21 from
    compiler.mlarge_flag=-mlarge -mcode-region=upper
    compiler.mlarge_flag=-mlarge -mcode-region=either
  6. Like
    StefanSch got a reaction from mgs in upload error - filename syntax is incorrect   
    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
    - just for completeness)
    Yes, update both lines
  7. Like
    StefanSch got a reaction from Rei Vilo in I2C communication in energia background with MSP430F5529   
    When using the latest version of Energia the wire (I2C) has now the function
    to set to 400k use setClock(400000UL);
  8. Like
    StefanSch got a reaction from energia in MSP430G2 no communication   
    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
    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.
  9. Thanks
    StefanSch got a reaction from alpinistbg in Blink example too slow   
    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  
  10. Like
    StefanSch got a reaction from Rei Vilo in Using HW (not SW) I2C   
    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.
  • Create New...