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.
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.
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
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
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?
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(®,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.
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
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
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
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); }
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
Part Number:MSP432P401V
Hi Team SimpleLink,
Any Advice / Docs / AppNotes etc WRT Porting Software / Code from TM4C123BH6Z to MSP432P401V?
Thanks, Merril
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.
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.
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.
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!
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 ?
looking forward to your input here
Part Number: MSP430FR2533
Dear Sir,
we are designing MSP430FR2533 Capacitive sensing function with NFC.
so far we encounter the issue of capacitive sensing interference.
touch key 0,9 and # sign will be initiated by itself. May give us some suggestion of this case? thanks.
our board is 4 layers
http://www.seawalk.com.tw/0000/touch.jpg
http://www.seawalk.com.tw/0000/gerber.png
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)
:
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
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