Last visited

Days Won

Forums

Calendar

Everything posted by Marc

When including "main.c" as follows, can I include functions from another tab into main.c?
In my example, I would like to use a function from LED.output.h before the main setup file
In main.c
#include <Energia.h>
#include "LEDoutput.h"
int main(void)
{
led_init(); // my function from LEDoutput.h
init();
setup();
while (1) {
loop();
}
return 0;
}
However I am getting the following error: main.c:(.init9+0x2): undefined reference to `led_init'.
Is my path to my custom library incorrect?
Thank you!

Hi, I am using the latest version of Energia (Energia 1.6.10E18) on a windows 7 machine. When I try to compile a basic example code, Energia tries to use libraries found in a file "..\AppData\Local\Energia15\packages\energia\hardware\msp430\1.0.2\libraries", an older library instead of the new folders that come with the new zipped file. Is there a way to change the path variable within Energia, so that it opens libraries within its own folder ie "..\energia-1.6.10E18\hardware\energia\msp430\libraries"?
Or is \AppData\Local\Energia15 the default location, and I need to manually replace the files in here?
Thank you!

Hi, I am trying to modify some of the core Energia files (main.c) so that I can initialize GPIO pins to LOW right away before Energia goes through its startup sequence. I have an LED driver connected to the MSP430FR5739 experimenter board (v1.1). The issue is, during the startup sequence (before my setup() code is running) the control pin from the experimenter board to the LED driver is active high for a few seconds thus turning the LED to full brightness. I would like to avoid using an external resistor if possible. My question is:
1. Is there a better way to initialize GPIO pins in Energia before the startup sequence?
2. I tried modifying main.cpp (under xxx\energia-1.6.10E18\hardware\energia\msp430\cores\msp430), but the changes didn't seem to reflect when I compiled my code with Energia. I even tried putting erroneous statements intentionally to see if this cause the compilation to fail, but it didn't do anything. Is this the correct file? Or does this version of Energia not allow modifications to core files?
Thank you!
Hardware: MSP430FR5739 Experimenter board v1.1
Energia Version: 1.6.10E18
OS: WIndows 7

Has anyone experienced issues with the msp430FR5739 experimenter board with the latest energia v 18? I can't seem to program it using the latest version on my windows 10, 7 or mac.
I get the following error message:
usbutil: unable to find a device matching 0451:f432
An error occurred while uploading the sketch
Thanks!

I think I have found the issue:
In the energia opt3001.cpp code (line 77) the implementation for the register read readRegister(uint8_t registerName) declared the lsb, msb and result variables as int8_t.
(line 79, OPT3001.cpp)
int8_t lsb;
int8_t msb;
int16_t result;
I changed this to unsigned, as they are supposed to be:
uint8_t lsb;
uint8_t msb;
uint16_t result;
The code now works. Thank you for sharing your library @@Rei Vilo, I was able to realize this by doing a side by side comparison with your code. I hope this will prevent any issues you may have with your project @@NurseBob!

I know how you feel @@NurseBob, wow nursing instructor at day, developer at night?
Thanks @@Rei Vilo, I downloaded the SensorsWeather_Library and hooked up my sensor to the CC3200 launchpad. It works without glitches now!
There is still a NAK at the end of the wire transmission, but the CC3200 seems to have no problem getting the correct value.
I am more convinced that it is some timing issue with the energia wire implementation.

Thanks for sharing @BobNurse, it's interesting that it's a NAK instead of an ACK. I wonder if this has to do something with Energia's wire implementation?
It's interesting that the USB messages also reflect 'missed' data reports. To see if the USB reporting had anything to interfere with the i2c, I tried an experiment where instead of reporting the received data on the USB after each i2c read, I had it so that the msp would log 10 data points, and then spit out the 10 readings via USB once the 10 i2c readings were completed. The results however still indicated that the data still was corrupted during the i2c reads (that technically had no USB interference). It really is an odd issue.

Thanks Bob, I really appreciate the help! I took a look at the OPT3001EVM module:
It looks like it's reading the configuration bit, waits 13ms, reads the value, then waits another 45ms for the next cycle. There is no signal on the interrupt bit. Here are the captured waveforms.
Instead of my sensor I mounted 2k resistors on the OPT3001EVM daughter board SCL, SDA and INT pins, then connected it directly to the msp430 as you suggested - oddly I am seeing that the configuration bit and the value are correctly captured in the logic probe, but when doing a Serial.print to the captured values on the UART it seems that the first byte for both the configuration bit and the value is read as 0xFF.
So although the sensor is properly sending out a proper configuration register value and raw value (0xC490 and 0x1EDB), the msp430 somehow misses the first byte (0xFF90 and 0xFFDB).
I tried it on the TivaC as well, and see the same results.

Thanks @@Rei Vilo, I am currently using the Energia OPT3001 library, and experiencing the same issues with the example code. I did purchase an educational boosterPack MK-II to make sure it's not a hardware issue, but so far the issue seems to be consistent on both the Wolverine and Tiva C launchpads with the energia library.

Thanks for the insight @@NurseBob! Yes, I do recall reading about the transient response, and have done a side by side comparison with the OPT3001EVM evaluation kit. I have tried experiments where I swing a light across the sensor rapidly across both the evaluation module and my msp430 board. The msp430 board returns a corrupted value, while the evaluation module responds with no problems.
I have tried checking the "Conversion Ready" field before making a read, but I still get corrupted values read on the msp430.
Also, I have checked the sensor signal coming from a logic probe, and the values do seem to come out as un-corrupted values during rapid transitions. It's odd that they don't on the msp430.

I tried various resistors (ranging from 1k-5k) but still no luck...under a scope it looks like the data is being sent correctly from the sensor, it just doesn't reflect the value read within the msp430 processor.

Hi, does anyone have experience with the OPT3001 sensor using custom hardware or interfacing to the msp430 launchpad? I have a sensor on the TI opt3001EVM daughter board, with the SDA pins and SCL pins connected to vdd via 10k resistor, for a msp430fr5969 wolverine launchpad - I am able to read the data from the sensor, but every time I rapidly change a test light source (flash a light on the sensor, or put my hand to cover it), I get a corrupted reading (it reads FFxx). I currently have it set to poll at 100ms, and at autoscale with no mask. The autoscale does work, it's just during transition periods the first byte is read 0xFF.
The sensor works fine using the TI OPT3001EVM module.
Thanks for any insight or help!
The configuration register is set to the following value - 0b1100010000010000 - Automatic full scale setting mode
- 100ms conversion time
- Continuous conversion mode
- Mask field disabled
- latched mode enabled

Thanks! If you look on page 6 of that user guide:
P2.1/TB0.0/UCA0RXD/UCA0SOMI/TB0.0
P2.0/TB0.6/UCA0TXD/UCA0SIMO/TB0CLK/ACLK
These don't match the description in: http://energia.nu/wordpress/wp-content/uploads/2014/06/MSP430FR5969.jpeg
Also if you compare that with pins P2.5 and P2.6 TXD(1) and RXD(1) the two are consistent, so it's not a convention issue.
I can verify this when my new launchpad arrives, but it would be great to find out before then. I appreciate any available help!

Hi, are the RXD and TXD pins P2.0 and P2.1 respectively correct as shown in the Energia diagram? This is different from TI's datasheet - http://www.ti.com/lit/ds/symlink/msp430fr5969.pdf
I think the one on Energia is correct, can anyone confirm?