gdb-loop in Mspdebug

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

gdb-loop in Mspdebug

Andrew McLaren
I'm running Mspdebug outboard of Eclipse. In the old gdbproxy, once I set
this listening on its input port, it remained active until it was explicitly
stopped. With Mspdebug, if the debug session is stopped in Eclipse, Mspdebug
returns to its [mspdebug] prompt, and the "gdb [port]" command needs to be
reissued before it is again usable.
 
>From the documentation it appears that the gdb-loop option should be the
magic required to keep this active. However I've had no luck getting this to
work. This indicates it should have a boolean value, and have tried a number
of variations, all with no apparent effect. Options I have tried are;
 
gdb <port> opt gdb-loop
gdb <port> opt gdb-loop 1
gdb <port> opt gdb-loop true
 
plus tried adding these directly to the startup command line.
 
Am I reading this correctly?
 
Thanks - Andrew

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: gdb-loop in Mspdebug

Daniel Beer-3
On Mon, Nov 04, 2013 at 04:21:56PM +1300, Andrew McLaren wrote:

> I'm running Mspdebug outboard of Eclipse. In the old gdbproxy, once I set
> this listening on its input port, it remained active until it was explicitly
> stopped. With Mspdebug, if the debug session is stopped in Eclipse, Mspdebug
> returns to its [mspdebug] prompt, and the "gdb [port]" command needs to be
> reissued before it is again usable.
>  
> >From the documentation it appears that the gdb-loop option should be the
> magic required to keep this active. However I've had no luck getting this to
> work. This indicates it should have a boolean value, and have tried a number
> of variations, all with no apparent effect. Options I have tried are;
>  
> gdb <port> opt gdb-loop
> gdb <port> opt gdb-loop 1
> gdb <port> opt gdb-loop true
>  
> plus tried adding these directly to the startup command line.
>  
> Am I reading this correctly?

Hi Andrew,

"opt" is a command on its own, and the option you want is "gdb_loop".
Try adding this to your ~/.mspdebug file:

    opt gdb_loop true

Cheers,
Daniel

--
Daniel Beer <[hidden email]>    www.dlbeer.co.nz
IRC: inittab (Freenode)    PGP key: 2048D/160A553B

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: gdb-loop in Mspdebug

Eric Decker
In reply to this post by Andrew McLaren
it is gdb_loop not gdb-loop      under vs. dash.

ouch.

took me a while to see it.



On Sun, Nov 3, 2013 at 7:21 PM, Andrew McLaren <[hidden email]> wrote:

> I'm running Mspdebug outboard of Eclipse. In the old gdbproxy, once I set
> this listening on its input port, it remained active until it was
> explicitly
> stopped. With Mspdebug, if the debug session is stopped in Eclipse,
> Mspdebug
> returns to its [mspdebug] prompt, and the "gdb [port]" command needs to be
> reissued before it is again usable.
>
> >From the documentation it appears that the gdb-loop option should be the
> magic required to keep this active. However I've had no luck getting this
> to
> work. This indicates it should have a boolean value, and have tried a
> number
> of variations, all with no apparent effect. Options I have tried are;
>
> gdb <port> opt gdb-loop
> gdb <port> opt gdb-loop 1
> gdb <port> opt gdb-loop true
>
> plus tried adding these directly to the startup command line.
>
> Am I reading this correctly?
>
> Thanks - Andrew
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> Mspgcc-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>

--
Eric B. Decker
Senior (over 50 :-) Researcher

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: gdb-loop in Mspdebug

Andrew McLaren
In reply to this post by Daniel Beer-3
Thanks Daniel and Eric.

All working, and another (little) frustration removed.

Just out of curiousity, what home location does Mspdebug pick up its
.mspdebug init file from on XP? It doesn't appear to be the normal
UserProfile (C:\Documents and Settings\<user>). It works fine putting this
in my working directory, which is perfect for what I need.

Regards

Andrew

-----Original Message-----
From: Daniel Beer [mailto:[hidden email]]
Sent: Monday, 4 November 2013 4:35 p.m.
To: Andrew McLaren
Cc: [hidden email]
Subject: Re: [Mspgcc-users] gdb-loop in Mspdebug


On Mon, Nov 04, 2013 at 04:21:56PM +1300, Andrew McLaren wrote:

> I'm running Mspdebug outboard of Eclipse. In the old gdbproxy, once I
> set this listening on its input port, it remained active until it was
> explicitly stopped. With Mspdebug, if the debug session is stopped in
> Eclipse, Mspdebug returns to its [mspdebug] prompt, and the "gdb
> [port]" command needs to be reissued before it is again usable.
>  
> >From the documentation it appears that the gdb-loop option should be
> >the
> magic required to keep this active. However I've had no luck getting
> this to work. This indicates it should have a boolean value, and have
> tried a number of variations, all with no apparent effect. Options I
> have tried are;
>  
> gdb <port> opt gdb-loop
> gdb <port> opt gdb-loop 1
> gdb <port> opt gdb-loop true
>  
> plus tried adding these directly to the startup command line.
>  
> Am I reading this correctly?

Hi Andrew,

"opt" is a command on its own, and the option you want is "gdb_loop". Try
adding this to your ~/.mspdebug file:

    opt gdb_loop true

Cheers,
Daniel

--
Daniel Beer <[hidden email]>    www.dlbeer.co.nz
IRC: inittab (Freenode)    PGP key: 2048D/160A553B


------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: gdb-loop in Mspdebug

Daniel Beer-3
On Tue, Nov 05, 2013 at 12:41:12PM +1300, Andrew McLaren wrote:
> Thanks Daniel and Eric.
>
> All working, and another (little) frustration removed.
>
> Just out of curiousity, what home location does Mspdebug pick up its
> .mspdebug init file from on XP? It doesn't appear to be the normal
> UserProfile (C:\Documents and Settings\<user>). It works fine putting this
> in my working directory, which is perfect for what I need.

Hi Andrew,

If you set the HOME environment variable, mspdebug will look for a
.mspdebug file there. However, the current working directory takes
precedence.

Cheers,
Daniel

--
Daniel Beer <[hidden email]>    www.dlbeer.co.nz
IRC: inittab (Freenode)    PGP key: 2048D/160A553B

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

LPM3 seems to interfere with MSP's ability to restart

Andrew McLaren
I'm seeing a bit of a weird situation that I don't really understand. I
suspect it will be something simple (hopefully just a 'dumb user error'!).
It affects the ability of the debugger to reload/restart code following an
LPM3 state.

I've been able to reduce the logic to simply the command that triggers the
LPM3 state (I'm using C, so its just the LPM3 macro). As expected, the
command drops the MSP into lpm3, and the logic promptly hangs (there is
nothing there to exit this). This is running via mspdebug under Eclipse, so
if I pause the logic, I'll see that it is indeed sitting at the LPM3
instruction.

If I terminate this and reload the code, all appears normal (the write/read
messages from mspdebug as it erases and reloads the code seem normal).
However, when the code is restarted, it appears to hang somewhere - it never
reaches the LPM3 instruction. This appears to have left the target MSP in
some sort of indeterminate state, and haven't found any way of retrieving it
other than power cycling the target. If I simply restart mspdebug, it
reports the following (this is using the TI FET, but have also tried an
Olimex JTAG-TINY with the same end result).

TI3140 device is in boot config, setting active
Ti3140: TI_OPEN_PORT failed: A device attached to the system is not
functioning.
Ti3140: failed to set up port

I guess mspdebug is having issues communicating, and the problem is out with
the target msp. Powering the target MSP off and on clears the problem, but
haven't found anything else that does.

While the above is obviously contrived, many MSP's live most of their lives
in LP states, and LPM3 is possibly the most common of these. Any reload of
code while debugging is highly likely to be from something like LPM3, so
have to believe its something I'm doing. Any ideas?

Andrew


------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: LPM3 seems to interfere with MSP's ability to restart

Valentin Sawadski-4
Hi

I'm not sure if it is directy related to your issue but one thing I noticed
when debugging targets with MSPGCC is the following.

My program is using Timer A and directly after programming the MSP with
mspdebug the Timer A is not starting up. It is simply not counting. I have
to powercycle the board to have it operate correctly. This happens every
time I program the MSP. Are you by any chance also using Timer A?

Btw have you tried to evaluate the program counter to see where it is stuck?

Best,
Valentin


On Thu, Nov 21, 2013 at 12:51 AM, Andrew McLaren <[hidden email]>wrote:

> I'm seeing a bit of a weird situation that I don't really understand. I
> suspect it will be something simple (hopefully just a 'dumb user error'!).
> It affects the ability of the debugger to reload/restart code following an
> LPM3 state.
>
> I've been able to reduce the logic to simply the command that triggers the
> LPM3 state (I'm using C, so its just the LPM3 macro). As expected, the
> command drops the MSP into lpm3, and the logic promptly hangs (there is
> nothing there to exit this). This is running via mspdebug under Eclipse, so
> if I pause the logic, I'll see that it is indeed sitting at the LPM3
> instruction.
>
> If I terminate this and reload the code, all appears normal (the write/read
> messages from mspdebug as it erases and reloads the code seem normal).
> However, when the code is restarted, it appears to hang somewhere - it
> never
> reaches the LPM3 instruction. This appears to have left the target MSP in
> some sort of indeterminate state, and haven't found any way of retrieving
> it
> other than power cycling the target. If I simply restart mspdebug, it
> reports the following (this is using the TI FET, but have also tried an
> Olimex JTAG-TINY with the same end result).
>
> TI3140 device is in boot config, setting active
> Ti3140: TI_OPEN_PORT failed: A device attached to the system is not
> functioning.
> Ti3140: failed to set up port
>
> I guess mspdebug is having issues communicating, and the problem is out
> with
> the target msp. Powering the target MSP off and on clears the problem, but
> haven't found anything else that does.
>
> While the above is obviously contrived, many MSP's live most of their lives
> in LP states, and LPM3 is possibly the most common of these. Any reload of
> code while debugging is highly likely to be from something like LPM3, so
> have to believe its something I'm doing. Any ideas?
>
> Andrew
>
>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up
> now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> Mspgcc-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>


--
Valentin Sawadski
Founder & Head of Embedded Software

Tel.: +49 - (0) 89 - 416 15 66 4 - 5
Fax: +49 - (0) 89 - 416 15 66 4 - 9
Mobil: +49 - (0) 162 - 460 163 4
www.tado.com
www.facebook.com/tado.com
www.twitter.com/tado

tado.com ist ein Angebot der tado° GmbH

tado° GmbH | Lindwurmstr. 76 | 80337 München
Geschäftsführer: Christian Deilmann | Johannes Schwarz | Leopold v. Bismarck
Eingetragen beim Amtsgericht München, HRB 194769 B | Ust.-ID Nr. DE
280012558

VERTRAULICHKEITSHINWEIS: Diese Nachricht ist vertraulich. Sie darf
ausschließlich durch den vorgesehenen Empfänger und Adressaten
gelesen, kopiert oder genutzt werden. Sollten Sie diese Nachricht
versehentlich erhalten haben, bitten wir, den Absender (durch
Antwort-E-Mail) hiervon unverzüglich zu informieren und die Nachricht
zu löschen. Jede Nutzung oder Weitergabe des Inhalts dieser Nachricht
ist unzulässig.

CONFIDENTIALITY NOTICE: This message (including any attachments) is
confidential and may be privileged. It may be read, copied and used
only by the intended recipient. If you have received it in error
please contact the sender (by return e-mail) immediately and delete
this message. Any unauthorized use or dissemination of this message in
whole or in part is strictly prohibited.

**Please consider the environment before printing this e-mail**

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: LPM3 seems to interfere with MSP's ability to restart

Andrew McLaren
In reply to this post by Andrew McLaren
I'll plug Valentin's response in below, as it's got tied to my erroneous
post (I always thought this was keyed on the message title, but seems to be
more than that?).
 
In the test code I was running, I was literally doing nothing more than the
bare minimum I needed to do to get the MSP running (disabling the watchdog,
waiting for its oscillator to stabilise), then dropping it into an LPM3
state. None of the timers where operational (unless their registers were not
initialised disabled, as I'd expect). Maybe there are multiple 'wait' states
that a reload can't totally recover from. Haven't any idea if this is
mspdebug related or not.
 
Re the PC question, since mspdebug can't communicate with the target
processor, its in no position to retrieve any context of what the target is
doing. I'm assuming anything trying to access via the JTAG is going to have
the same problem (unless this is somehow mspdebug specific?)
 
Andrew
 

From: Valentin Sawadski [mailto:[hidden email]]
Sent: Sunday, 24 November 2013 1:30 a.m.
To: [hidden email]
Cc: [hidden email]
Subject: Re: [Mspgcc-users] LPM3 seems to interfere with MSP's ability to
restart


Hi

I'm not sure if it is directy related to your issue but one thing I noticed
when debugging targets with MSPGCC is the following.

My program is using Timer A and directly after programming the MSP with
mspdebug the Timer A is not starting up. It is simply not counting. I have
to powercycle the board to have it operate correctly. This happens every
time I program the MSP. Are you by any chance also using Timer A?

Btw have you tried to evaluate the program counter to see where it is stuck?

Best,
Valentin
 

-----Original Message-----
From: Andrew McLaren [mailto:[hidden email]]
Sent: Thursday, 21 November 2013 1:13 p.m.
To: '[hidden email]'
Subject: LPM3 seems to interfere with MSP's ability to restart


Seemed to have managed to post this as a reply to another thread... Should
be here on its own!
 
I'm seeing a bit of a weird situation that I don't really understand. I
suspect it will be something simple (hopefully just a 'dumb user error'!).
It affects the ability of the debugger to reload/restart code following an
LPM3 state.

I've been able to reduce the logic to simply the command that triggers the
LPM3 state (I'm using C, so its just the LPM3 macro). As expected, the
command drops the MSP into lpm3, and the logic promptly hangs (there is
nothing there to exit this). This is running via mspdebug under Eclipse, so
if I pause the logic, I'll see that it is indeed sitting at the LPM3
instruction.

If I terminate this and reload the code, all appears normal (the write/read
messages from mspdebug as it erases and reloads the code seem normal).
However, when the code is restarted, it appears to hang somewhere - it never
reaches the LPM3 instruction. This appears to have left the target MSP in
some sort of indeterminate state, and haven't found any way of retrieving it
other than power cycling the target. If I simply restart mspdebug, it
reports the following (this is using the TI FET, but have also tried an
Olimex JTAG-TINY with the same end result).

TI3140 device is in boot config, setting active

Ti3140: TI_OPEN_PORT failed: A device attached to the system is not
functioning.

Ti3140: failed to set up port

I guess mspdebug is having issues communicating, and the problem is out with
the target msp. Powering the target MSP off and on clears the problem, but
haven't found anything else that does.

While the above is obviously contrived, many MSP's live most of their lives
in LP states, and LPM3 is possibly the most common of these. Any reload of
code while debugging is highly likely to be from something like LPM3, so
have to believe its something I'm doing. Any ideas?

Andrew


------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: LPM3 seems to interfere with MSP's ability to restart

Valentin Sawadski-4
And is there anything in the errata sheet? I remember once coming across an
errata where the device would not wake up from LPM if the interrupt is
triggered a few clock cycles after the LPM instruction.


On Mon, Nov 25, 2013 at 11:38 PM, Andrew McLaren <[hidden email]>wrote:

> I'll plug Valentin's response in below, as it's got tied to my erroneous
> post (I always thought this was keyed on the message title, but seems to be
> more than that?).
>
> In the test code I was running, I was literally doing nothing more than the
> bare minimum I needed to do to get the MSP running (disabling the watchdog,
> waiting for its oscillator to stabilise), then dropping it into an LPM3
> state. None of the timers where operational (unless their registers were
> not
> initialised disabled, as I'd expect). Maybe there are multiple 'wait'
> states
> that a reload can't totally recover from. Haven't any idea if this is
> mspdebug related or not.
>
> Re the PC question, since mspdebug can't communicate with the target
> processor, its in no position to retrieve any context of what the target is
> doing. I'm assuming anything trying to access via the JTAG is going to have
> the same problem (unless this is somehow mspdebug specific?)
>
> Andrew
>
>
> From: Valentin Sawadski [mailto:[hidden email]]
> Sent: Sunday, 24 November 2013 1:30 a.m.
> To: [hidden email]
> Cc: [hidden email]
> Subject: Re: [Mspgcc-users] LPM3 seems to interfere with MSP's ability to
> restart
>
>
> Hi
>
> I'm not sure if it is directy related to your issue but one thing I noticed
> when debugging targets with MSPGCC is the following.
>
> My program is using Timer A and directly after programming the MSP with
> mspdebug the Timer A is not starting up. It is simply not counting. I have
> to powercycle the board to have it operate correctly. This happens every
> time I program the MSP. Are you by any chance also using Timer A?
>
> Btw have you tried to evaluate the program counter to see where it is
> stuck?
>
> Best,
> Valentin
>
>
> -----Original Message-----
> From: Andrew McLaren [mailto:[hidden email]]
> Sent: Thursday, 21 November 2013 1:13 p.m.
> To: '[hidden email]'
> Subject: LPM3 seems to interfere with MSP's ability to restart
>
>
> Seemed to have managed to post this as a reply to another thread... Should
> be here on its own!
>
> I'm seeing a bit of a weird situation that I don't really understand. I
> suspect it will be something simple (hopefully just a 'dumb user error'!).
> It affects the ability of the debugger to reload/restart code following an
> LPM3 state.
>
> I've been able to reduce the logic to simply the command that triggers the
> LPM3 state (I'm using C, so its just the LPM3 macro). As expected, the
> command drops the MSP into lpm3, and the logic promptly hangs (there is
> nothing there to exit this). This is running via mspdebug under Eclipse, so
> if I pause the logic, I'll see that it is indeed sitting at the LPM3
> instruction.
>
> If I terminate this and reload the code, all appears normal (the write/read
> messages from mspdebug as it erases and reloads the code seem normal).
> However, when the code is restarted, it appears to hang somewhere - it
> never
> reaches the LPM3 instruction. This appears to have left the target MSP in
> some sort of indeterminate state, and haven't found any way of retrieving
> it
> other than power cycling the target. If I simply restart mspdebug, it
> reports the following (this is using the TI FET, but have also tried an
> Olimex JTAG-TINY with the same end result).
>
> TI3140 device is in boot config, setting active
>
> Ti3140: TI_OPEN_PORT failed: A device attached to the system is not
> functioning.
>
> Ti3140: failed to set up port
>
> I guess mspdebug is having issues communicating, and the problem is out
> with
> the target msp. Powering the target MSP off and on clears the problem, but
> haven't found anything else that does.
>
> While the above is obviously contrived, many MSP's live most of their lives
> in LP states, and LPM3 is possibly the most common of these. Any reload of
> code while debugging is highly likely to be from something like LPM3, so
> have to believe its something I'm doing. Any ideas?
>
> Andrew
>
>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up
> now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> Mspgcc-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>

--
Valentin Sawadski
Founder & Head of Embedded Software

Tel.: +49 - (0) 89 - 416 15 66 4 - 5
Fax: +49 - (0) 89 - 416 15 66 4 - 9
Mobil: +49 - (0) 162 - 460 163 4


facebook.com/tado<http://www.google.com/url?q=http%3A%2F%2Ffacebook.com%2Ftado&sa=D&sntz=1&usg=AFrqEzcXsXBuNZnoI7i7O22YPtGSE1LCVg>
 | twitter.com/tado<http://www.google.com/url?q=http%3A%2F%2Ftwitter.com%2Ftado&sa=D&sntz=1&usg=AFrqEzeG-3hEUnpKEGOrasN1nAT7-QJXPA>
|
youtube.com/tado

<http://www.google.com/url?q=http%3A%2F%2Fwww.tado.com%2F&sa=D&sntz=1&usg=AFrqEzdlGA-41vPiKHbUfSyHgdnCwXCWcA>

www.tado.com<http://www.google.com/url?q=http%3A%2F%2Fwww.tado.com%2F&sa=D&sntz=1&usg=AFrqEzdlGA-41vPiKHbUfSyHgdnCwXCWcA>|
tado° GmbH | Lindwurmstr. 76 | 80337 Munich | Germany

Managing Directors: Christian Deilmann | Johannes Schwarz | Leopold v.
Bismarck
Registered with the Commercial Register Munich as HRB 194769 B | VAT-No: DE
280012558

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users