Sign in
Search msp430
Subscribe to msp430
Ads
Discussion Groups
See Also
Discussion Groups | MSP430 | Weird behaviour of I/O on F5438
The purpose of this group is to foster exchange of information on the Texas Instruments MSP430 family of microcontrollers and related tools. Everyone welcome, all levels of familiarity/expertise.
Weird behaviour of I/O on F5438 - Markus Schaub - Nov 3 13:45:17 2009
Hi,
I observed a rather strange behaviour on the I/Os with a MSP430F5438 on
an F5438 experimenters board. I had some code running on the device that
enabled on of the boards LEDs. After removing the debugging code that
switched on the LED I tried to run the code on the MCU expecting that the
LED now would stay off. However, it didn't. After every reset the LED
switched immediately on again. Then, after switching off the boards power
supply and switching it on again it suddenly worked like expected.
Can anybody explain me what happened?
Regards,
Markus
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
I observed a rather strange behaviour on the I/Os with a MSP430F5438 on
an F5438 experimenters board. I had some code running on the device that
enabled on of the boards LEDs. After removing the debugging code that
switched on the LED I tried to run the code on the MCU expecting that the
LED now would stay off. However, it didn't. After every reset the LED
switched immediately on again. Then, after switching off the boards power
supply and switching it on again it suddenly worked like expected.
Can anybody explain me what happened?
Regards,
Markus
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: Weird behaviour of I/O on F5438 - old_cow_yellow - Nov 3 14:12:45 2009
Based on your description, the behavior is not weird at all. Switching the power off and
then on does not have exactly the same effect as resetting the chip. Consequently, the
chip could behave differently.
After a reset, the contents of the RAM and a lot of the registers are unchanged, whereas after a power off-than-on cycle, the contents of the RAM and those registers are likely to change. If you code, intentionally or unintentionally, depends on the contents of the RAM or those registers, then your code is weird -- not the behavior of the chip.
If you code does not depend on those things then the chip is weird. The F5438 has a long list of known bug. But it is unlikely that you found a new bug.
--- In m...@yahoogroups.com, Markus Schaub wrote:
>
> Hi,
>
> I observed a rather strange behaviour on the I/Os with a MSP430F5438 on
> an F5438 experimenters board. I had some code running on the device that
> enabled on of the boards LEDs. After removing the debugging code that
> switched on the LED I tried to run the code on the MCU expecting that the
> LED now would stay off. However, it didn't. After every reset the LED
> switched immediately on again. Then, after switching off the boards power
> supply and switching it on again it suddenly worked like expected.
> Can anybody explain me what happened?
>
> Regards,
> Markus
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
After a reset, the contents of the RAM and a lot of the registers are unchanged, whereas after a power off-than-on cycle, the contents of the RAM and those registers are likely to change. If you code, intentionally or unintentionally, depends on the contents of the RAM or those registers, then your code is weird -- not the behavior of the chip.
If you code does not depend on those things then the chip is weird. The F5438 has a long list of known bug. But it is unlikely that you found a new bug.
--- In m...@yahoogroups.com, Markus Schaub
>
> Hi,
>
> I observed a rather strange behaviour on the I/Os with a MSP430F5438 on
> an F5438 experimenters board. I had some code running on the device that
> enabled on of the boards LEDs. After removing the debugging code that
> switched on the LED I tried to run the code on the MCU expecting that the
> LED now would stay off. However, it didn't. After every reset the LED
> switched immediately on again. Then, after switching off the boards power
> supply and switching it on again it suddenly worked like expected.
> Can anybody explain me what happened?
>
> Regards,
> Markus
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: Weird behaviour of I/O on F5438 - Markus Schaub - Nov 4 13:46:28 2009
old_cow_yellow schrieb:
>> I observed a rather strange behaviour on the I/Os with a MSP430F5438 on
>> an F5438 experimenters board. I had some code running on the device that
>> enabled on of the boards LEDs. After removing the debugging code that
>> switched on the LED I tried to run the code on the MCU expecting that the
>> LED now would stay off. However, it didn't. After every reset the LED
>> switched immediately on again. Then, after switching off the boards power
>> supply and switching it on again it suddenly worked like expected.
>> Can anybody explain me what happened?
>> Based on your description, the behavior is not weird at all. Switching the
> power off and then on does not have exactly the same effect as resetting the
> chip. Consequently, the chip could behave differently.
>
> After a reset, the contents of the RAM and a lot of the registers are
> unchanged, whereas after a power off-than-on cycle, the contents of the RAM
> and those registers are likely to change. If you code, intentionally or
> unintentionally, depends on the contents of the RAM or those registers, then
> your code is weird -- not the behavior of the chip.
I agree that a reset does not necessarily have the same effects as a power
cycle. However, after a power cycle there should always be a reset which should
set the I/O registers to their default state. But -- and that's the mistake I
made -- this is not the case for the PORTxOUT registers. Unlike the PORTxDIR and
the other I/O configuration registers, these are undefined.
Regards,
Markus
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
>> I observed a rather strange behaviour on the I/Os with a MSP430F5438 on
>> an F5438 experimenters board. I had some code running on the device that
>> enabled on of the boards LEDs. After removing the debugging code that
>> switched on the LED I tried to run the code on the MCU expecting that the
>> LED now would stay off. However, it didn't. After every reset the LED
>> switched immediately on again. Then, after switching off the boards power
>> supply and switching it on again it suddenly worked like expected.
>> Can anybody explain me what happened?
>> Based on your description, the behavior is not weird at all. Switching the
> power off and then on does not have exactly the same effect as resetting the
> chip. Consequently, the chip could behave differently.
>
> After a reset, the contents of the RAM and a lot of the registers are
> unchanged, whereas after a power off-than-on cycle, the contents of the RAM
> and those registers are likely to change. If you code, intentionally or
> unintentionally, depends on the contents of the RAM or those registers, then
> your code is weird -- not the behavior of the chip.
I agree that a reset does not necessarily have the same effects as a power
cycle. However, after a power cycle there should always be a reset which should
set the I/O registers to their default state. But -- and that's the mistake I
made -- this is not the case for the PORTxOUT registers. Unlike the PORTxDIR and
the other I/O configuration registers, these are undefined.
Regards,
Markus
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: Weird behaviour of I/O on F5438 - Michael - Nov 4 15:45:18 2009
But that means your code doesn't define the pin output level prior to defining that bit's
output state. Don't rely on the default state of any register when configuring it (make
the first operation an = instead of an |= or &= ), as a PUC will have the same unwanted
effect or worse (some IE bits are not reset by a PUC).
Regards,
Michael K.
--- In m...@yahoogroups.com, Markus Schaub wrote:
>
> old_cow_yellow schrieb:
> >> I observed a rather strange behaviour on the I/Os with a MSP430F5438 on
> >> an F5438 experimenters board. I had some code running on the device that
> >> enabled on of the boards LEDs. After removing the debugging code that
> >> switched on the LED I tried to run the code on the MCU expecting that the
> >> LED now would stay off. However, it didn't. After every reset the LED
> >> switched immediately on again. Then, after switching off the boards power
> >> supply and switching it on again it suddenly worked like expected.
> >> Can anybody explain me what happened?
> >> Based on your description, the behavior is not weird at all. Switching the
> > power off and then on does not have exactly the same effect as resetting the
> > chip. Consequently, the chip could behave differently.
> >
> > After a reset, the contents of the RAM and a lot of the registers are
> > unchanged, whereas after a power off-than-on cycle, the contents of the RAM
> > and those registers are likely to change. If you code, intentionally or
> > unintentionally, depends on the contents of the RAM or those registers, then
> > your code is weird -- not the behavior of the chip.
>
> I agree that a reset does not necessarily have the same effects as a power
> cycle. However, after a power cycle there should always be a reset which should
> set the I/O registers to their default state. But -- and that's the mistake I
> made -- this is not the case for the PORTxOUT registers. Unlike the PORTxDIR and
> the other I/O configuration registers, these are undefined.
>
> Regards,
> Markus
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Regards,
Michael K.
--- In m...@yahoogroups.com, Markus Schaub
>
> old_cow_yellow schrieb:
> >> I observed a rather strange behaviour on the I/Os with a MSP430F5438 on
> >> an F5438 experimenters board. I had some code running on the device that
> >> enabled on of the boards LEDs. After removing the debugging code that
> >> switched on the LED I tried to run the code on the MCU expecting that the
> >> LED now would stay off. However, it didn't. After every reset the LED
> >> switched immediately on again. Then, after switching off the boards power
> >> supply and switching it on again it suddenly worked like expected.
> >> Can anybody explain me what happened?
> >> Based on your description, the behavior is not weird at all. Switching the
> > power off and then on does not have exactly the same effect as resetting the
> > chip. Consequently, the chip could behave differently.
> >
> > After a reset, the contents of the RAM and a lot of the registers are
> > unchanged, whereas after a power off-than-on cycle, the contents of the RAM
> > and those registers are likely to change. If you code, intentionally or
> > unintentionally, depends on the contents of the RAM or those registers, then
> > your code is weird -- not the behavior of the chip.
>
> I agree that a reset does not necessarily have the same effects as a power
> cycle. However, after a power cycle there should always be a reset which should
> set the I/O registers to their default state. But -- and that's the mistake I
> made -- this is not the case for the PORTxOUT registers. Unlike the PORTxDIR and
> the other I/O configuration registers, these are undefined.
>
> Regards,
> Markus
>
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: Weird behaviour of I/O on F5438 - Markus Schaub - Nov 5 14:49:05 2009
Michael schrieb:
> But that means your code doesn't define the pin output level prior to defining
> that bit's output state.
Yes, that's true. At least for the debugging macro which enabled the LED on the
development board. I did a lot 8051 and AVR prior to my current MSP430 project
and am still learning about the differences between the architectures.
> Don't rely on the default state of any register when configuring it (make the
> first operation an = instead of an |= or &= ), as a PUC will have the same
> unwanted effect or worse (some IE bits are not reset by a PUC).
I generally do this when configuring the peripheral modules. It's the only way
to avoid unwanted states when you want to set and also reset some bits of a
register.
Regards,
Markus
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
> But that means your code doesn't define the pin output level prior to defining
> that bit's output state.
Yes, that's true. At least for the debugging macro which enabled the LED on the
development board. I did a lot 8051 and AVR prior to my current MSP430 project
and am still learning about the differences between the architectures.
> Don't rely on the default state of any register when configuring it (make the
> first operation an = instead of an |= or &= ), as a PUC will have the same
> unwanted effect or worse (some IE bits are not reset by a PUC).
I generally do this when configuring the peripheral modules. It's the only way
to avoid unwanted states when you want to set and also reset some bits of a
register.
Regards,
Markus
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )