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.

  • TI Thinks Resolved

MSP430 Launchpad

hello,

 

I am new to launch pad... when i got the kit i tried that inbuilt code, the leds glow as required but nothing on the screen of hyper terminal except a list of "??????".

 

Now, when i am finished trying some other codes for leds and switches, they worked well but when i tried to debug that demo code using IAR, it gives an error while linking........

The error is as mentioned:-

Building configuration: lp - Debug 

Updating build tree... 

main.c  

Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement C:\Documents and Settings\x0137852\Desktop\launchpad\main.c 232 

Linking 

Error[e104]: Failed to fit all segments into specified ranges. Problem discovered in segment CODE. Unable to place 22 block(s) (0x4b6 byte(s) total) in  

0x3c8 byte(s) of memory. The problem occurred while processing the segment placement command "-P(CODE)CODE=FC00-FFDF", where at the  

moment of placement the available memory ranges were "CODE:fc18-ffdf" 

Error while running Linker 

 

Total number of errors: 1 

Total number of warnings: 1 

Kindly suggest me some solution to this.
kindly also help me for the fact why nothing displays on hyperterminal.............?
waiting for reply
Thanking you

  • The Compiler Warning[Pa082] is just silly. Ignore it.

    The Linker Error[e104] is caused by the size of the code the Compiler generated was to big for the chip you specified in the IAR Project. It looks like you specified a chip with only 1KB of Main Flash while the compiled code needs over 1 KB. Try a chip with at least 2 KB of Main Flash.

    The demo program is flaky. And PC interface hardware may have problem too. I do not have any LaunchPad (yet).

  • qwert,

    could you make sure that you have the correct device (G2231) selected? The error indicates that the selected device only has ~0x3C8 or ~1000 bytes of flash, from 0xFC00-0xFFFF. The G2231 has 2KB of flash, which would be sufficient for the firmware.

     

    The default demo application sends the temperature reading in Fahrenheit to the UART. Depending on the device, the room temperature reading could vary in the 60-80 degree range. This, translated to ASCII values, should appear as some kind of alphabet character in HyperTerminal. I would recommend trying the GUI to display the data, or using a more flexible terminal software such as HTerm to display values in Hex/Decimal.

    Regards,

    Dung

     

  • qwert
    Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement C:\Documents and Settings\x0137852\Desktop\launchpad\main.c 232 

    Would you mind posting the source line in question too?
    If not, all I can say is that this error means that the order of volatile accesses is undefined in this statement.

    qwert
    Failed to fit all segments into specified ranges. Problem discovered in segment CODE. Unable to place 22 block(s) (0x4b6 byte(s) total) in  0x3c8 byte(s) of memory.

    Let me make an educated guess: the compiler is unable to squeeze 1206 bytes of code into the available 968 bytes of flash memory? I believe, the compiler is right. I'd have problems too.
    In other words: your code is too large for the 1kb (minus variable initializers and interrupt vector table) flash the processor has.

    qwert
    Kindly suggest me some solution to this.

    Try reducing the code size or buy a larger processor.

    qwert
    kindly also help me for the fact why nothing displays on hyperterminal.............?


    Let me look into my crystal orb... Well, I don't see anything, so what about this answer:
    'the computer is off'
    Doesn't fit? Wait, I'll ask my Tarot cards. Let's see... 'the fool'. Well, this could mean
    'HyperTerm isn't running"
    Still no go? Hmm, well, my dices tell me to try this answer:
    "the driver for the virtual COM port isn't installed"

    Enough guessing wihtout any information. If it still doesn't work, you have two choices: seach the forum for already given answers (there are SEVERAL threads about LaunchPad and HyperTerm in this forum) or provide some detailed information.

    _____________________________________

    Time to say goodbye - I don't have the time anymore to read and answer forum posts. See my bio for details.

    Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.
    I'm sorry that  I can no longer provide help  in the forum or by private conversation.

  • In reply to Jens-Michael Gross:

    Jens-Michael,

    You overlooked the last part of the original posting. It says: nothing displays on hyperterminal....except a list of "??????"

    It is quite possible that the temperature was 63 degrees F.

    --OCY

  • In reply to old_cow_yellow:

    You got it OCY.

    Rubbing the chip with your finger will change the reading.

  • In reply to eltury:

    eltury,

     

    rubbing the chip doesn't show any change of values except that it only indicates a change in the led's glowing as according to the coding and the GUI that is available on net is not working here on my PC.

     

  • In reply to Dung Dang:

     

    thank you Dung and everyone for their help.....

     

    It worked and even i could find the ASCII values on the hyper terminal that show the temp to vary between 60 t0 83 degree fahrenheit. But GUI doesn't work, when i try to run the "EXE" file dialog box appears saying could not find the main class and the setup exits.

     

    Anyhow, i have got the values in ASCII so not a big problem....

     

    Now, everyone..... Kindly suggest me some more projects so as to make me play with this small launch pad..... i have done all the led blinking using interrupt, timer , switches...... all that stuff......

     

    kindly suggest me something more good and difficult to play with...

     

    thank you all once again....

  • In reply to qwert:

    Hi qwert,

    if your looking for 'something more good and difficult to play with' I suggest to have a look at the girls next door! That's more fun than playing around with MCUs *lol*.

    Have a look at TIs application notes (http://focus.ti.com/mcu/docs/mcuprodtechdoc.tsp?sectionId=95&tabId=1202&familyId=342&techDoc=1&docCategoryId=1&viewType=mostrecent) if you don't have own ideas what to do with an MCU. Maybe this will point you into the right direction.

    Rgds
    aBUGSworstnightmare

  • In reply to aBUGSworstnightmare:

    hey aBUGSworstnightmare,

     

    i already had a look at your so called suggestion. Anyhow, thanks for the information.

     

    I am planning to work on a MORSE CODE decoder using this launchpad. Do you have any ideas or suggestions so as to guide me in the RIGHT direction?

  • In reply to qwert:

    Morse decoding is easy in a way, and hard in a way. The easy part is that there are no particularly complex algorithms involved, and you only need minimal microcontroller resources -- chiefly the adc converter. The hard part is that the signal has very few definite parameters of modulation or form, so your implementation must be very generic such that it will be insensitive to all the variables and unknowns about the modulation. The baseband and broadband frequencies are unknown. The frequencies are prone to drifting. There may be lots of noise of various sorts. The received signal amplitude is prone to fading / fluctuation. The timing of the modulation is unknown and could vary over more than a 10:1 range. The most helpful advice I can give is as follows: A: Get the MSP430 to sequentially sample a signal on the desired analog input pin at some reasonable rate such as 11kHz or 22kHz. This will be the input signal you need to analyze. B: Make some kind of input coupling circuit so that your input audio or other signal can be coupled to the MSP430 ADC converter input so that you get the right level of gain/loss, low pass filtering before the ADC, et. al. C: Implement the actual morse decoder algorithm in C on a PC using initial data inputs that are either recorded samples from the PC's sound card or which are simulated data sets (write a program to output samples of morse code with a test message given some particular modulation speed and baseband frequency). Generate the audio samples at a sampling rate similar to what you expect to use on the MSP430. Once you have the prerecorded / pre-generated test messages decoding properly using the C code on the PC, make or acquire some new samples to test with -- ones which have different frequencies, different amplitudes, more noise, more frequency/timing variation et. al. Get those to decode, and then you just port the code to the MSP430 which will be easy enough if you've written the code such that it is easily ported which should not be hard since it must only access RAM buffer arrays, variables, and some reference tables about the morse alphabet itself. Use only 'unsigned short' or 'unsigned char' fixed point types which are 8 or 16 bits in the code / data, and keep in mind you'll only have a hundred or so bytes of RAM for all variables and signal storage. The first thing you'll need is basically an energy detector which is like a VU meter, feed it any signal of any frequency or waveform and it will calculate the average energy of that signal over some short period of time such as 5ms or so. This can be done by just calculating the RMS or root mean square of the series of samples such as PowerAccumulator += (Sample - 32767)^2 assuming your samples are originally unsigned 0...65536 range numbers. If they're already signed 16 bit quantities, don't subtract 32767. Anyway do that in a loop over the right number of samples, say, 20 at a time to generate your average. Since your power accumulator variable is possibly only 16 bits, you may need to prevent overflow of its range somehow such as: PowerAccumulator += (Sample >> 8) * (Sample >> 8) or whatever which divides the input samples before their squaring/summing by dropping the least significant 8 bits and shifting the rest of the bits downward so 0x7f00 would become 0x007f though the problem with that is that extremely quiet signals which only have the least significant few bits active may be ignored. So then you have a power variable that measures the loudness (well power anyway) of the signal over a short time with no respect for the actual frequency or waveform. You could skip the square root in the RMS since your squared variable is still a fine representation of the power. Then you will need some kind of threshold power to say that power levels greater than X volume/signal power are considered "audio present" and anything quieter is "audio absent" . The most basic way is to hard code the number which is the threshold of "quiet" versus "audio" but you could make the threshold adaptive over a period of time such as 1/10th second or 1 second or 10 seconds or whatever so that you're better able to adapt to quiet or loud signals automatically. You could also use this adaptive signal level value over some long time to scale the incoming ADC samples themselves so that you have less overflow or undersensitivity problems during the above signal power measurement process. That loop of averaging the signal power over a modestly long while and adjusting the gain of the receiver and the noise 'squelch' level would be basically an AGC or variable squelch type of operation. Anyway eventually you'll end up with a set of averages like so where 'A' is "AUDIO detected at a volume more than the threshold" and 'Q' is "Quiet below the threshold": QQQQQQQQAAAAAAQQQQQQAAAAAAQQQQQQAAAAAAQQQQQQAAAQQQQQQAAAQQQQQQAAAQQQQQQAAAAAAQQQQQQAAAAAAQQQQQQAAAAAAQQQQQQQQQ and if you look at the "ON", "OFF" periods over that set of data you'll eventually see you have a message of a series of morse coded letters. To decode that of course you'll want to have a loop that looks at the timing of the shortest bursts of audio (above that would be three unit intevals as in 'AAA'), and dynamically sets that value as your 'dot' threshold timing. Also look for the longest bursts of audio, much longer than the 'dot' duration, and set that interval as the 'dash' time you're looking for. Make the timing re-adjust every few seconds to adapt to variable rates. So then you scan the power detector's output for sequences of "DOT" long audio or sequences of "DASH" length audio and you can then generate a "." or "-" output once you've decided which length the most recent audio burst corresponded to, short or long. Now you have a sequence of dot and dash sequences output from this stage of processing, and you can just compare them to the alphabet tables to see at what point you have decoded a whole letter. When deciding where a letter starts and stops of course you should look for extra long quiet time preceding the first letter in a series and look for the maximum possible length letter you could make from a sequence of input so that you don't assume too early the end of a letter and the start of the next one. The limited RAM will cause you to not keep too long of a history of past data streams of history of quiet versus not quiet, but that is OK since if you have the power averaging timing windows set to a reasonable length, only a few dozen outputs of that data would correspond to even the longest letter, and you could really discard the data as soon as you've determined whether a given audio burst is a dot or a dash so you wouldn't even need more than a few samples to discriminate the dot vs dash timing.

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.