This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR6047: MSP430FR6047

Part Number: MSP430FR6047

Hello everyone, I am working with EVM430FR6047 with the application " MSP430FR6047EVM_USS_Water_Demo ". So the idea is sending data from MSP430 to my Arduino board over I2C protocol. However when I implement the I2C function to the main source code, i am losing the connection between EVM430FR6047 board and the USS ( Ultrasonic sensing design center) software. Is this the problem about using I2C because board is communicating with the computer over I2C ? 

As far as I see from the datasheet this evaluation board has two I2C peripherals, I thought this would solve the issue.Is there any way to solve this problem ? Now I will provide you my code as well. If this is the problem about using I2C and would not be possible to use the I2C for data sending without losing the communication with USS, would it work with UART ? Thank you for your help. ( UART protocol is commented out) 

void main(void)
{

WDTCTL = WDTPW + WDTHOLD;

/* EUSCI_A_UART_initParam uartParams = {
.selectClockSource = UCSSEL_2, // SMCLK as clock source
.msborLsbFirst = 0, // MSB first
.numberofStopBits = 0, // 1 stop bit
.parity = EUSCI_A_UART_NO_PARITY, // No parity
.clockPrescalar = 104, // Baud rate control
.firstModReg = 1, // First modulation stage
.secondModReg = 0, // Second modulation stage
.overSampling = 0, // No oversampling
.uartMode = UCMODE_0, // UART mode
};


EUSCI_A_UART_init(EUSCI_A0_BASE, &uartParams);
EUSCI_A_UART_transmitData(EUSCI_A0_BASE, 'A');
*/


EUSCI_B_I2C_initMasterParam i2cParams = {
.selectClockSource = EUSCI_B_I2C_CLOCKSOURCE_SMCLK, // Use SMCLK as clock source
.i2cClk = 100000, // I2C clock frequency (Hz)
.dataRate = 10000, // Desired data rate (Hz)
.autoSTOPGeneration = EUSCI_B_I2C_NO_AUTO_STOP, // No automatic STOP generation
.byteCounterThreshold = 0, // No byte counter threshold
};


uint16_t reset_source = 0x00;

// Initializes the basic functionality of the system
hal_system_Init();

// Initialize interfaces to user including buttons, LCD, GUI
HMI_Init();

// Verify the reset source and log/report if there was an error
reset_source = hal_system_GetResetSource();
if(reset_source != 0x00)
{
USSLibGUIApp_send_error(COMMAND_HANDLER_ERROR_FAULT_RESET_ERROR,
reset_source);
}

__enable_interrupt();

// Initialize the USS Lib
USSLibGUIApp_Init();


//EUSCI_B_I2C_initMaster(EUSCI_B0_BASE, &i2cParams);
// EUSCI_B_I2C_setSlaveAddress(EUSCI_B0_BASE, 0x42);
// EUSCI_B_I2C_enable(EUSCI_B0_BASE);

while(1) {


EUSCI_B_I2C_initMaster(EUSCI_B0_BASE, &i2cParams);
EUSCI_B_I2C_setSlaveAddress(EUSCI_B0_BASE, 0x42);
EUSCI_B_I2C_enable(EUSCI_B0_BASE);
EUSCI_B_I2C_masterSendSingleByte(EUSCI_B0_BASE, 'A');

USSLibGUIApp_Engine();
}


}

  • Hi Umut,

    You are likely correct that the initial I2C issue is due to the fact that the EVM communicates with the computer using I2C. However I would also expect that changing the I2C peripheral that you use with your Arduino would help resolve this issue. I personally have not added an I2C peripheral to the EVM and it would take me some time to debug and figure out the issue here.

    If UART is a viable option, I would encourage you to use the FR6047 USSSWLIB template example. This version is the version that is intended to be a reference for production use, so it does not have the GUI functionality, but it has the UART peripheral already set-up for communicating with another device like an Arduino. I have also used this myself so I could be of better assistance to you if you went this route. 

    Please let me know if this helps, or if you need further assistance with the I2C peripheral.

  • Hi Dylan,

    To be honest, I couldn`t initialize UART successfully even though I tried the same way I did with I2C.However, without GUI I have the I2C which is working. But I have to have function USSLibGUIApp_Engine(); working so I need the entire Ultrasound sensing application. I did not understand what do you mean exactly about UART but if GUI functionality is not working with UART, it is not a viable option for me. I would be really happy if we can find a solution that I have GUI functionality and I2C working.  

  • I see. I did mean using UART without the GUI, so we can move on from this suggestion.

    You may need to try an approach that does not use interrupts for I2C with the GUI. It seems that this often leads to some issues with the GUI. Could you try this in your implementation? 

  • Hi Dylan, I don`t use any interrupt in my implementation. However there might be an interrupt in of the the files in this complete source code.I couldn`t find it and that`s why I need help from a TI expert. 

  • You should leave the interrupts that the GUI uses, they are critical to the GUI behavior, so you don't need to dig through the source code to find the interrupts it contains. I see your initialization code above, could you show me the code you use to actually perform the I2C send? Have you implemented this yet?

  • I am actually sending my I2C message with the code above, inside while(1) loop

    while(1) {
    EUSCI_B_I2C_initMaster(EUSCI_B0_BASE, &i2cParams);
    EUSCI_B_I2C_setSlaveAddress(EUSCI_B0_BASE, 0x42);
    EUSCI_B_I2C_enable(EUSCI_B0_BASE);
    EUSCI_B_I2C_masterSendSingleByte(EUSCI_B0_BASE, 'A');

    USSLibGUIApp_Engine();
    }

    }

    Please see the highlighted function.

  • Oh so you have not even started the GUIApp_Engine and you are unable to use the I2C? Have you tried using one of the I2C (no USS included) examples to check the behavior of the I2C then? Or have you tested your I2C implementation without any of the USS code? It is important to isolate the issue to I2C before we start looking at the more complex USS code.

    If you haven't already, could you try using MSP430FR60x3_euscib0_i2c_11.c and testing the I2C out there? And once that is working, work on adding the I2C functionality into the USS Demo code.

    Please let me know if you try this, or if you've done this already. I am surprised to see that you are having these issues before the GUI App engine runs. 

  • Let me explain the statement of the code again. My I2C function is working in the above code that you are seeing right now. I have used my arduino to see if my I2C messages are being sent and it was successful so I received the messages from EVM430 board. But I2C function is only working when I call it before the USSLibGUIApp_Engine();. So with my problem two statements are valid such as,

    1. I call I2C function before USSLIBGUI and send message to arduino successfully, however I can`t connect with the USS application.

    2. I call USSLIBGUI before I2C function, I can connect with the USS application but my arduino doesn`t receive any message.


    As you can see above I am also calling my USSLibGUI function after the I2C function but still can`t connect to the USS app.

  • Hi  Umut,

    I don't really know any of that code. But my suspicion is that this is an issue in the SW. Let's assume any of the two parts is blocking at some point (waiting for some data). In normal case the interrupt that receives data sets a flag to unblock processing. Then this would make the main function continue and process the data. Now if you combine two of such functions in a single threaded system that does not work without changing some of the code.

    One way to find out is to use the debugger and see where your code is blocked. Did you try that yet? Basically run the app and once it stops reacting stop t with the debugger and see where PC is at. You could also do some single stepping to see what is happening. 

    Regards, Frank

  • Hello Frank, we have decided to use UART instead of I2C and we implemented the protocol with my colleague. It is working as I want and there is no problem for now. So we can close this discussion. Thank you all. :) 

  • Hi Umut,

    thanks for the update. You can confirm this is closed by clicking the resolved button. Thanks. 
    I saw your latest entry and will let our experts follow up on this.

    Regards, Frank

**Attention** This is a public forum