Quantcast
Channel: MSP low-power microcontroller forum - Recent Threads
Viewing all 21946 articles
Browse latest View live

MSP430FR5949: Real Time clock, using VLO

$
0
0

Part Number:MSP430FR5949

Is it possible (as advertised by TI) to use the on board VLO as the clock source for the RTC on the fr5949 ? It doesn't seem so from the available register settings. 


MSP430I2041: EnergyMeasurementDesignCenterWorkspace : Error in IAR

$
0
0

Part Number:MSP430I2041

Hi,

I am import a source code from EnergyMeasurementDesignCenterWorkspace for MSP430I2041, when I compile this code in IAR than I got following error

Fatal Error[e59]: Module dc_filter16 ( D:\R&D\New Developmwnt\EnergyMeasurementDesignCenterWorkspace_RC_2041\UNTITLED\src\lib\EM\IAR\
MSP430i2xx\EMLib_IAR_MSP430i2xx_small_code_small_data.lib ) uses UBROF revision 11.1.0. This XLINK only supports UBROF revisions up to 11.0.3

Error while running Linker

Please resolve

TIDM-1019: USS - Meter constant error

$
0
0

Part Number:TIDM-1019

I recently purchased an eval board for the MSP430FR6047 Water Meter. I use transducers from Audiowell (same as those used in documention).

The pipe with transducers is on a testing bench with a flowrate (water) fixed at 500L/h.

I read the mean value of the flowrate on USS, and i'm able to calculate the new "Meter constant".

The problem is, when i want to change the default value (12742000.00) by the new one (33390985.00), i've the following error " Non-advanced parameter error : Invalid Meter Constant"

Can you help me ? I didn't find any solution in the documentation

i'm using this version : UltrasonicWaterFR604x_02_20_00_08

Best Regards,

Maxime

CCS/MSP430FR2155: I2C working fine when debugging and but stuck in Continuous run

$
0
0

Part Number:MSP430FR2155

Tool/software: Code Composer Studio

I am trying to communicate through I2C in MSP430FR2155 as master device and Arduino Uno as slave device .

when I am debugging my code and execute program line by line the Code works and send data to Arduino.

but when I start continuous mode the code get stuck in while loop and communication stops. I am using standard driver provided from ti web sites.

void EUSCI_B_I2C_masterSendSingleByte(uint16_t baseAddress,
                                      uint8_t txData)
{
    //Store current TXIE status
    uint16_t txieStatus = HWREG16(baseAddress + OFS_UCBxIE) & UCTXIE;

    //Disable transmit interrupt enable
    HWREG16(baseAddress + OFS_UCBxIE) &= ~(UCTXIE);

    //Send start condition.
    HWREG16(baseAddress + OFS_UCBxCTLW0) |= UCTR + UCTXSTT;

    //Poll for transmit interrupt flag.
    while(!(HWREG16(baseAddress + OFS_UCBxIFG) & UCTXIFG))
    {
        ;
    }

    //Send single byte data.
    HWREG16(baseAddress + OFS_UCBxTXBUF) = txData;

    //Poll for transmit interrupt flag.
    while(!(HWREG16(baseAddress + OFS_UCBxIFG) & UCTXIFG))
    {
        ;
    }

    //Send stop condition.
    HWREG16(baseAddress + OFS_UCBxCTLW0) |= UCTXSTP;

    //Clear transmit interrupt flag before enabling interrupt again
    HWREG16(baseAddress + OFS_UCBxIFG) &= ~(UCTXIFG);

    //Reinstate transmit interrupt enable
    HWREG16(baseAddress + OFS_UCBxIE) |= txieStatus;
}

the execution stuck at 

while(!(HWREG16(baseAddress + OFS_UCBxIFG) & UCTXIFG))...

any suggestion?

MSP430FR5994: Nothing but issues with I2C

$
0
0

Part Number:MSP430FR5994

Come, sit down! Let me weave for you a tale of the most frustrating experience I've ever had with getting I2C to work...This is going to be a long one, but hopefully it helps some other people that are struggling with this board, and hopefully I can get some feedback that clears up the issues I'm still having.

Board: MSP430FR5994 Launchpad

IDE: CCSv8

Compiler: TI v18.1.5.LTS

I'm working with the FR5994 Launchpad, an Adafruit BMP280 breakout, and an Adafruit VL53L0X breakout to develop code for a larger device. I've worked with MSP430s and both sensors before, so I thought it would be a fairly quick process to get I2C up and running with them...not so much. I have spent the last three weeks searching forums, scouring the User Guide and example code, and I am still having trouble. Three weeks. So please, believe me when I say that I've tried damn near everything.

First things first: I'm not using the driverlib. Can't. There's too much going on this chip to clutter it with that. 

Second: Yes, there are pullups (10k Ohm) on the SDA/SCL lines. They are at 3.3V. 

Third: I've been using a scope since week 2 to debug. I'll be attaching pictures. 

So let's start with what works! After fruitlessly trying to get the interrupt method outlined in the user guide to work, I decided to go back to basics and try a simple polling protocol. This works for the BMP280, but there are some weird (let's call them) idiosyncrasies that keep it from working with the VL53L0X. Sidenote: I was only able to get this working after finding this equally frustrated individual: (https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/702571?MSP430FR5994-I2C-Inaccurate-eUSCI-description-on-User-s-Guide)  

I first initialize the board pins and eUSCI bus:

void bmp280::initialize(){
    // Configure GPIO
    P1OUT &= ~BIT0;             // Clear P1.0 output latch
    P1DIR |= BIT0;              // For LED

    // Configure interface ports
    P7SEL0 |=  (BIT0 | BIT1);   // Connect ports P7.0 and P7.1 to
    P7SEL1 &= ~(BIT0 | BIT1);   // eUSCI-B1, SDA and SCL, respectively
    P7DIR  &= ~(BIT0 | BIT1);   // Configure as if they are inputs

    PM5CTL0 &= ~LOCKLPM5;       // Disable GPIO power-on high-impedance mode

    UCB2CTLW0 = UCSWRST;        // Reset I2C interface for configuration

    UCB2CTLW0 =                 /* USCI - B2 configuration register */
                UCMST         | // Master mode
                UCSYNC        | // Synchronous mode
                UCMODE_3      | // I2C mode
                UCSSEL__SMCLK | // Select SMCLK
                UCTR          | // Transmitter mode
                UCSWRST       | // Don't release reset (yet)
                0;

    UCB2CTLW1 =
                UCCLTO_0      | // Clock low time-out select (disabled)
                UCASTP_0      | // Automatic STOP condition generation (disabled)
                UCGLIT_0      | // Deglitch time (50ns)
                0;

    UCB2BRW = 10;               // Bit clock divider 1M/10 = 100kHz

    UCB2CTLW0 &= ~UCSWRST;      // Clear reset bit to start operation

    __delay_cycles(50);
}

Then I read/write to the device, manually polling for the RX/TX flags, and setting the start/stop bits. Here's a read example:

void bmp280::readID(){
    UCB2I2CSA = BMP280_ADDRESS;             // Set slave address
    UCB2CTLW0 |= UCTR | UCTXSTT;            // Start request as transmitter

    while(!(UCB2IFG & UCTXIFG));            // Wait until TXBUFF is empty
    UCB2TXBUF = BMP280_REGISTER_CHIPID;     // Send first data byte

    while(UCB1CTLW0 & UCTXSTT);             // Wait for slave's response

    while(!(UCB2IFG & UCTXIFG));            // Wait for the last byte to be loaded to shift register
    UCB2CTLW0 |= UCTXSTP;                   // Request a stop condition
    while (UCB2CTLW0 & UCTXSTP);            // Wait until stop was sent

    UCB2IFG &= ~UCTXIFG;                    // Clear TX flag

    UCB2CTLW0 &= ~UCTR;                     // Put I2C bus in receive mode

    UCB2CTLW0 |= UCTXSTT;                   // Start request as a receiver

    rxCount = 1;                            // Set number of bytes to receive

    while(rxCount){                         // Loop until data is collected
        UCB2CTL1 |= UCTXSTP;               // Generate I2C stop condition (with a nack before that, which is handled by hardware automatically)
        while(!(UCB2IFG & UCRXIFG));        // Wait until RXBUF is full
        rxBuffer = UCB2RXBUF;               // Pull data from buffer
        rxCount--;
    }

    chipID = rxBuffer;                      // Store data
}

Here's a write example: 

void bmp280::configure(){
txCount = 2; // Set number of bytes to send

UCB2I2CSA = BMP280_ADDRESS; // Set slave address
UCB2CTLW0 |= UCTR | UCTXSTT; // Start request as transmitter

while(!(UCB2IFG & UCTXIFG)); // Wait until TXBUFF is empty
UCB2TXBUF = BMP280_REGISTER_CONTROL; // Send first data byte

while(UCB1CTLW0 & UCTXSTT); // Wait for slave's response

if (UCB2IFG & UCNACKIFG) { // If there was no response
UCB2IFG &= ~UCNACKIFG; // Clear NACK flag
UCB2CTLW0 |= UCTXSTP; // Request a stop
while (UCB2CTLW0 & UCTXSTP); // And wait until stop was actually sent
UCB2IFG &= ~UCSTPIFG; // Clear stop flag (not actually using this..)
}
else { // If there was a reply from the slave,
while (--txCount) { // send the remaining bytes
while(!(UCB2IFG & UCTXIFG));
UCB2TXBUF = 0x26; // Temp/Pressure oversampling x1, forced mode
// Must rewrite "forced mode" command for each measurement
}
}

while(!(UCB2IFG & UCTXIFG)); // Wait for the last byte to be loaded to shift register
UCB2CTLW0 |= UCTXSTP; // Request a stop condition
while (UCB2CTLW0 & UCTXSTP); // Wait until stop was sent

UCB2IFG &= ~UCTXIFG; // Clear TX flag
}

These work, but the read has the frustrating result of sometimes (somehow) returning two bytes instead of 1. How this happens, I have no idea, and because it's intermittent I'm now struggling to get a scope shot of it. Additionally, and maybe this has more to do with CCS than the MSP430, when I'm in Debug mode, the program will sometimes get hung at this line: while(!(UCB2IFG & UCTXIFG)); Again, no idea why this happens, because if I power cycle the board and let it run freely, not in debug mode, it works just fine! Another example of someone having this issue can be found here: http://e2e.ti.com/support/microcontrollers/msp430/f/166/p/558315/2046359?tisearch=e2e-sitesearch&keymatch=fr5994#2046359

Regardless, the real issues lie in the interrupt method that TI seems to favor in their User Guide and example code. This is also the method that is required for the project I'm working on. We can't risk the polling method getting hung intermittently, and we don't want I2C data getting dropped because other interrupts override the I2C data transfer. So interrupts are a must.

After learning the lessons I learned with the polling method I show above, I was finally (finally!) able to get the I2C interrupts to work...but it required HEAVY tweaking/debugging...and it's still not working 100% how you would expect. 

I first initialize the board pins and configure the I2C bus to use interrupts. I also have a secondary I2C configuration function for instances when interrupts don't work well:

void bmp280::initialize(){
    // Configure GPIO
    P1OUT &= ~BIT0;             // Clear P1.0 output latch
    P1DIR |= BIT0;              // For LED

    // Configure interface ports
    P7SEL0 |=  (BIT0 | BIT1);   // Connect ports P5.0 and P5.1 to
    P7SEL1 &= ~(BIT0 | BIT1);   // eUSCI-B1, SDA and SCL, respectively
    P7DIR  &= ~(BIT0 | BIT1);   // Configure as if they are inputs

    PM5CTL0 &= ~LOCKLPM5;       // Disable GPIO power-on high-impedance mode

    i2cConfig(0x01);            // Configure i2c bus with stop count of 1 byte

    __delay_cycles(50);
    __bis_SR_register(GIE);     // Enable interrupts
}

void bmp280::i2cConfig(uint8_t stop_count){
    UCB2CTLW0 = UCSWRST;        // Reset I2C interface for configuration

    UCB2CTLW0 =                 /* USCI - B2 configuration register */
                UCMST         | // Master mode
                UCSYNC        | // Synchronous mode
                UCMODE_3      | // I2C mode
                UCSSEL__SMCLK | // Select SMCLK
                UCTR          | // Transmitter mode
                UCSWRST       | // Don't release reset (yet)
                0;

    UCB2CTLW1 =
                UCCLTO_1      | // Clock low time-out select (28ms)
                UCASTP_2      | // Automatic STOP condition generation (enabled)
                UCGLIT_0      | // Deglitch time (50ns)
                0;

    UCB2TBCNT = stop_count;

    UCB2BRW = 10;               // Bit clock divider 1M/10 = 100kHz

    UCB2CTLW0 &= ~UCSWRST;      // Clear reset bit to start operation

    UCB2IE = 0;

    UCB2IE = UCNACKIE         | // Enable Nack interrupt
             UCTXIE           | // Enable TX interrupt
             UCRXIE           | // Enable RX interrupt
             UCCLTOIE         | // Enable clock low time-out interrupt
             0;
}

void bmp280::i2cConfig_noInt(){
    UCB2CTLW0 = UCSWRST;        // Reset I2C interface for configuration

        UCB2CTLW0 =                 /* USCI - B2 configuration register */
                    UCMST         | // Master mode
                    UCSYNC        | // Synchronous mode
                    UCMODE_3      | // I2C mode
                    UCSSEL__SMCLK | // Select SMCLK
                    UCTR          | // Transmitter mode
                    UCSWRST       | // Don't release reset (yet)
                    0;

        UCB2CTLW1 =
                    UCCLTO_1      | // Clock low time-out select (28ms)
                    UCASTP_0      | // Automatic STOP condition generation (enabled)
                    UCGLIT_0      | // Deglitch time (50ns)
                    0;

        UCB2BRW = 10;               // Bit clock divider 1M/10 = 100kHz

        UCB2CTLW0 &= ~UCSWRST;      // Clear reset bit to start operation

        UCB2IE = 0;
}

I found that trying to manually set the stop bit while in the interrupt led to overflow/timing issues. These went away when I used the auto stop...however, the drawback of this is you have to reconfigure the I2C bus every time you want to write/read a different number of bytes. So, for instance, if I want to read in 3 bytes, I would have to set the stop counter to 1, transmit the register to read from, reset the stop counter to 3, then read in the 3 bytes of data. This is clunky, and (not surprisingly) does not work as advertised...more on this later. In general, the auto stop works as long as I'm not changing the stop counter all the time. 

Here are my read/write functions and the interrupt definitions: 

void bmp280::write(uint8_t reg, uint8_t data){
    i2cConfig(0x02);

    mBuffer[0] = reg;
    mBuffer[1] = data;
    transmit(mBuffer,2);
    for(int i=0;i<50;i++);
}

void bmp280::read(uint8_t reg){
    i2cConfig(0x01);
    __delay_cycles(50);

    transmit(&reg,1);
    for(int i=0;i<50;i++);
    receive(mBuffer,1);
    for(int i=0;i<100;i++);
}

void bmp280::read16(uint8_t reg){
    i2cConfig_noInt();

    UCB2I2CSA = BMP280_ADDRESS;             // Set slave address
    UCB2CTLW0 |= UCTR | UCTXSTT;            // Start request as transmitter

    while(!(UCB2IFG & UCTXIFG));            // Wait until TXBUFF is empty
    UCB2TXBUF = reg;                        // Send first data byte

    while(UCB1CTLW0 &  UCTXSTT);            // Wait for slave's response

    while(!(UCB2IFG & UCTXIFG));            // Wait for the last byte to be loaded to shift register
    UCB2CTLW0 |= UCTXSTP;                   // Request a stop condition
    while (UCB2CTLW0 & UCTXSTP);            // Wait until stop was sent

    UCB2IFG &= ~UCTXIFG;                    // Clear TX flag

    i2cConfig(0x02);
    rxData = 0;

    receive(mBuffer,2);
    for(int i=0;i<50;i++);
    
    rxData = (mBuffer[0] << 8) | mBuffer[1];
}

void bmp280::read24(uint8_t reg){
    i2cConfig_noInt();


    UCB2I2CSA = BMP280_ADDRESS;             // Set slave address
    UCB2CTLW0 |= UCTR | UCTXSTT;            // Start request as transmitter

    while(!(UCB2IFG & UCTXIFG));            // Wait until TXBUFF is empty
    UCB2TXBUF = reg;                        // Send first data byte

    while(UCB1CTLW0 &  UCTXSTT);            // Wait for slave's response

    while(!(UCB2IFG & UCTXIFG));            // Wait for the last byte to be loaded to shift register
    UCB2CTLW0 |= UCTXSTP;                   // Request a stop condition
    while (UCB2CTLW0 & UCTXSTP);            // Wait until stop was sent

    UCB2IFG &= ~UCTXIFG;                    // Clear TX flag

    i2cConfig(0x03);
    rxData = 0;

    receive(mBuffer,3);
    for(int i=0;i<50;i++);
    
    uint32_t temp = (mBuffer[0] << 8) | mBuffer[1];
    rxData = (temp << 8) | mBuffer[2];
}

void bmp280::transmit(uint8_t *field, uint8_t count){
    UCB2I2CSA = BMP280_ADDRESS;             // Set slave address
    txCount = count;
    txBuffer = field;
    
    UCB2CTLW0 |= UCTR | UCTXSTT;            // Start request as transmitter
}

void bmp280::receive(uint8_t *field, uint8_t count){
    UCB2I2CSA = BMP280_ADDRESS;             // Set slave address
    rxCount = count;
    rxBuffer = field;
    UCB2CTLW0 &= ~UCTR;                     // Put I2C bus in receive mode

    UCB2CTLW0 |= UCTXSTT;                   // Start request as a receiver
}

#if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)
#pragma vector=USCI_B2_VECTOR
__interrupt
#elif defined(__GNUC__)
__attribute__((interrupt(USCI_B2_VECTOR)))
#endif
void USCIB2_ISR(void)
{
    switch(__even_in_range(UCB2IV, USCI_I2C_UCBIT9IFG))
  {
        case USCI_NONE:             // No interrupts break;
            break;
        case USCI_I2C_UCALIFG:      // Arbitration lost
            break;
        case USCI_I2C_UCNACKIFG:    // NAK received (master only)
            nack_received = true;
            UCB2CTLW0 |= UCTXSTP;                 // when an acknowledge is missing the slave gets a stop condition
            UCB2IFG   &= ~UCTXIFG;
            break;
        case USCI_I2C_UCRXIFG0:             // RXIFG0
            if(rxCount){
                receive_initiated = true;
                *rxBuffer = UCB2RXBUF;      // Get RX data
                rxBuffer++;
                rxCount--;
            }
            break;
        case USCI_I2C_UCTXIFG0:     // TXIFG0
            transmit_initiated = true;
            UCB2TXBUF = *txBuffer++;
            break;
        case USCI_I2C_UCCLTOIFG:    // Clock low timeout - clock held low too long
            clock_timeout = true;
            break;
        default:
            break;
  }
}

I'll start from the top: 

1) Write: I configure the I2C bus to use interrupts and have a stop count of 2 bytes. I load a buffer with the register I'm writing to and the data, then pass that buffer to my transmit function. And yes, the empty for loop is necessary. If I take it out either nothing gets transmitted, or the transmitted data gets cut off halfway through and the clock times out. (Pictured below)

2) Trasmit: Sets the count and passes the start point of the buffer to the interrupt, which then iterates through the buffer, passing the data to UCB2TXBUF. I realize the txCount isn't used in this code (due to the auto stop) but it was handy for debugging...I took it out of this example though. 

This all makes sense right? And it works...like 50% of the time! See below:

With the empty for loop: (And sometimes I still have issues with this...it's playing nice today)

 

Without the empty for loop:

Now for reading data:

3) Read: I configure the I2C bus to use interrupts and have a stop count of 1 byte, so it should transmit 1, and receive 1. I use the same transmit function to send the register to read from, then pass my buffer to my receive function. And again, yes the empty for loops are necessary. If taken out, nothing works properly.

4) Receive: Sets the count (again, not necessary, but useful for debugging) and passes the starting point of the buffer to the interrupt, which pulls the data from UCB2RXBUF.

All nice and good, right? But again, plagued with issues. See below:

Without the for loop between transmit and receive in the read function: (Transmits the register, but does not receive the data afterward)

With the for loop between transmit and receive: (Transmits the register, but the receive doesn't show up on the scope for some reason if I'm in debug mode...no clue why...but the data is still received!!! It reads into my variable with the correct value!!!)

However, if I power cycle the board and let the code run freely (not in debug mode in CCS), I see the transmit, delay, and receive on the scope:

With the correct data: 

What is strange is this same read (I'm reading the chip ID) works perfectly with the polling method, and requires no delay whatsoever! None. Why on earth would interrupts require such a significant delay between transmitting the register to read from, and actually reading from the register? I've demonstrated this to multiple people with more experience using this hardware than me, and they don't understand it either. So TI, if you're listening...please explain.

Now, moving forward to yet another weird issue...the multi reads. This is one of the issues I mentioned above, where resetting the byte counter too often seems to lead to issues. To make this work, I *have to* use the polling method to transmit the register to read from, *then* reconfigure the I2C bus to use interrupts and the byte counter to pull in the data. This defeats the entire purpose of using the interrupts in my opinion...but I haven't been able to find any combination of settings, additional delays, or whatever, that makes it so I can use purely interrupts for a multi read...

5) Read16: I disable interrupts and manually transmit the register to read from using the polling method from above, then reconfigure the I2C bus to use interrupts with a byte counter of 2. I pass the buffer to my receive function. The empty for loop is necessary after calling receive, otherwise the buffer isn't filled properly and I lose part of the data, even though it shows it being received on the scope. 

Here is the transmit. The receive doesn't show up on the scope, but it *does* actually happen and return the correct data.

Here is the read from the same register using the polling method, no interrupts: 

These same issues happen with read24 as well.

So, in summary, I have I2C code that works, but only if I'm using a polling methodology. If I use interrupts I have to shoehorn it into working by using delays and reconfiguring the I2C bus again and again. Is there something I'm missing? I've noticed this board has an errata sheet that's about twice as long as most other TI boards...so perhaps there is something inherently wrong with this chip? 

I've tried other FR5994 Launchpads and gotten the same results. I haven't tried using another compiler yet, but if these problems remain unsolved that will happen.

Thank you in advance to anyone who reads this all the way through and offers any advice or solutions. It will be greatly appreciated. 

Compiler/MSP430FR5994: Code reset problem.

$
0
0

Part Number:MSP430FR5994

Tool/software: TI C/C++ Compiler

Hi,

I am working on MSP430FR5994 boot-loader and application image code.

I download image in application device using BootHost and it working.

Now I am try to load application(App1) and boot image at same time using uniflash.

Both code load and run success but device reset continuously. If i remove timer interrupt from App1 code then load both(App1 and boot) code then its works and never reset.

I can not understand that what is problem?

can anyone help me?

Dinkar

MSP430F5437A: About BSL password

$
0
0

Part Number:MSP430F5437A

Hello,

This is about MSP430F5437A security.

I have more questions related to https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/814820. There were answers about BSL password as follows:

- If JTAG is disabled, the only way to access the MCU memory is by providing the correct BSL password. If an incorrect BSL password is given, the FRAM memory is erased

Further questions are:

- After MCU fully erased by providing the wrong password, could the MCU be reprogrammed with new firmware and the new password?

- In the case the BSL password is leaked, the firmware in MCU could be readout and could be reprogrammed with the modified firmware, correct?

- Can BSL password be implemented as unique for each device/MCU? 

Thanks, HJ

MSP432E401Y: New design, startup issues (ongoing)

$
0
0

Part Number:MSP432E401Y

The project implements an MSP432E401Y, a 3.3V buck regulator, and POE Ethernet jack as the core.

~WAKE is tied to ground and ~HIB is left floating, per Design Guidelines (slaa770, 4.15).

This particular board has never had firmware loaded yet.

When connected to a POE-capable switch, the switch's POE Good LED lights, and the Link LED comes on; Vdd measures 3.2+ VDC.

After a short time (< a minute?), Link LED goes out, and we see Vdd has dropped below 3 VDC.

This was first observed when the debugger probe was attached, but later found to be the case, without the debugger.

Is there a weird mode, possibly drawing significantly more current than expected, that the uP may enter on start-up?

Next step will be to supply a solid 3.3V, bypassing POE, while waiting for any input from the Community.

Thank you!

Dave


MSP432P401R: Digital input pin does not trigger interrupt for PM0

$
0
0

Part Number:MSP432P401R

Hi,

I have a motion sensor attached with Digital Output of the sensor is connected to PM0 of controller.

I have configured the PM0 pin for edge triggered but my ISR is not being invoked.

Is it allowed to raise interrupt for PM0? (If I scan the input pin PM0, I see that level changes as expected but does not trigger interrupt)

My code snippet :

int myVar;


int main(void)
{
    /* Call driver init functions */
    Board_init();

    motionSensorInit();

    /* Initialize the GPIO since multiple threads are using it */
    GPIO_init();

    setupOneSecTimer();

    /* Start the TI-RTOS scheduler */
    BIOS_start();

    return (0);
}


void gpioMotionSensorInt(uint_least8_t index)
{
    myVar++;
}
void motionSensorInit()
{
    myVar = 0;

    GPIO_setConfig(GPIO_MOTION_SENSOR, GPIO_CFG_IN_PU | /*GPIO_CFG_IN_INT_RISING*/ GPIO_CFG_IN_INT_BOTH_EDGES);

    GPIO_setCallback(GPIO_MOTION_SENSOR, gpioMotionSensorInt);
    GPIO_enableInt(GPIO_MOTION_SENSOR);


}

MSP430F5359: Custom BSL package is missing the MSP430F53xx source code even though it has the images (.txt and .d43)

$
0
0

Part Number:MSP430F5359

Support,

I am looking for the MSP430F53xx BSL source code.  The package has the 'released_BSL_images' for the 5342 but not the source.

Regards,

Marc

MSP432P401V: Porting Software / Code from TM4C123 TM4C123BH6Z to MSP432P401V

$
0
0

Part Number:MSP432P401V

Hi Team SimpleLink,

Any Advice / Docs / AppNotes etc WRT Porting Software / Code from TM4C123BH6Z to MSP432P401V?

Thanks, Merril

MSP430F5342: related question for BSL source code

$
0
0

Part Number:MSP430F5342

Jace,

I asked the same question on different post then found this post and it 100% matches my question.  Sorry for the repeat.

The Custom BSL package contains the released BSL image for the MSP430F53xx famliy.  There is no way to get this source?  

If not, I do understand that I would have to port it.

CCS/MSP432P401R: Sampling for a pulse

$
0
0

Part Number: MSP432P401R

Tool/software: Code Composer Studio

Hello everyone, 

I'm currently trying to learn how to code micro controllers, more specifically, the MSP432P401R, and I've taken a DIY summer project for fun. The project involves reading a very short pulse, about 3ms with a max of around 2.5 V, and turning on an LED when it detects said pulse. The problem is that I don't know when the pulse will be generated so I want to code the MCU to continuously read from an analog source until the pulse is generated and detected. I've looked at some of the examples on the MSP432 SDK.TI Driver folder but can't find a good starting point. I'm new to coding in CCS so any references and/or tips are greatly appreciated. 

CCS/MSP430F5529: TDC7200EVM_USB, Unresolved symbol USB_disable()

$
0
0

Part Number: MSP430F5529

Tool/software: Code Composer Studio

Hi,

I'm trying to compile the example "TDC7200EVM_USB" (from "TDC720xEVM_Firmware_Source-v2.07"), using ccsv8, ti-cgt-msp430_19.6.0.STS compiler.

After a few project tweaks (wasn't finding "/libcxx/cstring" and added full support for printf) I'm seeing 5 linker errors all related to the unresolved external "USB_disable()" (declared in host_interface.c).

I've tried adding "${PROJECT_LOC}/../../Debug/obj" to linker search path, but no joy.

EDIT: So I think USB_disable() is defined in "\Debug\USB_API\USB_Common\usb.obj" - but how to link to it?

EDIT: Compiles w/out errors after adding "include usb.h" to host_interface.c, and commenting-out "extern uint8_t USB_disable(void)". Would still like to know how to make this work as original author intended. :-)

Any help is appreciated.

[Snipped] CONSOLE TEXT BELOW

undefined first referenced
symbol in file
--------- ----------------
USB_disable() ./host_interface.obj

remark #10372-D: (ULP 4.1) Detected uninitialized Port D in this project. Recommend initializing all unused ports to eliminate wasted current consumption on unused pins.
error #10234-D: unresolved symbols remain

>> Compilation failure
makefile:225: recipe for target 'TDC7200EVM_USB.out' failed
error #10010: errors encountered during linking; "TDC7200EVM_USB.out" not built
gmake: *** [TDC7200EVM_USB.out] Error 1
gmake: Target 'all' not remade because of errors.

Compiler/MSP430F47187: How to remove thoes info from compilation output file such as "Number out of range. Valid range is -32768 (-0x8000) to 65535 (0xFFFF)"

$
0
0

Part Number: MSP430F47187

Tool/software: TI C/C++ Compiler

Hi TI,

We are using IAR for MSP430 to compile and generated a static library. The sources file, which is a c code of an algorithm(i.e. actually platform independent) and just a bit large but the generated libary should be small as around 30K Bytes as it is we generated the libary for many other platforms.  However, when we use IAR for MSP430 to generate the libary, it generates a library of nealy 600K Bytes. so big !

We tried to open the generated .r43 libary with an edit tool, such as a text edit, and find that it contains a lot of below readble compilation info appended to the "real" libary as below, which is the reason why the libary is so big:

       Number out of range. Valid range is -32768 (-0x8000) to 65535 (0xFFFF).
       File: *****\******\*****\****.c, Line: 11126
       Source: CALL #?Subroutine123s*******

There are hundreds of lines of such above readable info repeated(only except the Line number are different) inside the generated .r43 libary, which cause the libary is too big. And meanwhile, it provides a possibility to hack the libary since it contains two much readable info of source !  Actually, the above compilation info has been added into the generated .r43 object file by the icc430.exe  is performed and reserved into the .r43 libary by the xar.exe.

Although it is big, but the libary has no problem if we add it into out project and could be work fine. That is, the generated file has no problem to be linked into other projects.

If we remove the readable of above info from the libary using an edit tool and left those , and the size would be reduced to 30KBytes, but the library could not be linked into our proects and the conpilation says the libary "is not a UBROF file", which means that we could not remove those above meanningless compilation info from the libary simply just with an edit tool.

So, how and what might be the compilation option, so that we could exclude those compilation info from the generated .r43 libary?

Thanks!


MSP430F5131: MSP430F5131 queries

$
0
0

Part Number: MSP430F5131

Our customer needs inputs as below-

We are looking for msp430 part number which supports BSL in I2C mode. According to the doc “SLAU319X–July 2010–Revised April 2019”

MSP430™ Flash Devices Bootloader (BSL), the msp430-G2xx3 does not support BSL-I2C which we are using currently , please confirm.

 Now, we are planning to move to new part number MSP430F5131IRSBR, which supports BSL-I2C in non-USB mode (table-1 in above doc)

 Could you explain ?

  1. What is non-usb and usb in table-1 ?
  2. Is our new chip MSP430F5131IRSBR is non-usb ?
  3. Please confirm the above-mentioned part will support BSL-I2C functionality ? 

looking forward to your input here

 

MSP430FR2533: capacitive sensing interference

CCS/MSP432P401R: TimerA Capture Mode: If i start a for loop before starting TIMER. First two capture edges are not correct.

$
0
0

Part Number: MSP432P401R

Tool/software: Code Composer Studio

I am measuring input signal frequency using timer A. I am running Timer A in Capture mode to capture rising edges of input signal. Sometimes initial captured edges are not correct. I tried debugging the error and came to the following scenario:


If I put a for loop before starting my timer first two capture edges are not correct.

For example if I give 5 KHz input signal timerAcaptureValues are:

Case 1:

Correct result
   FreqMeas_measure_freq();   //Start Timer

288 892 1496 2100 2704

Case 2: A for loop before starting timer. 

Wrong first two captures

uint32_t i;
   for (i = 160000; i > 0; i--);
  
   FreqMeas_measure_freq(); //Start Timer

1 160 764 1368 1972

First capture edge is always 1 in this case.

 Can anyone please guide me why putting  a for loop delay before starting timer resulting in wrong capture edges. Thank you.

My code is

#include "msp.h"
#include <stdint.h>

#define NUMBER_TIMER_CAPTURES 5

volatile uint32_t timerAcaptureValues[NUMBER_TIMER_CAPTURES] = {0};
uint16_t timerAcapturePointer = 0;


static void FreqMeas_init(void);
static void FreqMeas_measure_freq(void);


int main(void)
{
    WDT_A->CTL = WDT_A_CTL_PW |             // Stop watchdog timer
            WDT_A_CTL_HOLD;

    //Board.c/.h
    //Configure SMCLK = MCLK = 12MHz, ACLK = REFOCLK.
    CS->KEY = CS_KEY_VAL ;                  // Unlock CS module for register access
    CS->CTL0 = 0;                           // Reset tuning parameters
    CS->CTL0 = CS_CTL0_DCORSEL_3;           // Set DCO to 12MHz (nominal, center of 8-16MHz range)
    // Select ACLK = REFO, SMCLK = MCLK = DCO
    CS->CTL1 = CS_CTL1_SELA_2 | CS_CTL1_SELS_3 | CS_CTL1_SELM_3;
    CS->KEY = 0;                            // Lock CS module from unintended accesses


    FreqMeas_init();

   uint32_t i;
   for (i = 160000; i > 0; i--);

   //Start Timer
    FreqMeas_measure_freq();

    while(1);

}


// Timer A0 interrupt service routine
void TA0_N_IRQHandler(void)
{

    //Compare?
    if(TIMER_A0->CCTL[2] & TIMER_A_CCTLN_CCIFG)
    {
            // Clear the capture interrupt flag
             TIMER_A0->CCTL[2] &= ~TIMER_A_CCTLN_CCIFG;

             timerAcaptureValues[timerAcapturePointer++] = TIMER_A0->CCR[2];

            if (timerAcapturePointer == (NUMBER_TIMER_CAPTURES ))//Samples completed
                {
             //Stop timer
             TIMER_A0->CTL |= TIMER_A_CTL_TASSEL_2 | // Use SMCLK as clock source,
                        TIMER_A_CTL_MC_0 ;              // Stop timer
                }
     }
}




void FreqMeas_init(void)
{
    // Configure GPIO
    P2->SEL0 |= BIT5;                       // TA0.CCI2A input capture pin, second function
    P2->DIR &= ~BIT5;


    // Timer0_A3 Setup
    TIMER_A0->CCTL[2] = TIMER_A_CCTLN_CM_1 | // Capture rising edge,
            TIMER_A_CCTLN_CCIS_0 |          // Use CCI2A=ACLK,
            TIMER_A_CCTLN_CCIE |            // Enable capture interrupt
            TIMER_A_CCTLN_CAP |             // Enable capture mode,
            TIMER_A_CCTLN_SCS;              // Synchronous capture

    // Enable global interrupt
    __enable_irq();

    NVIC->ISER[0] = 1 << ((TA0_N_IRQn) & 31);


}

void FreqMeas_measure_freq(void)
{
    //Start Timer
    TIMER_A0->CTL |= TIMER_A_CTL_TASSEL_2 | // Use SMCLK as clock source,
            TIMER_A_CTL_ID__4|              // Div4 // ACLK/4 = 8192 Hz
            TIMER_A_CTL_MC_2 |              // Start timer in continuous mode
            TIMER_A_CTL_IE|                 // Enable overflow interrupt
            TIMER_A_CTL_CLR;                // clear TA0R

}

(Please visit the site to view this file)

:

CCS/MSP430F5528: MSP430F5528's SVSL_IT–/+ voltage specifications

$
0
0

Part Number: MSP430F5528

Tool/software: Code Composer Studio

Hello

In the MSP430F5528's datasheet, the voltage specifications of V(SVSL_IT–) and V(SVSL_IT+) were not found.

What is the voltage specification? Where can I find it?

Best & Regard

JingMingJun

MSP430FR2633: Captivate FR2633 Kit schematic & gerber file

$
0
0

Part Number: MSP430FR2633

Dear ...who can support for MSP430FR2633.

I will make own board with MSP430FR2633 , so I need Schematic & Gerber file of Captivate FR2633 KIT.

I could not find its file at TI site. I already bought  Captivate FR2633+Prgmer _+BSWP bundle.

if someone have Schematic and its gerber file. pls! offer me to solve the design our own board.

thank you very much . I need fast reply from you.

Best regards.

Albert Kim. my e-mail: shkim@nxtech.kr 

Viewing all 21946 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>