I am looking for an MSP430 programmer who has some expertise in serial ports
programming.

Please add me in your connection at ezdia ( search for Vikas Shukla) and I will
start giving you instructions.

See http://tech.groups.yahoo.com/group/msp430/message/42414

--- In msp430@yahoogroups.com, "for_si2003" <for_si2003@...> wrote:
>
> I am looking for an MSP430 programmer who has some expertise in serial ports
programming.
>
> Please add me in your connection at ezdia ( search for Vikas Shukla) and I
will start giving you instructions.
>

Hi,

Before running the experiment, I checked the archives and didn't seen any
relevant postings for "JTAG distance". I'm working on a rapid prototype and plan
to put an MSP430 in the engine compartment and extend the JTAG ~10 ft (~3 m.)
back to the cabin and the eZ430 USB fob. Any best guesses on distance
limitations using Cat-5 cable and RJ-45 blocks?

The reason is testing revealed the MSP430 daughter has survived 100C but the USB
eZ430 failed. Hence the reason why I'd like to extend the JTAG into the cabin.
The USB interface might not survive engine compartment temperatures.

Yes, I'll share my results but thought I'd ask first if anyone had tried this
approach to extending JTAG using Cat-5 cable. Checking the Cat-5 specifications:

4 MHz, 13dB/1,000 ft
28.6 ohm/1000 ft
14 pF/ft
100 ohm impedance

Back of the envelope for 10 ft. (~3 m) Cat-5 suggests:

.13 dB attenuation, 4 MHz
.572 ohms, round-trip
280 pF capacitance, round trip

Thanks,
Bob Wilson

nOT TRIED cat-5. The older parallel programmers were a nightmare with
the ribbon cable connection to the JTAG box. anywhere near an older LCD
display and they'd garbage themselves. however I have shoved the USB
dongle at the end of 4 USB connectors linked together (don't ask!! I was
laid up in bed and that was as close as I could get to the work bench!)
and that was fine. Conversely, similar situation, I've debugged with the
dongle directly into a laptop and the test piece on the end of about 8
feet of shielded 4 core cable. Similar deal, I was in bed and needed to
get the device outside to debug it. Not a car though. Obviously the
usual advice would apply, protect against automotive size spikes, and if
powering from the car then automotive size load dumps. these thing do go
OK in cars generally. A lot would perhaps depend on how you route it.
obvious stuff, avoid the ignition leads and injector drivers if you can.

One thing I have found is that the little 4 way connectors on the EZ430
dongles are not the best, in fact they're pretty shitty, and even a
slight movement if they are stressed at all can fracture them. I have a
   collection of dead ones. Luckily they are cheap. It's worth a try anyway.

Al

Robert J. Wilson wrote:
> Hi,
>
> Before running the experiment, I checked the archives and didn't seen any
relevant postings for "JTAG distance". I'm working on a rapid prototype and plan
to put an MSP430 in the engine compartment and extend the JTAG ~10 ft (~3 m.)
back to the cabin and the eZ430 USB fob. Any best guesses on distance
limitations using Cat-5 cable and RJ-45 blocks?
>
> The reason is testing revealed the MSP430 daughter has survived 100C but the
USB eZ430 failed. Hence the reason why I'd like to extend the JTAG into the
cabin. The USB interface might not survive engine compartment temperatures.
>
> Yes, I'll share my results but thought I'd ask first if anyone had tried this
approach to extending JTAG using Cat-5 cable. Checking the Cat-5 specifications:
>
> 4 MHz, 13dB/1,000 ft
> 28.6 ohm/1000 ft
> 14 pF/ft
> 100 ohm impedance
>
> Back of the envelope for 10 ft. (~3 m) Cat-5 suggests:
>
> .13 dB attenuation, 4 MHz
> .572 ohms, round-trip
> 280 pF capacitance, round trip
>
> Thanks,
> Bob Wilson
>
>
>
> ------------------------------------
>
> To unsubscribe from the msp430 group, send an email to:
> msp430-unsubscribe@egroups.com
>
> Yahoo! Groups Links
>
>
>
>

--- In msp430@yahoogroups.com, OneStone <onestone@...> wrote:
>
. . .
> Not a car though. Obviously the
> usual advice would apply, protect against automotive size spikes, and if
> powering from the car then automotive size load dumps. these thing do go
> OK in cars generally. A lot would perhaps depend on how you route it.
> obvious stuff, avoid the ignition leads and injector drivers if you can.

Thanks, I'm trying to be careful but being able to use the JTAG as my interface
device simplifies the task. It really comes down to how much cable load the JTAG
interface can take and whether or not the CAT-5 twist is enough for these short
distances. <grins>

Bob Wilson

Thanks guys,

I think you have placed me on the right track.  I have determined there is a
slight chance that Vcc could drop during an INFO memory write (battery
operated device).  It was just curious as to why this would wipe the reset
vector given info memory is in a completely separate location/block.  Your
idea of the write continuing along the reset vector is interesting.  At the
core I think the lesson is that if power drops during a flash write the
results are unpredictable!

Jon



Onestone-2 wrote:
>
> This would suggest that in the middle of a flash write the power has
> fallen below threshhold, a POR has been generated, but somehow the flash
> write has continued using the reset fetch vector. I've never seen this,
> just thinking out loud. I never attempt to save on power down for this
> reason. If the data is urgent save it while power is secure. There are
> plenty of ways around this.
>
> Al
>
> jpottaway wrote:
>> Hi all.
>>
>> I have a MSP430 project which has been on commercial production for a few
>> years.  However in the most recent batch we have been getting a number of
>> devices returned with apparent corruption.  Reprogramming fixes the
>> issue.
>>
>> On investigation of the corrupted devices it seems that the reset vector
>> (FFFEh) has been corrupted and is 0000h instead of the 0080h it was
>> originally programmed as.  I am at a loss to explain it.  The only flash
>> writing the firmware does is to the INFO areas when power is removed to
>> preserve settings.
>>
>> Anyone seem something like this before?
>>
>> Thanks in advance,
>> Jon
>
>

--
View this message in context:
http://www.nabble.com/Interrupt-Vector-Table-Corruption-tp24750598p24783595.html
Sent from the MSP430 - Discuss mailing list archive at Nabble.com.

Depenidng upon the amount of data you need to store I use a cyclic
store. using this method I have a device which stores time every minute.
they have been in use for over 10 years without a single report of flash
corruption or exhaustion. You will need a routine to detect the next
free address in your buffer, but that's quite easy.

Cheers

Al

jpottaway wrote:
> Thanks guys,
>
> I think you have placed me on the right track.  I have determined there is a
> slight chance that Vcc could drop during an INFO memory write (battery
> operated device).  It was just curious as to why this would wipe the reset
> vector given info memory is in a completely separate location/block.  Your
> idea of the write continuing along the reset vector is interesting.  At the
> core I think the lesson is that if power drops during a flash write the
> results are unpredictable!
>
> Jon
>
>
>
> Onestone-2 wrote:
>> This would suggest that in the middle of a flash write the power has
>> fallen below threshhold, a POR has been generated, but somehow the flash
>> write has continued using the reset fetch vector. I've never seen this,
>> just thinking out loud. I never attempt to save on power down for this
>> reason. If the data is urgent save it while power is secure. There are
>> plenty of ways around this.
>>
>> Al
>>
>> jpottaway wrote:
>>> Hi all.
>>>
>>> I have a MSP430 project which has been on commercial production for a few
>>> years.  However in the most recent batch we have been getting a number of
>>> devices returned with apparent corruption.  Reprogramming fixes the
>>> issue.
>>>
>>> On investigation of the corrupted devices it seems that the reset vector
>>> (FFFEh) has been corrupted and is 0000h instead of the 0080h it was
>>> originally programmed as.  I am at a loss to explain it.  The only flash
>>> writing the firmware does is to the INFO areas when power is removed to
>>> preserve settings.
>>>
>>> Anyone seem something like this before?
>>>
>>> Thanks in advance,
>>> Jon
>>
>

Thanks so much for you assistance.

The problem has gotten even more bizarre.  I have determined that sudden
drops in voltage and/or repeated brownouts cause the flash corruption.  I
have a simple function that saves user settings to flash when requested -
this function never executes on startup and requires significant user
interaction to actually run.  However, when this function is compiled into
the code and the voltage is randomly moved about corruption eventually
results but if it is commented out is does not?

Can the PC jump to random locations after loss of voltage or a brownout?
There simply is no execution path that could possibly get to the flash write
function during startup/voltage fail when there has been no other
interaction with the device?

Very confused.

Jon


Onestone-2 wrote:
>
> Depenidng upon the amount of data you need to store I use a cyclic
> store. using this method I have a device which stores time every minute.
> they have been in use for over 10 years without a single report of flash
> corruption or exhaustion. You will need a routine to detect the next
> free address in your buffer, but that's quite easy.
>
> Cheers
>
> Al
>
> jpottaway wrote:
>> Thanks guys,
>>
>> I think you have placed me on the right track.  I have determined there
>> is a
>> slight chance that Vcc could drop during an INFO memory write (battery
>> operated device).  It was just curious as to why this would wipe the
>> reset
>> vector given info memory is in a completely separate location/block.
>> Your
>> idea of the write continuing along the reset vector is interesting.  At
>> the
>> core I think the lesson is that if power drops during a flash write the
>> results are unpredictable!
>>
>> Jon
>>
>>
>>
>> Onestone-2 wrote:
>>> This would suggest that in the middle of a flash write the power has
>>> fallen below threshhold, a POR has been generated, but somehow the flash
>>> write has continued using the reset fetch vector. I've never seen this,
>>> just thinking out loud. I never attempt to save on power down for this
>>> reason. If the data is urgent save it while power is secure. There are
>>> plenty of ways around this.
>>>
>>> Al
>>>
>>> jpottaway wrote:
>>>> Hi all.
>>>>
>>>> I have a MSP430 project which has been on commercial production for a
>>>> few
>>>> years.  However in the most recent batch we have been getting a number
>>>> of
>>>> devices returned with apparent corruption.  Reprogramming fixes the
>>>> issue.
>>>>
>>>> On investigation of the corrupted devices it seems that the reset
>>>> vector
>>>> (FFFEh) has been corrupted and is 0000h instead of the 0080h it was
>>>> originally programmed as.  I am at a loss to explain it.  The only
>>>> flash
>>>> writing the firmware does is to the INFO areas when power is removed to
>>>> preserve settings.
>>>>
>>>> Anyone seem something like this before?
>>>>
>>>> Thanks in advance,
>>>> Jon
>>>
>>
>
>

--
View this message in context:
http://www.nabble.com/Interrupt-Vector-Table-Corruption-tp24750598p24785431.html
Sent from the MSP430 - Discuss mailing list archive at Nabble.com.

My experience with trying to use CTA5 on SPI might be relevant here. Basically I
wanted to remote a SPI device some 2 meters from the MSP board. I got my RJ45
connection and CAT5 cable and all looked great. Only thing it didn't work. Long
story short, because of the twisted pairs in the CAT5, the signals were
disturbing one another and giving noise of canceling each other out. I had to
resort to flat cable (or non-twisted 8 core cable). Hope this helps.



--- In msp430@yahoogroups.com, "Robert J. Wilson" <bwilson4web@...> wrote:
>
> Hi,
>
> Before running the experiment, I checked the archives and didn't seen any
relevant postings for "JTAG distance". I'm working on a rapid prototype and plan
to put an MSP430 in the engine compartment and extend the JTAG ~10 ft (~3 m.)
back to the cabin and the eZ430 USB fob. Any best guesses on distance
limitations using Cat-5 cable and RJ-45 blocks?
>
> The reason is testing revealed the MSP430 daughter has survived 100C but the
USB eZ430 failed. Hence the reason why I'd like to extend the JTAG into the
cabin. The USB interface might not survive engine compartment temperatures.
>
> Yes, I'll share my results but thought I'd ask first if anyone had tried this
approach to extending JTAG using Cat-5 cable. Checking the Cat-5 specifications:
>
> 4 MHz, 13dB/1,000 ft
> 28.6 ohm/1000 ft
> 14 pF/ft
> 100 ohm impedance
>
> Back of the envelope for 10 ft. (~3 m) Cat-5 suggests:
>
> .13 dB attenuation, 4 MHz
> .572 ohms, round-trip
> 280 pF capacitance, round trip
>
> Thanks,
> Bob Wilson
>

Hi all,

We're just having a few problems with the new MSP430F4132/MSP430F4152 micros and
were wondering if anyone here has used the these yet or could shed some light.
Is there anything special about the way we need to use these?

We've just received a couple of samples and we're unable to program them (via
IAR). We tried both the standard JTAG and spy-bi-wire interfaces and neither
seem to want to program. We have had to modify an old 64pin target board to suit
this new setup but we keep getting the usual "failed to identify device error
message". (Apparantly the new target board isn't available for a while)

This is the first time we have used an MSP that has JTAG multiplexed with a
standard IO port. Is there any setting or something that has to be changed
before programming or do you just connect JTAG to the device and click debug
like usual?

There is nothing in the errata about this either.

Thanks in advance

Hani

The TEST pin must be brought out and some devices require the rst pin as well..
I always bring out the RST pin as standard practice..
 
 


--- On Mon, 8/3/09, hchahine@... <hchahine@...> wrote:


From: hchahine@... <hchahine@...>
Subject: [msp430] New MSP430F41x2 programming issues
To: msp430@yahoogroups.com
Date: Monday, August 3, 2009, 2:26 AM


 



Hi all,

We're just having a few problems with the new MSP430F4132/ MSP430F4152 micros
and were wondering if anyone here has used the these yet or could shed some
light. Is there anything special about the way we need to use these?

We've just received a couple of samples and we're unable to program them (via
IAR). We tried both the standard JTAG and spy-bi-wire interfaces and neither
seem to want to program. We have had to modify an old 64pin target board to suit
this new setup but we keep getting the usual "failed to identify device error
message". (Apparantly the new target board isn't available for a while)

This is the first time we have used an MSP that has JTAG multiplexed with a
standard IO port. Is there any setting or something that has to be changed
before programming or do you just connect JTAG to the device and click debug
like usual?

There is nothing in the errata about this either.

Thanks in advance

Hani















[Non-text portions of this message have been removed]

you should have a brownout detect that will reset the device, short voltage
drops have unpredictable results.. it all depends on what instruction is being
executed when the glitch occurs.. if your PS is that unstable you need to
protect against it..
 


--- On Mon, 8/3/09, jpottaway <jpottaway@...> wrote:


From: jpottaway <jpottaway@...>
Subject: Re: [msp430] Interrupt Vector Table Corruption
To: msp430@yahoogroups.com
Date: Monday, August 3, 2009, 1:14 AM


 




Thanks so much for you assistance.

The problem has gotten even more bizarre. I have determined that sudden
drops in voltage and/or repeated brownouts cause the flash corruption. I
have a simple function that saves user settings to flash when requested -
this function never executes on startup and requires significant user
interaction to actually run. However, when this function is compiled into
the code and the voltage is randomly moved about corruption eventually
results but if it is commented out is does not?

Can the PC jump to random locations after loss of voltage or a brownout?
There simply is no execution path that could possibly get to the flash write
function during startup/voltage fail when there has been no other
interaction with the device?

Very confused.

Jon

Onestone-2 wrote:
>
> Depenidng upon the amount of data you need to store I use a cyclic
> store. using this method I have a device which stores time every minute.
> they have been in use for over 10 years without a single report of flash
> corruption or exhaustion. You will need a routine to detect the next
> free address in your buffer, but that's quite easy.
>
> Cheers
>
> Al
>
> jpottaway wrote:
>> Thanks guys,
>>
>> I think you have placed me on the right track. I have determined there
>> is a
>> slight chance that Vcc could drop during an INFO memory write (battery
>> operated device). It was just curious as to why this would wipe the
>> reset
>> vector given info memory is in a completely separate location/block.
>> Your
>> idea of the write continuing along the reset vector is interesting. At
>> the
>> core I think the lesson is that if power drops during a flash write the
>> results are unpredictable!
>>
>> Jon
>>
>>
>>
>> Onestone-2 wrote:
>>> This would suggest that in the middle of a flash write the power has
>>> fallen below threshhold, a POR has been generated, but somehow the flash
>>> write has continued using the reset fetch vector. I've never seen this,
>>> just thinking out loud. I never attempt to save on power down for this
>>> reason. If the data is urgent save it while power is secure. There are
>>> plenty of ways around this.
>>>
>>> Al
>>>
>>> jpottaway wrote:
>>>> Hi all.
>>>>
>>>> I have a MSP430 project which has been on commercial production for a
>>>> few
>>>> years. However in the most recent batch we have been getting a number
>>>> of
>>>> devices returned with apparent corruption. Reprogramming fixes the
>>>> issue.
>>>>
>>>> On investigation of the corrupted devices it seems that the reset
>>>> vector
>>>> (FFFEh) has been corrupted and is 0000h instead of the 0080h it was
>>>> originally programmed as. I am at a loss to explain it. The only
>>>> flash
>>>> writing the firmware does is to the INFO areas when power is removed to
>>>> preserve settings.
>>>>
>>>> Anyone seem something like this before?
>>>>
>>>> Thanks in advance,
>>>> Jon
>>>
>>
>
>

--
View this message in context: http://www.nabble. com/Interrupt- Vector-Table-
Corruption- tp24750598p24785 431.html
Sent from the MSP430 - Discuss mailing list archive at Nabble.com.
















[Non-text portions of this message have been removed]

franciscocantero1 wrote:
> I'm experiencing some problems with printf(), sprintf().
> It seems that
> va_start(ap,format);
> where va_list ap
> char* format
> Is not populating the ap with a valid address, it keeps the same address
> that had before running that line.
> while debugging if i set the ap varaiable to the address that i want it
> prints ok. but at runtime it doesnt print the string, it prints whatever
> contains that va_list.
>
> I dont know why is doing this, I use IAR 3.42 and the code works properly.
> Any help will be welcome.

Hi!

I could take a look at it, but I would need a small but complete example
that demonstrates the problem.

Also, I would need to know if you are using DLib or the legacy CLib library.

      -- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

I would like to set low power mode such that it would reset the USCI
register of uC- MSP430F2350. & Again enable it immediately.



Which LPM mode is recommended to use it for above requirement?



Or shall I look for software reset. I am not sure which method to use.







[Non-text portions of this message have been removed]

Nick Loy wrote:
> My experience is mid grade optimization usually works fine, maximum
> optimization almost never works. Be absolutely sure all dynamic
> variables are declared as such.

Hi Nick!

It's always great to get feedback on your products. However, it would be
even greater if you could be a bit more specific than "maximum
optimization almost never works". Do you have concrete cases when the
compiler doesn't generate correct code? If you do, I would be happy to
take a look at them.

      -- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

I would like to set low power mode such that it would reset the USCI
register of uC- MSP430F2350. & Again enable it immediately.

Which LPM mode is recommended to use it for above requirement?

Or shall I look for software reset. I am not sure which method to use.



--
View this message in context:
http://www.nabble.com/Low-power-mode-in-MSP430F2350-tp24787453p24787453.html
Sent from the MSP430 - Discuss mailing list archive at Nabble.com.

What do you mean by sudden drops in voltage, how sudden? I wouldn't
expect any system to be totally stable in an environment where its power
supply was allowed to be noisy, and nothing was done to mitigate this.
Your probably crapping all over the registers, since they are RAM based,
including the stack pointer and program counter, so if you do it enough
at some point they may very well point you into the flash routine, or a
nearby dead region of code that causes you to end up there.  Especially
if you have no BOR or SVS responses defined, or these are inadequate. To
test this try writing an endless loop immediately before the start of
the flash write routine, this will make it harder to accidentally drop
in there. If you're writing in C you may have to force this somehow.

otherwise your previous post mentioned that you saved on power loss,
whereas here you suggest that the flash write is a user activated
function, is this two separate actions?

Al

jpottaway wrote:
> Thanks so much for you assistance.
>
> The problem has gotten even more bizarre.  I have determined that sudden
> drops in voltage and/or repeated brownouts cause the flash corruption.  I
> have a simple function that saves user settings to flash when requested -
> this function never executes on startup and requires significant user
> interaction to actually run.  However, when this function is compiled into
> the code and the voltage is randomly moved about corruption eventually
> results but if it is commented out is does not?
>
> Can the PC jump to random locations after loss of voltage or a brownout?
> There simply is no execution path that could possibly get to the flash write
> function during startup/voltage fail when there has been no other
> interaction with the device?
>
> Very confused.
>
> Jon
>
>
> Onestone-2 wrote:
>> Depenidng upon the amount of data you need to store I use a cyclic
>> store. using this method I have a device which stores time every minute.
>> they have been in use for over 10 years without a single report of flash
>> corruption or exhaustion. You will need a routine to detect the next
>> free address in your buffer, but that's quite easy.
>>
>> Cheers
>>
>> Al
>>
>> jpottaway wrote:
>>> Thanks guys,
>>>
>>> I think you have placed me on the right track.  I have determined there
>>> is a
>>> slight chance that Vcc could drop during an INFO memory write (battery
>>> operated device).  It was just curious as to why this would wipe the
>>> reset
>>> vector given info memory is in a completely separate location/block.
>>> Your
>>> idea of the write continuing along the reset vector is interesting.  At
>>> the
>>> core I think the lesson is that if power drops during a flash write the
>>> results are unpredictable!
>>>
>>> Jon
>>>
>>>
>>>
>>> Onestone-2 wrote:
>>>> This would suggest that in the middle of a flash write the power has
>>>> fallen below threshhold, a POR has been generated, but somehow the flash
>>>> write has continued using the reset fetch vector. I've never seen this,
>>>> just thinking out loud. I never attempt to save on power down for this
>>>> reason. If the data is urgent save it while power is secure. There are
>>>> plenty of ways around this.
>>>>
>>>> Al
>>>>
>>>> jpottaway wrote:
>>>>> Hi all.
>>>>>
>>>>> I have a MSP430 project which has been on commercial production for a
>>>>> few
>>>>> years.  However in the most recent batch we have been getting a number
>>>>> of
>>>>> devices returned with apparent corruption.  Reprogramming fixes the
>>>>> issue.
>>>>>
>>>>> On investigation of the corrupted devices it seems that the reset
>>>>> vector
>>>>> (FFFEh) has been corrupted and is 0000h instead of the 0080h it was
>>>>> originally programmed as.  I am at a loss to explain it.  The only
>>>>> flash
>>>>> writing the firmware does is to the INFO areas when power is removed to
>>>>> preserve settings.
>>>>>
>>>>> Anyone seem something like this before?
>>>>>
>>>>> Thanks in advance,
>>>>> Jon
>>
>

You should lock your flashwrite-function by a password(variable). This password
is set only in case of user interaction and releases your flashwrite-function
for only one time. That's just a work around. If you have a logging
functionality implemented, you could log every write access, to see whether your
flash is really written by that function.

Is it possible that the voltage drops are reducing the data retention time of
the flash? Probably not. I guess that in your case, more than the reset vector
is corrupted.

astalavista,
Stefan



--- In msp430@yahoogroups.com, jpottaway <jpottaway@...> wrote:
>
>
> Thanks so much for you assistance.
>
> The problem has gotten even more bizarre.  I have determined that sudden
> drops in voltage and/or repeated brownouts cause the flash corruption.  I
> have a simple function that saves user settings to flash when requested -
> this function never executes on startup and requires significant user
> interaction to actually run.  However, when this function is compiled into
> the code and the voltage is randomly moved about corruption eventually
> results but if it is commented out is does not?
>
> Can the PC jump to random locations after loss of voltage or a brownout?
> There simply is no execution path that could possibly get to the flash write
> function during startup/voltage fail when there has been no other
> interaction with the device?
>
> Very confused.
>
> Jon
>
>
> Onestone-2 wrote:
> >
> > Depenidng upon the amount of data you need to store I use a cyclic
> > store. using this method I have a device which stores time every minute.
> > they have been in use for over 10 years without a single report of flash
> > corruption or exhaustion. You will need a routine to detect the next
> > free address in your buffer, but that's quite easy.
> >
> > Cheers
> >
> > Al
> >
> > jpottaway wrote:
> >> Thanks guys,
> >>
> >> I think you have placed me on the right track.  I have determined there
> >> is a
> >> slight chance that Vcc could drop during an INFO memory write (battery
> >> operated device).  It was just curious as to why this would wipe the
> >> reset
> >> vector given info memory is in a completely separate location/block.
> >> Your
> >> idea of the write continuing along the reset vector is interesting.  At
> >> the
> >> core I think the lesson is that if power drops during a flash write the
> >> results are unpredictable!
> >>
> >> Jon
> >>
> >>
> >>
> >> Onestone-2 wrote:
> >>> This would suggest that in the middle of a flash write the power has
> >>> fallen below threshhold, a POR has been generated, but somehow the flash
> >>> write has continued using the reset fetch vector. I've never seen this,
> >>> just thinking out loud. I never attempt to save on power down for this
> >>> reason. If the data is urgent save it while power is secure. There are
> >>> plenty of ways around this.
> >>>
> >>> Al
> >>>
> >>> jpottaway wrote:
> >>>> Hi all.
> >>>>
> >>>> I have a MSP430 project which has been on commercial production for a
> >>>> few
> >>>> years.  However in the most recent batch we have been getting a number
> >>>> of
> >>>> devices returned with apparent corruption.  Reprogramming fixes the
> >>>> issue.
> >>>>
> >>>> On investigation of the corrupted devices it seems that the reset
> >>>> vector
> >>>> (FFFEh) has been corrupted and is 0000h instead of the 0080h it was
> >>>> originally programmed as.  I am at a loss to explain it.  The only
> >>>> flash
> >>>> writing the firmware does is to the INFO areas when power is removed to
> >>>> preserve settings.
> >>>>
> >>>> Anyone seem something like this before?
> >>>>
> >>>> Thanks in advance,
> >>>> Jon
> >>>
> >>
> >
> >
>
> --
> View this message in context:
http://www.nabble.com/Interrupt-Vector-Table-Corruption-tp24750598p24785431.html
> Sent from the MSP430 - Discuss mailing list archive at Nabble.com.
>

It may sound a little nutty, but Olimex has a "wireless USB JTAG".

http://www.olimex.com/dev/msp-jtag-rf.html
http://www.sparkfun.com/commerce/advanced_search_result.php?keywords=MSP430-JTAG\
-RF&x=0&y=0&search_section=products

It seems to be designed for situations like yours.  I haven't tried it.  The
price is a little higher than a TI or Software FET, but not terrible.

If you do take this path, please share your experiences with the group!

Stuart

--- In msp430@yahoogroups.com, "Robert J. Wilson" <bwilson4web@...> wrote:
>
> Hi,
>
> Before running the experiment, I checked the archives and didn't seen any
relevant postings for "JTAG distance". I'm working on a rapid prototype and plan
to put an MSP430 in the engine compartment and extend the JTAG ~10 ft (~3 m.)
back to the cabin and the eZ430 USB fob. Any best guesses on distance
limitations using Cat-5 cable and RJ-45 blocks?
>
> The reason is testing revealed the MSP430 daughter has survived 100C but the
USB eZ430 failed. Hence the reason why I'd like to extend the JTAG into the
cabin. The USB interface might not survive engine compartment temperatures.
>
> Yes, I'll share my results but thought I'd ask first if anyone had tried this
approach to extending JTAG using Cat-5 cable. Checking the Cat-5 specifications:
>
> 4 MHz, 13dB/1,000 ft
> 28.6 ohm/1000 ft
> 14 pF/ft
> 100 ohm impedance
>
> Back of the envelope for 10 ft. (~3 m) Cat-5 suggests:
>
> .13 dB attenuation, 4 MHz
> .572 ohms, round-trip
> 280 pF capacitance, round trip
>
> Thanks,
> Bob Wilson
>

Hi Robert,

> extend the JTAG ~10 ft (~3 m.) back to the cabin and the
> eZ430 USB fob. Any best guesses on distance limitations
> using Cat-5 cable and RJ-45 blocks?

The problem and may be the solution is in the datas you listed below:

> Checking the Cat-5 specifications:
> 4 MHz, 13dB/1,000 ft
> 28.6 ohm/1000 ft
> 14 pF/ft
> 100 ohm impedance

Ethernet for example uses 100 Ohm drivers to drive these lines. If you would do
this too, there will be no problems. Standard JTAG is not 100 Ohm. So if you
spent a drivercircuit on both sides of the cable there will be no problem to
drive 100 meters.

> Back of the envelope for 10 ft. (~3 m) Cat-5 suggests:
> .13 dB attenuation, 4 MHz

forget this, this is only relevant for a 100 ohm driver/receiver

> .572 ohms, round-trip

so this wouldn't be any problem

> 280 pF capacitance, round trip

why round trip? you want to drive 10 ft. teh relevant capacity that is seen by
your driver circuit is 140 pf. As far as I remember the JTAG-devices are fitted
with 74XY24x drivers. They should have less problems with this but the MSP could
habe this. So the first thing i would try is to spent an additional 74AC244 or
something like that on the MSP side of the CAT5-JTAG-cable. If this is not
enough, use 100 Ohm drivers on both sides.

Marte

Hi Amer.

I am reluctant to reply to your request as I am new to this group and know
almost nothing about the MSP430.
But as no one seems to be responding, here goes.

You didn't specify how often you need to measure the voltages.
However you may find that the 1-Wire bus (Dallas Semiconductor - now Maxim) may
suit your needs.
If it does, then the DS2540 Quad ADC, or similar, may be a suitable device to
measure the voltages.
These can be daisy-chained along the bus and each 1-Wire device has a unique ROM
ID that can be used to specify that device on the bus.
The 1-Wire bus can be driven, if that is the correct word, by a single MSP430
pin.

Take care.

Mike




________________________________
From: abufadel <amer@...>
To: msp430@yahoogroups.com
Sent: Friday, July 31, 2009 11:45:34 PM
Subject: [msp430] Dynamic Addressing?

 
Hello all,
I need to be able to measure voltages at about 100 locations. They are all
adjacent to each other, but some of them may be inserted in or removed from the
system after deployment.
I would like that every location be able to communicate its findings to a
central point, like a star network. The units most likely be daisy chained
togther. Power will pass through every unit to its neighbor and so on..

My questions are:

- Does anyone know of a bus structure that can handle automatic addressing? A
PCI bus comes to mind but I need something that can be implemented on msp430.

- If I decide to go wireless, how many nodes can SimplicTI handle, or is it
better to go with Zigbee?

Thank you for all your input.

Amer







[Non-text portions of this message have been removed]

Hi All.

My name is Mike and I, too, am a tech nut.
I' sure there is a 12-point program that you can help me with, but until then...

I am new to the group but have been loitering here a little while.
I know very little about the MSP430 but am most anxious to learn.

I used to read books about subject matters of interest to me (C/C++, VB, and so
on) but discovered that when I tried to complete a project that there was some
vital piece of information that had been omitted from the book(s) concerned.

So now I create 'realistic' projects - preferably something that can be extended
or built upon - and keep at it until that project has been completed. I find
this to be a far more successful means of learning for me.

And so I am formulating a project that I hope will teach me a lot about the uCs
in general and the MSP430 family in particular.

I wish to create a data logger.
Let us say that this data logger will measure ambient temperature as a minimum
and perhaps more later.
The data acquired will be transferred to a PC via a wireless link.

Seems like a simple spec, doesn't it :) (you can probably tell that the madness
set in a long time ago - I am assured that I was relatively normal until I,
figuratively speaking, met Kernigan and Ritchie)

The CC430f6137 seems like the ideal part for the job.
It will also allow me to extend myself later investigating such things
as LCDs and SPI and so on.

Knowing nothing at all about wireless - I have the greatest difficulty seting up
the video recorder - SimpliciTI would seem to be the place to start.

I have some queries, and please forgive my ignorance.
1. SimpliciTI
Is it possible, by that I mean without having to invent something new
- to setup a wireless link from a CC430f6137 to a Windows PC?
In other words are there Windows APIs/DLLs that allow comms between these?
2. MSP430 family
As far as I can determine there is no pin-event counter feature on these units.
By that I mean that signals into a particular pin cannot be counted except by
use of the CPU and code. Is this a correct interpretation of the docs?
3. DMA
As far as I can tell there is no DMA capability between memory and SPI? Would
this interpretation be correct?

Again please forgive my almost total ignornace at this point.
This is a condition I intend to correct.

Take care all.

Mike

Hi Mike. Your brain has been polluted by having come to
micro-controllers by way of programming languages such as C. Better to
have come to them via hardware, from which direction they appear
simpler, and more rational. C is a language of abstraction.
Micro-controllers deal with hard facts and the real world, and hence
can't truly be divorced from them.

A few personal observations, with the caveat that, although I have been
in this industry for almost 40 years, and have been using C for most of
them I am not a fan of C, or high level languages in general, on
micro-controllers.

I think a better place to start would be with the EZ430-2500 kit. It is
simpler, and I believe easier to understand.

Although I love the fact that finally there is an RF transceiver/micro
combination that does NOT have an 8051 core, I'm not a fan of the
CC1101. Too many bugs still, and far more complex than it needs to be to
handle. I believe it should have been more tightly integrated into the
micro than it was. This was a lazy job. The fact that it doesn't include
USB also shows how poorly thought through their product chain has
become, since the 5529 does have USB but no RF.

1. You can set up a small network with 2 EZ430-2500 kits modify the code
and learn some useful stuff, then add your own sensors as you go. I
think TI have the PC codes for these, and they are available. I roll my own.

2. Almost any micro can implement a pin event counter, look for clock
type inputs in the data sheets, then study the user guide to find out
how to configure them.

3. DMA can use any RAM (just about) as source or destination, including
registers associated with peripherals like the UARTs and SPI. How much
you really gain from using it for SPI is dubious in my opinion, since it
is not a truly independent CPU, ie it still consumes clock cycles.

Cheers

Al

solarquark wrote:
> Hi All.
>
> My name is Mike and I, too, am a tech nut.
> I' sure there is a 12-point program that you can help me with, but until
then...
>
> I am new to the group but have been loitering here a little while.
> I know very little about the MSP430 but am most anxious to learn.
>
> I used to read books about subject matters of interest to me (C/C++, VB, and
so on) but discovered that when I tried to complete a project that there was
some vital piece of information that had been omitted from the book(s)
concerned.
>
> So now I create 'realistic' projects - preferably something that can be
extended or built upon - and keep at it until that project has been completed. I
find this to be a far more successful means of learning for me.
>
> And so I am formulating a project that I hope will teach me a lot about the
uCs in general and the MSP430 family in particular.
>
> I wish to create a data logger.
> Let us say that this data logger will measure ambient temperature as a minimum
and perhaps more later.
> The data acquired will be transferred to a PC via a wireless link.
>
> Seems like a simple spec, doesn't it :) (you can probably tell that the
madness set in a long time ago - I am assured that I was relatively normal until
I, figuratively speaking, met Kernigan and Ritchie)
>
> The CC430f6137 seems like the ideal part for the job.
> It will also allow me to extend myself later investigating such things
> as LCDs and SPI and so on.
>
> Knowing nothing at all about wireless - I have the greatest difficulty seting
up the video recorder - SimpliciTI would seem to be the place to start.
>
> I have some queries, and please forgive my ignorance.
> 1. SimpliciTI
> Is it possible, by that I mean without having to invent something new
> - to setup a wireless link from a CC430f6137 to a Windows PC?
> In other words are there Windows APIs/DLLs that allow comms between these?
> 2. MSP430 family
> As far as I can determine there is no pin-event counter feature on these
units. By that I mean that signals into a particular pin cannot be counted
except by use of the CPU and code. Is this a correct interpretation of the docs?
> 3. DMA
> As far as I can tell there is no DMA capability between memory and SPI? Would
this interpretation be correct?
>
> Again please forgive my almost total ignornace at this point.
> This is a condition I intend to correct.
>
> Take care all.
>
> Mike
>
>
>
> ------------------------------------
>
> To unsubscribe from the msp430 group, send an email to:
> msp430-unsubscribe@egroups.com
>
> Yahoo! Groups Links
>
>
>
>

Please see below.--ER

Emmett Redd Ph.D.   mailto:EmmettRedd@...
Professor                                 (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University             Fax (417)836-6226
901 SOUTH NATIONAL                   Dept (417)836-5131
SPRINGFIELD, MO  65897   USA

"In theory there is no difference between theory and practice. In practice there
is." -- Yogi Berra or Jan van de Snepscheut



-----Original Message-----
From: msp430@yahoogroups.com on behalf of jpottaway
Sent: Mon 8/3/2009 12:14 AM
To: msp430@yahoogroups.com
Subject: Re: [msp430] Interrupt Vector Table Corruption


Thanks so much for you assistance.

The problem has gotten even more bizarre.  I have determined that sudden
drops in voltage and/or repeated brownouts cause the flash corruption.  I
have a simple function that saves user settings to flash when requested -
this function never executes on startup and requires significant user
interaction to actually run.  However, when this function is compiled into
the code and the voltage is randomly moved about corruption eventually
results but if it is commented out is does not?

Can the PC jump to random locations after loss of voltage or a brownout?

ER--From what I remember, this is one method used by hackers to bypass security
and attempt to copy code.

There simply is no execution path that could possibly get to the flash write
function during startup/voltage fail when there has been no other
interaction with the device?

Very confused.

Jon




[Non-text portions of this message have been removed]

Hi Al.

Can I call you Al?

Actually I suppose it was the other way around.
I came to programming languages via the uC.
I still remember _way_ back when men were men and sheep were frightened.
Back then the 8080 and the 6800 were just having children (not together AFAIK -
that would have produced interesting offspring).
I got to play a little with the 8085 and the 6502 (a Rockwell variant of the
6802 IIRC).
I still remember that 31 c2 20 was the machine code to initialise the stack at
0x20c2 on the 8085.
Ah, those were the days!

Time passes.
A lot of time has passed, perhaps far too much since then.
Electronics was my first love and it is past time I repaid her a visit.

I have taken a quick look at the ez430-2500.
It looks nice too.
It uses the MSP430f2274.
This part is somewhat limited in capability compared to the MSP430f6137.
This doesn't matter much now but might limit my learning later on.
Ah, decisions, decisions!
You refer to certain problems with the CC430f6137.
Are these problems related solely to the wireless side - the CC1101?
Are TI working to resolve these problems or will the product remain
substantially as is?
In other words, if I wait a while would the CC4306137 then become a more viable
option?

When you say TI have the 'PC code', do you mean that there are APIs available to
allow a Windows front-end to be developed or do you mean that there is code for
the PC development of the end device, i.e. using a PC based development platform
to create code for the end device?

The MSP family user guide makes a lot of the low power modes and that integrated
devices such as ADCs and DMA can operate independent of the CPU and when the
device is in a low power mode.
So, for instance, the ADC can operate independently of the CPU and when it had
completed a conversion it can cause an interrupt and wake-up the CPU. After the
CPU has finished it will re-enter the low power mode. However there doesn't seem
to be a similar capability to count events at a pin. Perhaps I missed something?

Also I see that the DMA can handle a transfer to the IIC interface. And the IIC
interface can request new data from the DMA controller when it requires it. As I
understood, or mis-understood, it all this can happen with the device in a low
power mode. There is no mention of such a capability with the SPI interface.
Again perhaps I missed something?

Thanks for your reply, Al.
This gives me a lot to mull over.

Take care.

Mike



________________________________
From: OneStone <onestone@...>
To: msp430@yahoogroups.com
Sent: Monday, August 3, 2009 4:23:35 PM
Subject: Re: [msp430] Introduction and Queries

 
Hi Mike. Your brain has been polluted by having come to
micro-controllers by way of programming languages such as C. Better to
have come to them via hardware, from which direction they appear
simpler, and more rational. C is a language of abstraction.
Micro-controllers deal with hard facts and the real world, and hence
can't truly be divorced from them.

A few personal observations, with the caveat that, although I have been
in this industry for almost 40 years, and have been using C for most of
them I am not a fan of C, or high level languages in general, on
micro-controllers.

I think a better place to start would be with the EZ430-2500 kit. It is
simpler, and I believe easier to understand.

Although I love the fact that finally there is an RF transceiver/ micro
combination that does NOT have an 8051 core, I'm not a fan of the
CC1101. Too many bugs still, and far more complex than it needs to be to
handle. I believe it should have been more tightly integrated into the
micro than it was. This was a lazy job. The fact that it doesn't include
USB also shows how poorly thought through their product chain has
become, since the 5529 does have USB but no RF.

1. You can set up a small network with 2 EZ430-2500 kits modify the code
and learn some useful stuff, then add your own sensors as you go. I
think TI have the PC codes for these, and they are available. I roll my own.

2. Almost any micro can implement a pin event counter, look for clock
type inputs in the data sheets, then study the user guide to find out
how to configure them.

3. DMA can use any RAM (just about) as source or destination, including
registers associated with peripherals like the UARTs and SPI. How much
you really gain from using it for SPI is dubious in my opinion, since it
is not a truly independent CPU, ie it still consumes clock cycles.

Cheers

Al

solarquark wrote:
> Hi All.
>
> My name is Mike and I, too, am a tech nut.
> I' sure there is a 12-point program that you can help me with, but until
then...
>
> I am new to the group but have been loitering here a little while.
> I know very little about the MSP430 but am most anxious to learn.
>
> I used to read books about subject matters of interest to me (C/C++, VB, and
so on) but discovered that when I tried to complete a project that there was
some vital piece of information that had been omitted from the book(s)
concerned.
>
> So now I create 'realistic' projects - preferably something that can be
extended or built upon - and keep at it until that project has been completed. I
find this to be a far more successful means of learning for me.
>
> And so I am formulating a project that I hope will teach me a lot about the
uCs in general and the MSP430 family in particular.
>
> I wish to create a data logger.
> Let us say that this data logger will measure ambient temperature as a minimum
and perhaps more later.
> The data acquired will be transferred to a PC via a wireless link.
>
> Seems like a simple spec, doesn't it :) (you can probably tell that the
madness set in a long time ago - I am assured that I was relatively normal until
I, figuratively speaking, met Kernigan and Ritchie)
>
> The CC430f6137 seems like the ideal part for the job.
> It will also allow me to extend myself later investigating such things
> as LCDs and SPI and so on.
>
> Knowing nothing at all about wireless - I have the greatest difficulty seting
up the video recorder - SimpliciTI would seem to be the place to start.
>
> I have some queries, and please forgive my ignorance.
> 1. SimpliciTI
> Is it possible, by that I mean without having to invent something new
> - to setup a wireless link from a CC430f6137 to a Windows PC?
> In other words are there Windows APIs/DLLs that allow comms between these?
> 2. MSP430 family
> As far as I can determine there is no pin-event counter feature on these
units. By that I mean that signals into a particular pin cannot be counted
except by use of the CPU and code. Is this a correct interpretation of the docs?
> 3. DMA
> As far as I can tell there is no DMA capability between memory and SPI? Would
this interpretation be correct?
>
> Again please forgive my almost total ignornace at this point.
> This is a condition I intend to correct.
>
> Take care all.
>
> Mike
>
>
>
> ------------ --------- --------- ------
>
> To unsubscribe from the msp430 group, send an email to:
> msp430-unsubscribe@ egroups.com
>
> Yahoo! Groups Links
>
>
>
>






[Non-text portions of this message have been removed]

Hi Mike, you're more than welcome to call me Al, as the song goes, many
people here call me far worse! Ah, so you're a newbie :@}, well so am I
compared to opa joerg and OCY, I just started jung (sorry, psycho joke).

OK, That's good, a lot of guys jump into micros from the PC world, not a
bad thing of course, anybody who has a go is good thing, but it is a
very different world as you will know.

I worked with the very first versions of the Cc1100. the CC1101 is an
upgrade, but unfortunately they really only improved ona  few issues
related to FCC regs, not many of the control related issues. It is a bit
of a pain to program, and, in my view too cumbersome. If you look at the
errata sheet for the CC1101 you will see what I mean. Basic things like
the status (MARCSTATE) register cannot be relied on, and there is not in
my opinion a satisfactory workaround. this wasn't fixed according to the
CC1101 errata when I last looked, so has probably crawled over into the
CC430. Also you ask about PC AI's and DLL's. Ti are very slow to get off
the mark with support for their newest stuff, normally. this device
family has been trumpeted loudly for some time, but I can't see much in
the way of a dev kit or even application notes for it. I have no doubt
that these will come, and when they do they will be great if you want to
stick to basic stuff. But I've found that if you want tyo do something
even remotely off the beaten track you are on your own.

When the CC1100 was new I couldn't even get an answer from Ti on the
best way to match the antenna for use in differential mode. It strikes
me as odd that most of these single chip transceivers have a
differential output yet all the reference designs have matching circuits
for a single ended antenna.

In the end I went away from the Ti Rf stuff.

So will Ti correct the bugs? Probably not. Are they a huge problem? For
those who have gotten used to them no, for those who are doing mostly
mundane stuff, probably not, for those pushing the envelope a little,
yes, they might be.

Will TI correct all the errata in ther 6137? Likely not, since the 149
and a lot of earlier parts still have many bugs that are 10 years old,
and many newer parts have inherited these. Again this isn't a problem if
you are aware of them, and there is probably not a single device of any
complexity out there that doesn't have some bugs buried inside it.
personally I still think the MSP430 is one of the best micros on the
market. I haven't found a need to go to another family yet. there was an
argument sometime ago about whether it was worth using if the
application didin't require low power consumption. My personal response
is that EVERY application should be made to consume as little power as
possible, but that's another pulpit to preach from! Suffice to say were
the PC world to adopt efficient coding techniques and effcient energy
managemtn design it would be the same as taking 30 million cars off the
road in terms of the environmental impact, but even Al gore doesn't get it!

Don't think the 2274 is in any way limited. I have a data logger that
includes the following:-

RF transceiver
temp sensor
pressure sensor
humidity sensor
GPS
3D accelerometer
3D mag field sensor
3D gyro
16M external memory
LEDs
optical sensors
remote reprogramming
UART for hardware mission upload/download if required
and an optional 64k colour LCD

it has plenty of spare memory and spare pins

At the other extreme I have a wireless data logger that measures 11.4mm
square which uses an mSP430F2131 and the CC1100 it has a range of at
least 130mtr indoors using a simple 0.8mm copper wire loop antenna
folded back over the PCB, and includes a motion sensor, optical sensor,
LEDs, and a TACT switch. There is a picture of this in my piccies folder
on the group site if you're interested

http://d.yimg.com/kq/groups/2342629/sn/1133855661/name/n_a

Currently I am using the Nordic nRF24L01P for some designs, as I like
the level of automation and the 6 receive channel addresses. There is
absolutely minimal CPU overhead. It adds a lot of flexibility. It also
has good range considering its a 2.4Ghz low power device, with a high
data rate, and not quite as good sensitivity as some devices. It can
also operate with a fairly poor quality crystal, surprisingly enough,
although I don't chance that! Although a bit bulkier than the circuit
for the Nordic, and not quite as flexible, or as automated as the Nordic
stuff the Microchip MRF24J40MA/B is also a very nice part, and I have
tested it's LOS range to up to 400mtr, although its bulk means I'm
currently not using it in any designs. Finally I also source some
semi-custom parts from Asia, that pack the entire circuit into a smaller
area than the Nordic IC, which itself is only 4x4mm., so it may be worth
hunting around there before you commit.

Cheers for now

Al


Michael Malone wrote:
> Hi Al.
>
> Can I call you Al?
>
> Actually I suppose it was the other way around. I came to programming
> languages via the uC. I still remember _way_ back when men were men
> and sheep were frightened. Back then the 8080 and the 6800 were just
> having children (not together AFAIK - that would have produced
> interesting offspring). I got to play a little with the 8085 and the
> 6502 (a Rockwell variant of the 6802 IIRC). I still remember that 31
> c2 20 was the machine code to initialise the stack at 0x20c2 on the
> 8085. Ah, those were the days!
>
> Time passes. A lot of time has passed, perhaps far too much since
> then. Electronics was my first love and it is past time I repaid her
> a visit.
>
> I have taken a quick look at the ez430-2500. It looks nice too. It
> uses the MSP430f2274. This part is somewhat limited in capability
> compared to the MSP430f6137. This doesn't matter much now but might
> limit my learning later on. Ah, decisions, decisions! You refer to
> certain problems with the CC430f6137. Are these problems related
> solely to the wireless side - the CC1101? Are TI working to resolve
> these problems or will the product remain substantially as is? In
> other words, if I wait a while would the CC4306137 then become a more
> viable option?
>
> When you say TI have the 'PC code', do you mean that there are APIs
> available to allow a Windows front-end to be developed or do you mean
> that there is code for the PC development of the end device, i.e.
> using a PC based development platform to create code for the end
> device?
>
> The MSP family user guide makes a lot of the low power modes and that
> integrated devices such as ADCs and DMA can operate independent of
> the CPU and when the device is in a low power mode. So, for instance,
> the ADC can operate independently of the CPU and when it had
> completed a conversion it can cause an interrupt and wake-up the CPU.
> After the CPU has finished it will re-enter the low power mode.
> However there doesn't seem to be a similar capability to count events
> at a pin. Perhaps I missed something?
>
> Also I see that the DMA can handle a transfer to the IIC interface.
> And the IIC interface can request new data from the DMA controller
> when it requires it. As I understood, or mis-understood, it all this
> can happen with the device in a low power mode. There is no mention
> of such a capability with the SPI interface. Again perhaps I missed
> something?
>
> Thanks for your reply, Al. This gives me a lot to mull over.
>
> Take care.
>
> Mike
>
>
>
> ________________________________ From: OneStone
> <onestone@...> To: msp430@yahoogroups.com Sent: Monday,
> August 3, 2009 4:23:35 PM Subject: Re: [msp430] Introduction and
> Queries
>
>
> Hi Mike. Your brain has been polluted by having come to
> micro-controllers by way of programming languages such as C. Better
> to have come to them via hardware, from which direction they appear
> simpler, and more rational. C is a language of abstraction.
> Micro-controllers deal with hard facts and the real world, and hence
>  can't truly be divorced from them.
>
> A few personal observations, with the caveat that, although I have
> been in this industry for almost 40 years, and have been using C for
> most of them I am not a fan of C, or high level languages in general,
> on micro-controllers.
>
> I think a better place to start would be with the EZ430-2500 kit. It
> is simpler, and I believe easier to understand.
>
> Although I love the fact that finally there is an RF transceiver/
> micro combination that does NOT have an 8051 core, I'm not a fan of
> the CC1101. Too many bugs still, and far more complex than it needs
> to be to handle. I believe it should have been more tightly
> integrated into the micro than it was. This was a lazy job. The fact
> that it doesn't include USB also shows how poorly thought through
> their product chain has become, since the 5529 does have USB but no
> RF.
>
> 1. You can set up a small network with 2 EZ430-2500 kits modify the
> code and learn some useful stuff, then add your own sensors as you
> go. I think TI have the PC codes for these, and they are available. I
> roll my own.
>
> 2. Almost any micro can implement a pin event counter, look for clock
>  type inputs in the data sheets, then study the user guide to find
> out how to configure them.
>
> 3. DMA can use any RAM (just about) as source or destination,
> including registers associated with peripherals like the UARTs and
> SPI. How much you really gain from using it for SPI is dubious in my
> opinion, since it is not a truly independent CPU, ie it still
> consumes clock cycles.
>
> Cheers
>
> Al
>
> solarquark wrote:
>> Hi All.
>>
>> My name is Mike and I, too, am a tech nut. I' sure there is a
>> 12-point program that you can help me with, but until then...
>>
>> I am new to the group but have been loitering here a little while.
>> I know very little about the MSP430 but am most anxious to learn.
>>
>> I used to read books about subject matters of interest to me
>> (C/C++, VB, and so on) but discovered that when I tried to complete
>> a project that there was some vital piece of information that had
>> been omitted from the book(s) concerned.
>>
>> So now I create 'realistic' projects - preferably something that
>> can be extended or built upon - and keep at it until that project
>> has been completed. I find this to be a far more successful means
>> of learning for me.
>>
>> And so I am formulating a project that I hope will teach me a lot
>> about the uCs in general and the MSP430 family in particular.
>>
>> I wish to create a data logger. Let us say that this data logger
>> will measure ambient temperature as a minimum and perhaps more
>> later. The data acquired will be transferred to a PC via a wireless
>> link.
>>
>> Seems like a simple spec, doesn't it :) (you can probably tell that
>> the madness set in a long time ago - I am assured that I was
>> relatively normal until I, figuratively speaking, met Kernigan and
>> Ritchie)
>>
>> The CC430f6137 seems like the ideal part for the job. It will also
>> allow me to extend myself later investigating such things as LCDs
>> and SPI and so on.
>>
>> Knowing nothing at all about wireless - I have the greatest
>> difficulty seting up the video recorder - SimpliciTI would seem to
>> be the place to start.
>>
>> I have some queries, and please forgive my ignorance. 1. SimpliciTI
>>  Is it possible, by that I mean without having to invent something
>> new - to setup a wireless link from a CC430f6137 to a Windows PC?
>> In other words are there Windows APIs/DLLs that allow comms between
>> these? 2. MSP430 family As far as I can determine there is no
>> pin-event counter feature on these units. By that I mean that
>> signals into a particular pin cannot be counted except by use of
>> the CPU and code. Is this a correct interpretation of the docs? 3.
>> DMA As far as I can tell there is no DMA capability between memory
>> and SPI? Would this interpretation be correct?
>>
>> Again please forgive my almost total ignornace at this point. This
>> is a condition I intend to correct.
>>
>> Take care all.
>>
>> Mike
>>
>>
>>
>> ------------ --------- --------- ------
>>
>> To unsubscribe from the msp430 group, send an email to:
>> msp430-unsubscribe@ egroups.com
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> To unsubscribe from the msp430 group, send an email to:
> msp430-unsubscribe@egroups.com
>
> Yahoo! Groups Links
>
>
>

"Can the PC jump to random locations after loss of voltage or a brownout?"

Yes, and worse things can happen too.

Which MSP430 are you using?

Is there a BOR feature? If so, do you ever change the BOR settings of BCS? When
and under what condition?

Is there a SVS feature? If so, do you use it and how?

Did you have any other means to monitor Vcc?

Most likely, the MSP430 "crashed" during brownout. Any seemingly irrational
events can happen.

--- In msp430@yahoogroups.com, jpottaway <jpottaway@...> wrote:
>
>
> Thanks so much for you assistance.
>
> The problem has gotten even more bizarre.  I have determined that sudden
> drops in voltage and/or repeated brownouts cause the flash corruption.  I
> have a simple function that saves user settings to flash when requested -
> this function never executes on startup and requires significant user
> interaction to actually run.  However, when this function is compiled into
> the code and the voltage is randomly moved about corruption eventually
> results but if it is commented out is does not?
>
> Can the PC jump to random locations after loss of voltage or a brownout?
> There simply is no execution path that could possibly get to the flash write
> function during startup/voltage fail when there has been no other
> interaction with the device?
>
> Very confused.
>
> Jon
>
>
> Onestone-2 wrote:
> >
> > Depenidng upon the amount of data you need to store I use a cyclic
> > store. using this method I have a device which stores time every minute.
> > they have been in use for over 10 years without a single report of flash
> > corruption or exhaustion. You will need a routine to detect the next
> > free address in your buffer, but that's quite easy.
> >
> > Cheers
> >
> > Al
> >
> > jpottaway wrote:
> >> Thanks guys,
> >>
> >> I think you have placed me on the right track.  I have determined there
> >> is a
> >> slight chance that Vcc could drop during an INFO memory write (battery
> >> operated device).  It was just curious as to why this would wipe the
> >> reset
> >> vector given info memory is in a completely separate location/block.
> >> Your
> >> idea of the write continuing along the reset vector is interesting.  At
> >> the
> >> core I think the lesson is that if power drops during a flash write the
> >> results are unpredictable!
> >>
> >> Jon
> >>
> >>
> >>
> >> Onestone-2 wrote:
> >>> This would suggest that in the middle of a flash write the power has
> >>> fallen below threshhold, a POR has been generated, but somehow the flash
> >>> write has continued using the reset fetch vector. I've never seen this,
> >>> just thinking out loud. I never attempt to save on power down for this
> >>> reason. If the data is urgent save it while power is secure. There are
> >>> plenty of ways around this.
> >>>
> >>> Al
> >>>
> >>> jpottaway wrote:
> >>>> Hi all.
> >>>>
> >>>> I have a MSP430 project which has been on commercial production for a
> >>>> few
> >>>> years.  However in the most recent batch we have been getting a number
> >>>> of
> >>>> devices returned with apparent corruption.  Reprogramming fixes the
> >>>> issue.
> >>>>
> >>>> On investigation of the corrupted devices it seems that the reset
> >>>> vector
> >>>> (FFFEh) has been corrupted and is 0000h instead of the 0080h it was
> >>>> originally programmed as.  I am at a loss to explain it.  The only
> >>>> flash
> >>>> writing the firmware does is to the INFO areas when power is removed to
> >>>> preserve settings.
> >>>>
> >>>> Anyone seem something like this before?
> >>>>
> >>>> Thanks in advance,
> >>>> Jon
> >>>
> >>
> >
> >
>
> --
> View this message in context:
http://www.nabble.com/Interrupt-Vector-Table-Corruption-tp24750598p24785431.html
> Sent from the MSP430 - Discuss mailing list archive at Nabble.com.
>

Thank you Al.

You have given me quite a bit (intended) to consider.
I think I'll have to put myself into LPM4 or 5 for a while (intended).

Take care.

Mike




________________________________
From: OneStone <onestone@...>
To: msp430@yahoogroups.com
Sent: Monday, August 3, 2009 7:07:49 PM
Subject: Re: [msp430] Introduction and Queries

 
Hi Mike, you're more than welcome to call me Al, as the song goes, many
people here call me far worse! Ah, so you're a newbie :@}, well so am I
compared to opa joerg and OCY, I just started jung (sorry, psycho joke).

OK, That's good, a lot of guys jump into micros from the PC world, not a
bad thing of course, anybody who has a go is good thing, but it is a
very different world as you will know.

I worked with the very first versions of the Cc1100. the CC1101 is an
upgrade, but unfortunately they really only improved ona few issues
related to FCC regs, not many of the control related issues. It is a bit
of a pain to program, and, in my view too cumbersome. If you look at the
errata sheet for the CC1101 you will see what I mean. Basic things like
the status (MARCSTATE) register cannot be relied on, and there is not in
my opinion a satisfactory workaround. this wasn't fixed according to the
CC1101 errata when I last looked, so has probably crawled over into the
CC430. Also you ask about PC AI's and DLL's. Ti are very slow to get off
the mark with support for their newest stuff, normally. this device
family has been trumpeted loudly for some time, but I can't see much in
the way of a dev kit or even application notes for it. I have no doubt
that these will come, and when they do they will be great if you want to
stick to basic stuff. But I've found that if you want tyo do something
even remotely off the beaten track you are on your own.

When the CC1100 was new I couldn't even get an answer from Ti on the
best way to match the antenna for use in differential mode. It strikes
me as odd that most of these single chip transceivers have a
differential output yet all the reference designs have matching circuits
for a single ended antenna.

In the end I went away from the Ti Rf stuff.

So will Ti correct the bugs? Probably not. Are they a huge problem? For
those who have gotten used to them no, for those who are doing mostly
mundane stuff, probably not, for those pushing the envelope a little,
yes, they might be.

Will TI correct all the errata in ther 6137? Likely not, since the 149
and a lot of earlier parts still have many bugs that are 10 years old,
and many newer parts have inherited these. Again this isn't a problem if
you are aware of them, and there is probably not a single device of any
complexity out there that doesn't have some bugs buried inside it.
personally I still think the MSP430 is one of the best micros on the
market. I haven't found a need to go to another family yet. there was an
argument sometime ago about whether it was worth using if the
application didin't require low power consumption. My personal response
is that EVERY application should be made to consume as little power as
possible, but that's another pulpit to preach from! Suffice to say were
the PC world to adopt efficient coding techniques and effcient energy
managemtn design it would be the same as taking 30 million cars off the
road in terms of the environmental impact, but even Al gore doesn't get it!

Don't think the 2274 is in any way limited. I have a data logger that
includes the following:-

RF transceiver
temp sensor
pressure sensor
humidity sensor
GPS
3D accelerometer
3D mag field sensor
3D gyro
16M external memory
LEDs
optical sensors
remote reprogramming
UART for hardware mission upload/download if required
and an optional 64k colour LCD

it has plenty of spare memory and spare pins

At the other extreme I have a wireless data logger that measures 11.4mm
square which uses an mSP430F2131 and the CC1100 it has a range of at
least 130mtr indoors using a simple 0.8mm copper wire loop antenna
folded back over the PCB, and includes a motion sensor, optical sensor,
LEDs, and a TACT switch. There is a picture of this in my piccies folder
on the group site if you're interested

http://d.yimg. com/kq/groups/ 2342629/sn/ 1133855661/ name/n_a

Currently I am using the Nordic nRF24L01P for some designs, as I like
the level of automation and the 6 receive channel addresses. There is
absolutely minimal CPU overhead. It adds a lot of flexibility. It also
has good range considering its a 2.4Ghz low power device, with a high
data rate, and not quite as good sensitivity as some devices. It can
also operate with a fairly poor quality crystal, surprisingly enough,
although I don't chance that! Although a bit bulkier than the circuit
for the Nordic, and not quite as flexible, or as automated as the Nordic
stuff the Microchip MRF24J40MA/B is also a very nice part, and I have
tested it's LOS range to up to 400mtr, although its bulk means I'm
currently not using it in any designs. Finally I also source some
semi-custom parts from Asia, that pack the entire circuit into a smaller
area than the Nordic IC, which itself is only 4x4mm., so it may be worth
hunting around there before you commit.

Cheers for now

Al

Michael Malone wrote:
> Hi Al.
>
> Can I call you Al?
>
> Actually I suppose it was the other way around. I came to programming
> languages via the uC. I still remember _way_ back when men were men
> and sheep were frightened. Back then the 8080 and the 6800 were just
> having children (not together AFAIK - that would have produced
> interesting offspring). I got to play a little with the 8085 and the
> 6502 (a Rockwell variant of the 6802 IIRC). I still remember that 31
> c2 20 was the machine code to initialise the stack at 0x20c2 on the
> 8085. Ah, those were the days!
>
> Time passes. A lot of time has passed, perhaps far too much since
> then. Electronics was my first love and it is past time I repaid her
> a visit.
>
> I have taken a quick look at the ez430-2500. It looks nice too. It
> uses the MSP430f2274. This part is somewhat limited in capability
> compared to the MSP430f6137. This doesn't matter much now but might
> limit my learning later on. Ah, decisions, decisions! You refer to
> certain problems with the CC430f6137. Are these problems related
> solely to the wireless side - the CC1101? Are TI working to resolve
> these problems or will the product remain substantially as is? In
> other words, if I wait a while would the CC4306137 then become a more
> viable option?
>
> When you say TI have the 'PC code', do you mean that there are APIs
> available to allow a Windows front-end to be developed or do you mean
> that there is code for the PC development of the end device, i.e.
> using a PC based development platform to create code for the end
> device?
>
> The MSP family user guide makes a lot of the low power modes and that
> integrated devices such as ADCs and DMA can operate independent of
> the CPU and when the device is in a low power mode. So, for instance,
> the ADC can operate independently of the CPU and when it had
> completed a conversion it can cause an interrupt and wake-up the CPU.
> After the CPU has finished it will re-enter the low power mode.
> However there doesn't seem to be a similar capability to count events
> at a pin. Perhaps I missed something?
>
> Also I see that the DMA can handle a transfer to the IIC interface.
> And the IIC interface can request new data from the DMA controller
> when it requires it. As I understood, or mis-understood, it all this
> can happen with the device in a low power mode. There is no mention
> of such a capability with the SPI interface. Again perhaps I missed
> something?
>
> Thanks for your reply, Al. This gives me a lot to mull over.
>
> Take care.
>
> Mike
>
>
>
> ____________ _________ _________ __ From: OneStone
> <onestone@bigpond. net.au> To: msp430@yahoogroups. com Sent: Monday,
> August 3, 2009 4:23:35 PM Subject: Re: [msp430] Introduction and
> Queries
>
>
> Hi Mike. Your brain has been polluted by having come to
> micro-controllers by way of programming languages such as C. Better
> to have come to them via hardware, from which direction they appear
> simpler, and more rational. C is a language of abstraction.
> Micro-controllers deal with hard facts and the real world, and hence
> can't truly be divorced from them.
>
> A few personal observations, with the caveat that, although I have
> been in this industry for almost 40 years, and have been using C for
> most of them I am not a fan of C, or high level languages in general,
> on micro-controllers.
>
> I think a better place to start would be with the EZ430-2500 kit. It
> is simpler, and I believe easier to understand.
>
> Although I love the fact that finally there is an RF transceiver/
> micro combination that does NOT have an 8051 core, I'm not a fan of
> the CC1101. Too many bugs still, and far more complex than it needs
> to be to handle. I believe it should have been more tightly
> integrated into the micro than it was. This was a lazy job. The fact
> that it doesn't include USB also shows how poorly thought through
> their product chain has become, since the 5529 does have USB but no
> RF.
>
> 1. You can set up a small network with 2 EZ430-2500 kits modify the
> code and learn some useful stuff, then add your own sensors as you
> go. I think TI have the PC codes for these, and they are available. I
> roll my own.
>
> 2. Almost any micro can implement a pin event counter, look for clock
> type inputs in the data sheets, then study the user guide to find
> out how to configure them.
>
> 3. DMA can use any RAM (just about) as source or destination,
> including registers associated with peripherals like the UARTs and
> SPI. How much you really gain from using it for SPI is dubious in my
> opinion, since it is not a truly independent CPU, ie it still
> consumes clock cycles.
>
> Cheers
>
> Al
>
> solarquark wrote:
>> Hi All.
>>
>> My name is Mike and I, too, am a tech nut. I' sure there is a
>> 12-point program that you can help me with, but until then...
>>
>> I am new to the group but have been loitering here a little while.
>> I know very little about the MSP430 but am most anxious to learn.
>>
>> I used to read books about subject matters of interest to me
>> (C/C++, VB, and so on) but discovered that when I tried to complete
>> a project that there was some vital piece of information that had
>> been omitted from the book(s) concerned.
>>
>> So now I create 'realistic' projects - preferably something that
>> can be extended or built upon - and keep at it until that project
>> has been completed. I find this to be a far more successful means
>> of learning for me.
>>
>> And so I am formulating a project that I hope will teach me a lot
>> about the uCs in general and the MSP430 family in particular.
>>
>> I wish to create a data logger. Let us say that this data logger
>> will measure ambient temperature as a minimum and perhaps more
>> later. The data acquired will be transferred to a PC via a wireless
>> link.
>>
>> Seems like a simple spec, doesn't it :) (you can probably tell that
>> the madness set in a long time ago - I am assured that I was
>> relatively normal until I, figuratively speaking, met Kernigan and
>> Ritchie)
>>
>> The CC430f6137 seems like the ideal part for the job. It will also
>> allow me to extend myself later investigating such things as LCDs
>> and SPI and so on.
>>
>> Knowing nothing at all about wireless - I have the greatest
>> difficulty seting up the video recorder - SimpliciTI would seem to
>> be the place to start.
>>
>> I have some queries, and please forgive my ignorance. 1. SimpliciTI
>> Is it possible, by that I mean without having to invent something
>> new - to setup a wireless link from a CC430f6137 to a Windows PC?
>> In other words are there Windows APIs/DLLs that allow comms between
>> these? 2. MSP430 family As far as I can determine there is no
>> pin-event counter feature on these units. By that I mean that
>> signals into a particular pin cannot be counted except by use of
>> the CPU and code. Is this a correct interpretation of the docs? 3.
>> DMA As far as I can tell there is no DMA capability between memory
>> and SPI? Would this interpretation be correct?
>>
>> Again please forgive my almost total ignornace at this point. This
>> is a condition I intend to correct.
>>
>> Take care all.
>>
>> Mike
>>
>>
>>
>> ------------ --------- --------- ------
>>
>> To unsubscribe from the msp430 group, send an email to:
>> msp430-unsubscribe@ egroups.com
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------ --------- --------- ------
>
> To unsubscribe from the msp430 group, send an email to:
> msp430-unsubscribe@ egroups.com
>
> Yahoo! Groups Links
>
>
>






[Non-text portions of this message have been removed]

Wow!.

http://d.yimg.com/kq/groups/2342629/sn/1133855661/name/n_a

That's small.

Mike



________________________________
From: OneStone <onestone@...>
To: msp430@yahoogroups.com
Sent: Monday, August 3, 2009 7:07:49 PM
Subject: Re: [msp430] Introduction and Queries

 
Hi Mike, you're more than welcome to call me Al, as the song goes, many
people here call me far worse! Ah, so you're a newbie :@}, well so am I
compared to opa joerg and OCY, I just started jung (sorry, psycho joke).

OK, That's good, a lot of guys jump into micros from the PC world, not a
bad thing of course, anybody who has a go is good thing, but it is a
very different world as you will know.

I worked with the very first versions of the Cc1100. the CC1101 is an
upgrade, but unfortunately they really only improved ona few issues
related to FCC regs, not many of the control related issues. It is a bit
of a pain to program, and, in my view too cumbersome. If you look at the
errata sheet for the CC1101 you will see what I mean. Basic things like
the status (MARCSTATE) register cannot be relied on, and there is not in
my opinion a satisfactory workaround. this wasn't fixed according to the
CC1101 errata when I last looked, so has probably crawled over into the
CC430. Also you ask about PC AI's and DLL's. Ti are very slow to get off
the mark with support for their newest stuff, normally. this device
family has been trumpeted loudly for some time, but I can't see much in
the way of a dev kit or even application notes for it. I have no doubt
that these will come, and when they do they will be great if you want to
stick to basic stuff. But I've found that if you want tyo do something
even remotely off the beaten track you are on your own.

When the CC1100 was new I couldn't even get an answer from Ti on the
best way to match the antenna for use in differential mode. It strikes
me as odd that most of these single chip transceivers have a
differential output yet all the reference designs have matching circuits
for a single ended antenna.

In the end I went away from the Ti Rf stuff.

So will Ti correct the bugs? Probably not. Are they a huge problem? For
those who have gotten used to them no, for those who are doing mostly
mundane stuff, probably not, for those pushing the envelope a little,
yes, they might be.

Will TI correct all the errata in ther 6137? Likely not, since the 149
and a lot of earlier parts still have many bugs that are 10 years old,
and many newer parts have inherited these. Again this isn't a problem if
you are aware of them, and there is probably not a single device of any
complexity out there that doesn't have some bugs buried inside it.
personally I still think the MSP430 is one of the best micros on the
market. I haven't found a need to go to another family yet. there was an
argument sometime ago about whether it was worth using if the
application didin't require low power consumption. My personal response
is that EVERY application should be made to consume as little power as
possible, but that's another pulpit to preach from! Suffice to say were
the PC world to adopt efficient coding techniques and effcient energy
managemtn design it would be the same as taking 30 million cars off the
road in terms of the environmental impact, but even Al gore doesn't get it!

Don't think the 2274 is in any way limited. I have a data logger that
includes the following:-

RF transceiver
temp sensor
pressure sensor
humidity sensor
GPS
3D accelerometer
3D mag field sensor
3D gyro
16M external memory
LEDs
optical sensors
remote reprogramming
UART for hardware mission upload/download if required
and an optional 64k colour LCD

it has plenty of spare memory and spare pins

At the other extreme I have a wireless data logger that measures 11.4mm
square which uses an mSP430F2131 and the CC1100 it has a range of at
least 130mtr indoors using a simple 0.8mm copper wire loop antenna
folded back over the PCB, and includes a motion sensor, optical sensor,
LEDs, and a TACT switch. There is a picture of this in my piccies folder
on the group site if you're interested

http://d.yimg. com/kq/groups/ 2342629/sn/ 1133855661/ name/n_a

Currently I am using the Nordic nRF24L01P for some designs, as I like
the level of automation and the 6 receive channel addresses. There is
absolutely minimal CPU overhead. It adds a lot of flexibility. It also
has good range considering its a 2.4Ghz low power device, with a high
data rate, and not quite as good sensitivity as some devices. It can
also operate with a fairly poor quality crystal, surprisingly enough,
although I don't chance that! Although a bit bulkier than the circuit
for the Nordic, and not quite as flexible, or as automated as the Nordic
stuff the Microchip MRF24J40MA/B is also a very nice part, and I have
tested it's LOS range to up to 400mtr, although its bulk means I'm
currently not using it in any designs. Finally I also source some
semi-custom parts from Asia, that pack the entire circuit into a smaller
area than the Nordic IC, which itself is only 4x4mm., so it may be worth
hunting around there before you commit.

Cheers for now

Al

Michael Malone wrote:
> Hi Al.
>
> Can I call you Al?
>
> Actually I suppose it was the other way around. I came to programming
> languages via the uC. I still remember _way_ back when men were men
> and sheep were frightened. Back then the 8080 and the 6800 were just
> having children (not together AFAIK - that would have produced
> interesting offspring). I got to play a little with the 8085 and the
> 6502 (a Rockwell variant of the 6802 IIRC). I still remember that 31
> c2 20 was the machine code to initialise the stack at 0x20c2 on the
> 8085. Ah, those were the days!
>
> Time passes. A lot of time has passed, perhaps far too much since
> then. Electronics was my first love and it is past time I repaid her
> a visit.
>
> I have taken a quick look at the ez430-2500. It looks nice too. It
> uses the MSP430f2274. This part is somewhat limited in capability
> compared to the MSP430f6137. This doesn't matter much now but might
> limit my learning later on. Ah, decisions, decisions! You refer to
> certain problems with the CC430f6137. Are these problems related
> solely to the wireless side - the CC1101? Are TI working to resolve
> these problems or will the product remain substantially as is? In
> other words, if I wait a while would the CC4306137 then become a more
> viable option?
>
> When you say TI have the 'PC code', do you mean that there are APIs
> available to allow a Windows front-end to be developed or do you mean
> that there is code for the PC development of the end device, i.e.
> using a PC based development platform to create code for the end
> device?
>
> The MSP family user guide makes a lot of the low power modes and that
> integrated devices such as ADCs and DMA can operate independent of
> the CPU and when the device is in a low power mode. So, for instance,
> the ADC can operate independently of the CPU and when it had
> completed a conversion it can cause an interrupt and wake-up the CPU.
> After the CPU has finished it will re-enter the low power mode.
> However there doesn't seem to be a similar capability to count events
> at a pin. Perhaps I missed something?
>
> Also I see that the DMA can handle a transfer to the IIC interface.
> And the IIC interface can request new data from the DMA controller
> when it requires it. As I understood, or mis-understood, it all this
> can happen with the device in a low power mode. There is no mention
> of such a capability with the SPI interface. Again perhaps I missed
> something?
>
> Thanks for your reply, Al. This gives me a lot to mull over.
>
> Take care.
>
> Mike
>
>
>
> ____________ _________ _________ __ From: OneStone
> <onestone@bigpond. net.au> To: msp430@yahoogroups. com Sent: Monday,
> August 3, 2009 4:23:35 PM Subject: Re: [msp430] Introduction and
> Queries
>
>
> Hi Mike. Your brain has been polluted by having come to
> micro-controllers by way of programming languages such as C. Better
> to have come to them via hardware, from which direction they appear
> simpler, and more rational. C is a language of abstraction.
> Micro-controllers deal with hard facts and the real world, and hence
> can't truly be divorced from them.
>
> A few personal observations, with the caveat that, although I have
> been in this industry for almost 40 years, and have been using C for
> most of them I am not a fan of C, or high level languages in general,
> on micro-controllers.
>
> I think a better place to start would be with the EZ430-2500 kit. It
> is simpler, and I believe easier to understand.
>
> Although I love the fact that finally there is an RF transceiver/
> micro combination that does NOT have an 8051 core, I'm not a fan of
> the CC1101. Too many bugs still, and far more complex than it needs
> to be to handle. I believe it should have been more tightly
> integrated into the micro than it was. This was a lazy job. The fact
> that it doesn't include USB also shows how poorly thought through
> their product chain has become, since the 5529 does have USB but no
> RF.
>
> 1. You can set up a small network with 2 EZ430-2500 kits modify the
> code and learn some useful stuff, then add your own sensors as you
> go. I think TI have the PC codes for these, and they are available. I
> roll my own.
>
> 2. Almost any micro can implement a pin event counter, look for clock
> type inputs in the data sheets, then study the user guide to find
> out how to configure them.
>
> 3. DMA can use any RAM (just about) as source or destination,
> including registers associated with peripherals like the UARTs and
> SPI. How much you really gain from using it for SPI is dubious in my
> opinion, since it is not a truly independent CPU, ie it still
> consumes clock cycles.
>
> Cheers
>
> Al
>
> solarquark wrote:
>> Hi All.
>>
>> My name is Mike and I, too, am a tech nut. I' sure there is a
>> 12-point program that you can help me with, but until then...
>>
>> I am new to the group but have been loitering here a little while.
>> I know very little about the MSP430 but am most anxious to learn.
>>
>> I used to read books about subject matters of interest to me
>> (C/C++, VB, and so on) but discovered that when I tried to complete
>> a project that there was some vital piece of information that had
>> been omitted from the book(s) concerned.
>>
>> So now I create 'realistic' projects - preferably something that
>> can be extended or built upon - and keep at it until that project
>> has been completed. I find this to be a far more successful means
>> of learning for me.
>>
>> And so I am formulating a project that I hope will teach me a lot
>> about the uCs in general and the MSP430 family in particular.
>>
>> I wish to create a data logger. Let us say that this data logger
>> will measure ambient temperature as a minimum and perhaps more
>> later. The data acquired will be transferred to a PC via a wireless
>> link.
>>
>> Seems like a simple spec, doesn't it :) (you can probably tell that
>> the madness set in a long time ago - I am assured that I was
>> relatively normal until I, figuratively speaking, met Kernigan and
>> Ritchie)
>>
>> The CC430f6137 seems like the ideal part for the job. It will also
>> allow me to extend myself later investigating such things as LCDs
>> and SPI and so on.
>>
>> Knowing nothing at all about wireless - I have the greatest
>> difficulty seting up the video recorder - SimpliciTI would seem to
>> be the place to start.
>>
>> I have some queries, and please forgive my ignorance. 1. SimpliciTI
>> Is it possible, by that I mean without having to invent something
>> new - to setup a wireless link from a CC430f6137 to a Windows PC?
>> In other words are there Windows APIs/DLLs that allow comms between
>> these? 2. MSP430 family As far as I can determine there is no
>> pin-event counter feature on these units. By that I mean that
>> signals into a particular pin cannot be counted except by use of
>> the CPU and code. Is this a correct interpretation of the docs? 3.
>> DMA As far as I can tell there is no DMA capability between memory
>> and SPI? Would this interpretation be correct?
>>
>> Again please forgive my almost total ignornace at this point. This
>> is a condition I intend to correct.
>>
>> Take care all.
>>
>> Mike
>>
>>
>>
>> ------------ --------- --------- ------
>>
>> To unsubscribe from the msp430 group, send an email to:
>> msp430-unsubscribe@ egroups.com
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------ --------- --------- ------
>
> To unsubscribe from the msp430 group, send an email to:
> msp430-unsubscribe@ egroups.com
>
> Yahoo! Groups Links
>
>
>






[Non-text portions of this message have been removed]

So many suggesting to investigate.  Great forum!  Apologies for all the
clarification required - I have fairly weak knowledge of the MSP and have
inherited this problem.

To clarify my original post.  The device does have a save on power loss
which I have temporarily removed to debug this problem - leaving only the
single function thats saves setting on user interaction.  The password
protection on the flash write function is a good idea - esp if, as some
suggest, the PC can go AWOL during power fluctuations.

The MSP is the 437F and has SVS.  SVS is used to detect voltages below 2.75V
before flash writes.  Can it be used to actually prevent code start below a
certain voltage?  MSP runs at 6Mhz which will obviously require a minimum
voltage?  The BOR is set as default.  The compiler is IAR and I am debugging
using a bench supply to mess with the voltage - it usually does not take
many simulated brownouts and/or power supply dropouts to cause the
corruption.



old_cow_yellow wrote:
>
> "Can the PC jump to random locations after loss of voltage or a brownout?"
>
> Yes, and worse things can happen too.
>
> Which MSP430 are you using?
>
> Is there a BOR feature? If so, do you ever change the BOR settings of BCS?
> When and under what condition?
>
> Is there a SVS feature? If so, do you use it and how?
>
> Did you have any other means to monitor Vcc?
>
> Most likely, the MSP430 "crashed" during brownout. Any seemingly
> irrational events can happen.
>
> --- In msp430@yahoogroups.com, jpottaway <jpottaway@...> wrote:
>>
>>
>> Thanks so much for you assistance.
>>
>> The problem has gotten even more bizarre.  I have determined that sudden
>> drops in voltage and/or repeated brownouts cause the flash corruption.  I
>> have a simple function that saves user settings to flash when requested -
>> this function never executes on startup and requires significant user
>> interaction to actually run.  However, when this function is compiled
>> into
>> the code and the voltage is randomly moved about corruption eventually
>> results but if it is commented out is does not?
>>
>> Can the PC jump to random locations after loss of voltage or a brownout?
>> There simply is no execution path that could possibly get to the flash
>> write
>> function during startup/voltage fail when there has been no other
>> interaction with the device?
>>
>> Very confused.
>>
>> Jon
>>
>>
>> Onestone-2 wrote:
>> >
>> > Depenidng upon the amount of data you need to store I use a cyclic
>> > store. using this method I have a device which stores time every
>> minute.
>> > they have been in use for over 10 years without a single report of
>> flash
>> > corruption or exhaustion. You will need a routine to detect the next
>> > free address in your buffer, but that's quite easy.
>> >
>> > Cheers
>> >
>> > Al
>> >
>> > jpottaway wrote:
>> >> Thanks guys,
>> >>
>> >> I think you have placed me on the right track.  I have determined
>> there
>> >> is a
>> >> slight chance that Vcc could drop during an INFO memory write (battery
>> >> operated device).  It was just curious as to why this would wipe the
>> >> reset
>> >> vector given info memory is in a completely separate location/block.
>> >> Your
>> >> idea of the write continuing along the reset vector is interesting.
>> At
>> >> the
>> >> core I think the lesson is that if power drops during a flash write
>> the
>> >> results are unpredictable!
>> >>
>> >> Jon
>> >>
>> >>
>> >>
>> >> Onestone-2 wrote:
>> >>> This would suggest that in the middle of a flash write the power has
>> >>> fallen below threshhold, a POR has been generated, but somehow the
>> flash
>> >>> write has continued using the reset fetch vector. I've never seen
>> this,
>> >>> just thinking out loud. I never attempt to save on power down for
>> this
>> >>> reason. If the data is urgent save it while power is secure. There
>> are
>> >>> plenty of ways around this.
>> >>>
>> >>> Al
>> >>>
>> >>> jpottaway wrote:
>> >>>> Hi all.
>> >>>>
>> >>>> I have a MSP430 project which has been on commercial production for
>> a
>> >>>> few
>> >>>> years.  However in the most recent batch we have been getting a
>> number
>> >>>> of
>> >>>> devices returned with apparent corruption.  Reprogramming fixes the
>> >>>> issue.
>> >>>>
>> >>>> On investigation of the corrupted devices it seems that the reset
>> >>>> vector
>> >>>> (FFFEh) has been corrupted and is 0000h instead of the 0080h it was
>> >>>> originally programmed as.  I am at a loss to explain it.  The only
>> >>>> flash
>> >>>> writing the firmware does is to the INFO areas when power is removed
>> to
>> >>>> preserve settings.
>> >>>>
>> >>>> Anyone seem something like this before?
>> >>>>
>> >>>> Thanks in advance,
>> >>>> Jon
>> >>>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>>
http://www.nabble.com/Interrupt-Vector-Table-Corruption-tp24750598p24785431.html
>> Sent from the MSP430 - Discuss mailing list archive at Nabble.com.
>>
>
>
>
>

--
View this message in context:
http://www.nabble.com/Interrupt-Vector-Table-Corruption-tp24750598p24799945.html
Sent from the MSP430 - Discuss mailing list archive at Nabble.com.