Nabble - MSP430 gcc - Users

Re: Problem with sprintf and snprintf in a msp430x2617

2009-11-30T04:09:31Z

After reading your message once again, I stumbled over the words "debugbuf keeps the same information as if '...' was a null string"
IMHO if the format string is a null string, the destination buffer should contain a null string too and not 'keep the same' (except if it was a null string before already).

Anyway, if you just want to compy your constant text into debugbuf (this is what your code actually does), you can simply use strcpy() instead. Faster, smaller and much less stack usage. :)

JMGross

----- Ursprüngliche Nachricht -----
Von: Jordi Soucheiron
An: mspgcc-users@...
Gesendet am: 24 Nov 2009 13:54:25
Betreff: [Mspgcc-users] Problem with sprintf and snprintf in a msp430x2617

Hi,
I've been trying to fix a problem with my build of mspgcc but I got
out of ideas to fix it. Some time ago I used a build from july 2008
and everithing worked just fine, now I've switched to the last cvs
version and I've found out that sprintf for some reason doesn't write
to the destiny. I've tryed to exec this (this line is from the output
of a nesc precompiler):
snprintf(debugbuf, 256, " + Accelerometer Started\n");
But instead of moving the string to the debugbuf keeps the same
information just as if " + Accelerometer Started\n" was a null
string.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: Problem with sprintf and snprintf in a msp430x2617

2009-11-30T04:02:38Z

I just checked on my system (windows build from 12/08) and everything seems to be okay.
The source code for the printf function hasn't changed for 6 years.
The compiler seems to generate the proper call sequence. Fine.

But I noticed that the spaces in your code snipped are followed by an 0xa0 'shift-space'. Is this intentional?
Maybe the library code does what it should but your code handling the result chokes on the 0xa0?

Also, the s(n)printf function use static variables while working, so the code is not reentrant. You may not use it from within an ISR as this would mess up the output from the main loop.

JMGross

----- Ursprüngliche Nachricht -----
Von: Jordi Soucheiron

> snprintf(debugbuf, 256, " + Accelerometer Started\n");
> But instead of moving the string to the debugbuf keeps the same
> information just as if " + Accelerometer Started\n" was a null
> string.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: msp430x5529 support

2009-11-29T23:44:12Z

Hi Bernie,

we have created our headers based on the datasheet from texas instruments.
That means we don't define structs to configure a component. Instead we only
define the addresses according to their name inside the datasheet. After
reading your symbols it looks like you are using hungarian notation for your
code. You simply have to define the structs you are using to configure the
USB component and define a corresponding variable at the right place and
your code will compile.

Best regards,
Gerald

-----Ursprüngliche Nachricht-----
Von: Bernard Mentink [mailto:bmentink@...]
Gesendet: Mittwoch, 25. November 2009 07:57
An: GCC for MSP430 - http://mspgcc.sf.net
Betreff: Re: [Mspgcc-users] msp430x5529 support

On Tue, Nov 24, 2009 at 1:09 AM, Gerald Lutter
<g.lutter@...>wrote:

> Hi Bernie,
>
> we have updated our script on the webpage. It downloads the patches
> automatically and builds a new toolchain with it.
>
> Best regards,
> Gerald
>
>
>

Hi again Gerald,

Every thing compiles except for the following symbols (Code Composer link
file .. ) I can't seem to find any equivalent symbols in the USB.h file ..

It maybe that they are additional symbols introduced by the USB stack. If
that is the case can you give be some instruction on how I can introduce
them ..

Thanks,
Bernie

---------------------------------- Missing Symbols
-----------------------------

tSetupPacket = 0x2380;

tEndPoint0DescriptorBlock = 0x0920;

tInputEndPointDescriptorBlock = 0x23C8;

tOutputEndPointDescriptorBlock = 0x2388;

abIEP0Buffer = 0x2378;

abOEP0Buffer = 0x2370;

pbXBufferAddressEp1 = 0x1C00;

pbYBufferAddressEp1 = 0x1C40;

pbXBufferAddressEp81 = 0x1C80;

pbYBufferAddressEp81 = 0x1CC0;

pbXBufferAddressEp2 = 0x1D00;

pbYBufferAddressEp2 = 0x1D40;

pbXBufferAddressEp82 = 0x1D80;

pbYBufferAddressEp82 = 0x1DC0;

pbXBufferAddressEp3 = 0x1E00;
----------------------------------------

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

MSP430-JTAG-TINY programmer

2009-11-27T13:51:33Z

Has anyone any experience with using the Olimex MSP430-JTAG-TINY programmer
under Linux? Any tips on how to get it going would be greatly appreciated.
--
Rick Jenkins <rick@...>
Hartman Technica http://www.hartmantech.com
Phone +1 (403) 230-1987
221 35 Avenue. N.E., Calgary, Alberta, Canada T2E 2K5

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: Problem with sprintf and snprintf in a msp430x2617

2009-11-26T23:46:57Z

I've just tried with 255 with the same result than 256.

2009/11/26 Jordi Soucheiron <jsoucheiron@...>:

> I'll try it tomorrow, but anyway if I use sprintf(debugbuf, " +
> Accelerometer Started\n"); the behaviour is the same. Tomorrow I'll
> try to use 255 anyway, just in case.
>
> 2009/11/26 Przemek Klosowski <przemek.klosowski@...>:
>> On Thu, Nov 26, 2009 at 3:42 AM, Jordi Soucheiron <jsoucheiron@...
>>> wrote:
>>
>>> > snprintf(debugbuf, 256, " + Accelerometer Started\n");
>>> > But instead of moving the string to the debugbuf keeps the same
>>> > information just as if " + Accelerometer Started\n" was a null
>>> > string.
>>>
>>
>> Just on a lark---does the behavior change when you use 255 instead of 256 as
>> the maximum size in the snprintf() call? If that was the case, perhaps the
>> compiler treats that variable (which normally should be of the type size_t)
>> as uint8_t, truncating it to zero, which, if true, would explain the
>> behavior you see.
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Mspgcc-users mailing list
>> Mspgcc-users@...
>> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>>
>>
>
>
>
> --
> Jordi Soucheiron
> Software Engineer
>
> DEXMA
> Parc Tecnològic la Salle
> Sant Joan de la Salle, 42
> 08022 Barcelona
> t/f: [+34] 93 181 01 95
> www.dexmatech.com
> jsoucheiron@...
>

--
Jordi Soucheiron
Software Engineer

DEXMA
Parc Tecnològic la Salle
Sant Joan de la Salle, 42
08022 Barcelona
t/f: [+34] 93 181 01 95
www.dexmatech.com
jsoucheiron@...

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: Problem with sprintf and snprintf in a msp430x2617

2009-11-26T13:57:10Z

I'll try it tomorrow, but anyway if I use sprintf(debugbuf, " +
Accelerometer Started\n"); the behaviour is the same. Tomorrow I'll
try to use 255 anyway, just in case.

2009/11/26 Przemek Klosowski <przemek.klosowski@...>:

> On Thu, Nov 26, 2009 at 3:42 AM, Jordi Soucheiron <jsoucheiron@...
>> wrote:
>
>> > snprintf(debugbuf, 256, " + Accelerometer Started\n");
>> > But instead of moving the string to the debugbuf keeps the same
>> > information just as if " + Accelerometer Started\n" was a null
>> > string.
>>
>
> Just on a lark---does the behavior change when you use 255 instead of 256 as
> the maximum size in the snprintf() call? If that was the case, perhaps the
> compiler treats that variable (which normally should be of the type size_t)
> as uint8_t, truncating it to zero, which, if true, would explain the
> behavior you see.
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@...
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>

Re: Problem with sprintf and snprintf in a msp430x2617

2009-11-26T08:29:00Z

On Thu, Nov 26, 2009 at 3:42 AM, Jordi Soucheiron <jsoucheiron@...
> wrote:

> > snprintf(debugbuf, 256, " + Accelerometer Started\n");
> > But instead of moving the string to the debugbuf keeps the same
> > information just as if " + Accelerometer Started\n" was a null
> > string.
>

Just on a lark---does the behavior change when you use 255 instead of 256 as
the maximum size in the snprintf() call? If that was the case, perhaps the
compiler treats that variable (which normally should be of the type size_t)
as uint8_t, truncating it to zero, which, if true, would explain the
behavior you see.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: Problem with sprintf and snprintf in a msp430x2617

2009-11-26T00:42:14Z

I've been testing further and I've found out that the problem is also
present in the windows version of the compiler. I've tryed the current
image of the compiler and the snapshots from 20080619 20080605
20080603 and none of them work properly.
I've been able to rebuild the 2008 version I had and it's working, but
I would like to be able to use the last version. Does somebody know
were can I start looking to find the bug? I don't have the most remote
idea of where to start and the diff between the current version and
the one working is huge.

2009/11/24 Jordi Soucheiron <jsoucheiron@...>:

> Hi,
> I've been trying to fix a problem with my build of mspgcc but I got
> out of ideas to fix it. Some time ago I used a build from july 2008
> and everithing worked just fine, now I've switched to the last cvs
> version and I've found out that sprintf for some reason doesn't write
> to the destiny. I've tryed to exec this (this line is from the output
> of a nesc precompiler):
> snprintf(debugbuf, 256, " + Accelerometer Started\n");
> But instead of moving the string to the debugbuf keeps the same
> information just as if " + Accelerometer Started\n" was a null
> string.
> Does somebody know what could be causing this behavior? I suspect that
> may have something to do with the compiler used, but I cannot be sure
> Thank you
>
> --
> Jordi Soucheiron
> Software Engineer
>
> DEXMA
> Parc Tecnològic la Salle
> Sant Joan de la Salle, 42
> 08022 Barcelona
> t/f: [+34] 93 181 01 95
> www.dexmatech.com
> jsoucheiron@...
>

Re: Ubuntu Packages, Karmic, where did the source code go in Bazaar?

2009-11-25T06:53:21Z

Hi Chris,

Thanks for the detailed reply. I have packages called msp430-binutils,
msp430-gcc, msp430-libc, msp430-gdb. These work at present but due to
the gcc version required do not work on jaunty.

My plan of attack if you agree:

All patches are hosted on my server that are submitted, I get a copy of
these and produce a combined patch that keeps getting updated the more
patches that are submitted. This combined patch can work in my packages
plus other packages for other distributions. These combined patches are
kept in Bazaar again on my local server so we have a point to check when
what broke what in a commit. These combined patches would be the best
way to go forward without a release scheme as I can keep track of the
combined patch for the packaging. This combined patch would be checked
into Bazaar onto my server and in the commit log I will log how this
patch was created and where the individual patches came from.

This allows the packages to be created each day and we have some some of
quality checking progress built in to ensure the source is sane before
been built into packages.

So in Bazaar there is the mspgcc4 port. This port works with Karmic and
this is what I need to package to get Karmic support. I will take a look
at what is in Bazaar. As the code there compiled last night I can use
this in my packages. I will also look at combing the other patches as
well such as the ones that have appeared recently for the MSP430x5 and
usb support.

I will bring along more packages for the other tools but at the moment I
am just working on the core parts of the compiler.

When I said the internals, I more meant line for line of the source to
find out how you created the cross compiler. By understanding the source
I was hoping to be able to add new devices when required.

Thanks,

Adam

Chris Liechti wrote:

> Adam Horden schrieb:
>
>
>> The Bazaar code has been away for over a week now so I have turned off
>> my automatic package building for now. I do not have packages for karmic
>> as I did not know the state of the source code. What did happen to the
>> code in Bazaar?
>>
>
> good question... i don't know why the web interface sometimes gives
> error messages about revisions that never existed in the repo and
> sometimes show "no revisions". anyways i wiped the repo created a new
> shared repo and uploaded the branches again.
>
> you once asked about a way to list the branches. the following works now
> (but it is slow):
> $ bzr branches bzr://mspgcc.bzr.sourceforge.net/bzrroot/mspgcc
>
>
>> I am still working on packaging but at the same time I am trying to
>> understand some of the internals so I can better understand how the
>> cross compiler works.
>>
>
> hm. roughly these parts play together:
> Core parts:
> - cross assembler and tools (binutils)
> - cross compiler (gcc)
> - separate libraries for the target
> - msp430-libc (must have)
> - libmspgcc (optional)
> - there is also libgcc but that is included in the cross gcc
> Debugger:
> - cross debugger (gdb) (understanding the target processors asm etc,
> built in simulator..)
> Separate tools:
> - separate tools (msp430-jtag/bsl, ...)
> - other 3rd party tools not hosted with mspgcc
> - mspgcc docs and example code
> - "make" or some other build control tool, usually not dependent on
> target platform, so no cross versions needed here
>
> how to package this? that depends on how many packages you prefer. fine
> grained packaging could mean approximately a package per list item
> above. otherwise binutils, gcc, libc, libmspgcc together may make sense.
> docs+examples as an other package. gdb and gdbproxy maybe?
>
> i would package all the python tools separately (as one) as well as each
> other 3rd party tool as these are more or less independent of the
> compiler/assembler toolchain used an they may be us use for users of
> other toolchains.
>
> sorry if that wasn't what you asked about :-)
>
>
>>> As far as my understanding goes most of the compilation problems are
>>> caused by dependencies and interfaces with out-of-project code like the
>>> kernel, bin-utils, gcc, and the secret libhil.so / msp430.dll code.
>>>
>
> the libhil used by MSP430mspgcc is completely open source. and i think
> it was compatible to the HIL used by TI's MSP430. the APIs drifted away
> when they added spy-bi-wire support.
>
> The USB access code is built into the MSP430 library itself. but the
> complete library is closed source. that's TI's choice. not ours ;-)
> due to the licensing, gdbproxy was required and as it has to link about
> the "secret" MSP430 API it also has a closed source part. There were not
> made using reverse engineering but with the help from TI. so there is no
> option releasing these part without their consent.
>
> there should not be any other parts that are "secret" or depending or
> have difficult dependencies.
>
>
>>> I always wondered why all these interfaces are needed (and why
>>> hacks around the TI secret code were not already included ;-) ).
>>>
>
> one part is explained above.
>
>
>>>> So what is the state of the source code in Bazaar?
>>>>
>
> so far there are no new features in the bzr branch yet (except...)
> - the mspgcc4 fork was merged into the mspgcc-core branch. but the
> msp430X branch is still separate for gcc itself
> - i've tried to get it better structured and separate parts in separate
> branches.
> - the build shell script is derived from mspgcc4 (instead of the make
> variant i usually used from packaging)
> - i had problems getting a 4.x gcc cross compiler (issues with gcc not
> finding its own binaries, build itself seems to pass sucessfully)
> - windows installer files not yet present as i'd like to create a more
> fine grained packaging there too.
>
>
>>>> Now I asked for advice if this code in Bazaar would be ready for
>>>> packaging but never got a reply.
>>>>
>
> i myself feel responsible for the python-mspgcc-tools. and i plan to
> develop them in bzr.
>
> gcc, gdb and binutils are an other topic as the key contributors are
> other developers, several over time. they that want to work further on
> it have to be happy with the versioning system.
> so far the feedback has not been very positive in favor of bzr but on
> the other side, generally, going away from CVS would be preferred.
>
>
>>>> I also asked if it was possible to sort
>>>> out a release system and Rob Spanton agreed on this but nothing moved
>>>> forward. As a packager it gives me a headache tracking my own revision
>>>> numbers to a revision in Bazaar or CVS.
>>>>
>
> so far there have not been "hard" release points so i used dates for the
> windows installer. with finer grained packages that should get easier.
>
>
>>>> There are commits that break things from time to time so building them
>>>> each day is a bad idea. We need a release schedule. I have been there
>>>> with my packages and it requires human intervention as I have them
>>>> automatically built but for testing I have to update my development
>>>> machines packages versions then test them to ensure nothing broke before
>>>> uploading them to Launchpad.
>>>>
>
> a good point.
>
> currently there is no official plan for future features (they get
> included as someone provides patches/checks in).
>
> chris
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@...
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: msp430x5529 support

2009-11-24T22:57:04Z

On Tue, Nov 24, 2009 at 1:09 AM, Gerald Lutter <g.lutter@...>wrote:

> Hi Bernie,
>
> we have updated our script on the webpage. It downloads the patches
> automatically and builds a new toolchain with it.
>
> Best regards,
> Gerald
>
>
>

Hi again Gerald,

Every thing compiles except for the following symbols (Code Composer link
file .. )
I can't seem to find any equivalent symbols in the USB.h file ..

It maybe that they are additional symbols introduced by the USB stack. If
that is the case can you give be some instruction on how I can introduce
them ..

Thanks,
Bernie

---------------------------------- Missing Symbols
-----------------------------

tSetupPacket = 0x2380;

tEndPoint0DescriptorBlock = 0x0920;

tInputEndPointDescriptorBlock = 0x23C8;

tOutputEndPointDescriptorBlock = 0x2388;

abIEP0Buffer = 0x2378;

abOEP0Buffer = 0x2370;

pbXBufferAddressEp1 = 0x1C00;

pbYBufferAddressEp1 = 0x1C40;

pbXBufferAddressEp81 = 0x1C80;

pbYBufferAddressEp81 = 0x1CC0;

pbXBufferAddressEp2 = 0x1D00;

pbYBufferAddressEp2 = 0x1D40;

pbXBufferAddressEp82 = 0x1D80;

pbYBufferAddressEp82 = 0x1DC0;

pbXBufferAddressEp3 = 0x1E00;
----------------------------------------

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: msp430x5529 support

2009-11-24T16:23:41Z

On Tue, Nov 24, 2009 at 1:09 AM, Gerald Lutter <g.lutter@...>wrote:

> Hi Bernie,
>
> we have updated our script on the webpage. It downloads the patches
> automatically and builds a new toolchain with it.
>
> Best regards,
> Gerald
>
>
>

Hi Gerald,

Thanks for that. I had nearly got my version done, but you bet me to it.

Tried it out and compile seems to work fine.

I am busy porting across the TI USB CDC/HID and my MIDI stack (CCE code)
across to mspgcc ... nearly finished ...

Cheers,
Bernie

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: Ubuntu Packages, Karmic, where did the source code go in Bazaar?

2009-11-24T15:38:28Z

Adam Horden schrieb:

> The Bazaar code has been away for over a week now so I have turned off
> my automatic package building for now. I do not have packages for karmic
> as I did not know the state of the source code. What did happen to the
> code in Bazaar?

good question... i don't know why the web interface sometimes gives
error messages about revisions that never existed in the repo and
sometimes show "no revisions". anyways i wiped the repo created a new
shared repo and uploaded the branches again.

you once asked about a way to list the branches. the following works now
(but it is slow):
$ bzr branches bzr://mspgcc.bzr.sourceforge.net/bzrroot/mspgcc

> I am still working on packaging but at the same time I am trying to
> understand some of the internals so I can better understand how the
> cross compiler works.

hm. roughly these parts play together:
Core parts:
- cross assembler and tools (binutils)
- cross compiler (gcc)
- separate libraries for the target
- msp430-libc (must have)
- libmspgcc (optional)
- there is also libgcc but that is included in the cross gcc
Debugger:
- cross debugger (gdb) (understanding the target processors asm etc,
built in simulator..)
Separate tools:
- separate tools (msp430-jtag/bsl, ...)
- other 3rd party tools not hosted with mspgcc
- mspgcc docs and example code
- "make" or some other build control tool, usually not dependent on
target platform, so no cross versions needed here

how to package this? that depends on how many packages you prefer. fine
grained packaging could mean approximately a package per list item
above. otherwise binutils, gcc, libc, libmspgcc together may make sense.
docs+examples as an other package. gdb and gdbproxy maybe?

i would package all the python tools separately (as one) as well as each
other 3rd party tool as these are more or less independent of the
compiler/assembler toolchain used an they may be us use for users of
other toolchains.

sorry if that wasn't what you asked about :-)

>> As far as my understanding goes most of the compilation problems are
>> caused by dependencies and interfaces with out-of-project code like the
>> kernel, bin-utils, gcc, and the secret libhil.so / msp430.dll code.

the libhil used by MSP430mspgcc is completely open source. and i think
it was compatible to the HIL used by TI's MSP430. the APIs drifted away
when they added spy-bi-wire support.

The USB access code is built into the MSP430 library itself. but the
complete library is closed source. that's TI's choice. not ours ;-)
due to the licensing, gdbproxy was required and as it has to link about
the "secret" MSP430 API it also has a closed source part. There were not
made using reverse engineering but with the help from TI. so there is no
option releasing these part without their consent.

there should not be any other parts that are "secret" or depending or
have difficult dependencies.

>> I always wondered why all these interfaces are needed (and why
>> hacks around the TI secret code were not already included ;-) ).

one part is explained above.

>>> So what is the state of the source code in Bazaar?

so far there are no new features in the bzr branch yet (except...)
- the mspgcc4 fork was merged into the mspgcc-core branch. but the
msp430X branch is still separate for gcc itself
- i've tried to get it better structured and separate parts in separate
branches.
- the build shell script is derived from mspgcc4 (instead of the make
variant i usually used from packaging)
- i had problems getting a 4.x gcc cross compiler (issues with gcc not
finding its own binaries, build itself seems to pass sucessfully)
- windows installer files not yet present as i'd like to create a more
fine grained packaging there too.

>>> Now I asked for advice if this code in Bazaar would be ready for
>>> packaging but never got a reply.

i myself feel responsible for the python-mspgcc-tools. and i plan to
develop them in bzr.

gcc, gdb and binutils are an other topic as the key contributors are
other developers, several over time. they that want to work further on
it have to be happy with the versioning system.
so far the feedback has not been very positive in favor of bzr but on
the other side, generally, going away from CVS would be preferred.

>>> I also asked if it was possible to sort
>>> out a release system and Rob Spanton agreed on this but nothing moved
>>> forward. As a packager it gives me a headache tracking my own revision
>>> numbers to a revision in Bazaar or CVS.

so far there have not been "hard" release points so i used dates for the
windows installer. with finer grained packages that should get easier.

>>> There are commits that break things from time to time so building them
>>> each day is a bad idea. We need a release schedule. I have been there
>>> with my packages and it requires human intervention as I have them
>>> automatically built but for testing I have to update my development
>>> machines packages versions then test them to ensure nothing broke before
>>> uploading them to Launchpad.

a good point.

currently there is no official plan for future features (they get
included as someone provides patches/checks in).

chris

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: GPL debugger for eZ430-RF2500 on Linux/BSD

2009-11-24T08:40:31Z

On Mon, Nov 23, 2009 at 7:45 PM, Daniel Beer <dlbeer@...> wrote:

> On Mon, Nov 23, 2009 at 04:18:19PM -0500, John Porubek wrote:
>> On Tue, Nov 17, 2009 at 7:26 PM, Daniel Beer <dlbeer@...> wrote:
>> > Probably easiest just to use GID 1000, which you're already in. Try
>> > this (as root):
>> >
>> > umount /proc/bus/usb
>> > mount -t usbfs none /proc/bus/usb -o devgid=1000,devmode=0664
>> >
>> > If you want to tidy things up later, you might like to make a "usb"
>> > group, add yourself to it and have usbfs mounted with the GID of
>> > the "usb" group.
>> >
>>
>> As it turns out, I was using the right GID but the wrong mount point.
>> Under Ubuntu 9.10, instead of "/proc/bus/usb", I had to use
>> "/dev/bus/usb". Also, I had to add my UID to the mount options
>> (devuid=1000). I haven't made a "usb" group yet, but I think I will.
>>
>> Now if I only could make this stick across reboots. As I understand
>> it, one would normally use fstab to apply mounts at bootup. However,
>> I'm not sure if that applies here, or, if it does, how to do it. Any
>> ideas?
>
> If the init scripts consult /etc/fstab when mounting procfs, you
> could add a line like this:
>
> none /dev/bus/usb usbfs devuid=1000 0 0
>
> I haven't tried this, however.
>
> - Daniel

It works! Thank you so much for your help and for creating a great
tool and making it available. Now to compile the latest version and
try it out with an eZ430-F2013 and FET430UIF. I may be back. ;^)

--John

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Problem with sprintf and snprintf in a msp430x2617

2009-11-24T04:54:25Z

Hi,
I've been trying to fix a problem with my build of mspgcc but I got
out of ideas to fix it. Some time ago I used a build from july 2008
and everithing worked just fine, now I've switched to the last cvs
version and I've found out that sprintf for some reason doesn't write
to the destiny. I've tryed to exec this (this line is from the output
of a nesc precompiler):
snprintf(debugbuf, 256, " + Accelerometer Started\n");
But instead of moving the string to the debugbuf keeps the same
information just as if " + Accelerometer Started\n" was a null
string.
Does somebody know what could be causing this behavior? I suspect that
may have something to do with the compiler used, but I cannot be sure
Thank you

--
Jordi Soucheiron
Software Engineer

DEXMA
Parc Tecnològic la Salle
Sant Joan de la Salle, 42
08022 Barcelona
t/f: [+34] 93 181 01 95
www.dexmatech.com
jsoucheiron@...

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: Programming the msp430f5529 via USB on Linux

2009-11-24T01:38:23Z

Hi Fred,

there was a post on the mailinglist from 2009/10/01 00:24 from Hans
Nieuwenhuis. He mentioned the elprotronic flash tool that is able to flash
55xx devices. It may possibly work under a virtual machine.

Best regards,
Gerald

-----Ursprüngliche Nachricht-----
Von: Frédéric Sureau [mailto:frederic.sureau@...]
Gesendet: Montag, 23. November 2009 22:54
An: GCC for MSP430 - http://mspgcc.sf.net
Betreff: [Mspgcc-users] Programming the msp430f5529 via USB on Linux

Hi everybody,

I would want to use the MSP430-FET-UIF to program a MSP430F5529. I'm on
Ubuntu Karmic.

I've tried many solutions found on the net, but I can't make it work.

With Linux version of gdbproxy I get the message :
"The FET tool version does not match this program. Update required." When I
ask for a firmware update, the same message appears.

I've tried to use the Windows version with Wine, using different MSP430.dll
I've found in CCE, IAR, etc. The best thing I obtain is : "Could not find
device (or device not supported) (4)" In other cases, this is the same
message as in Linux version.

Does anyone is able to flash or debug the MSP430F5529 with Linux ? Does the
only solution is to use Windows in a Virtual Machine ?

Thanks
Fred

----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with Crystal
Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: GPL debugger for eZ430-RF2500 on Linux/BSD

2009-11-23T16:45:33Z

On Mon, Nov 23, 2009 at 04:18:19PM -0500, John Porubek wrote:

> On Tue, Nov 17, 2009 at 7:26 PM, Daniel Beer <dlbeer@...> wrote:
> > Probably easiest just to use GID 1000, which you're already in. Try
> > this (as root):
> >
> > umount /proc/bus/usb
> > mount -t usbfs none /proc/bus/usb -o devgid=1000,devmode=0664
> >
> > If you want to tidy things up later, you might like to make a "usb"
> > group, add yourself to it and have usbfs mounted with the GID of
> > the "usb" group.
> >
>
> As it turns out, I was using the right GID but the wrong mount point.
> Under Ubuntu 9.10, instead of "/proc/bus/usb", I had to use
> "/dev/bus/usb". Also, I had to add my UID to the mount options
> (devuid=1000). I haven't made a "usb" group yet, but I think I will.
>
> Now if I only could make this stick across reboots. As I understand
> it, one would normally use fstab to apply mounts at bootup. However,
> I'm not sure if that applies here, or, if it does, how to do it. Any
> ideas?

If the init scripts consult /etc/fstab when mounting procfs, you
could add a line like this:

none /dev/bus/usb usbfs devuid=1000 0 0

I haven't tried this, however.

- Daniel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Programming the msp430f5529 via USB on Linux

2009-11-23T13:54:09Z

Hi everybody,

I would want to use the MSP430-FET-UIF to program a MSP430F5529.
I'm on Ubuntu Karmic.

I've tried many solutions found on the net, but I can't make it work.

With Linux version of gdbproxy I get the message :
"The FET tool version does not match this program. Update required."
When I ask for a firmware update, the same message appears.

I've tried to use the Windows version with Wine, using different
MSP430.dll I've found in CCE, IAR, etc.
The best thing I obtain is :
"Could not find device (or device not supported) (4)"
In other cases, this is the same message as in Linux version.

Does anyone is able to flash or debug the MSP430F5529 with Linux ?
Does the only solution is to use Windows in a Virtual Machine ?

Thanks
Fred

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: GPL debugger for eZ430-RF2500 on Linux/BSD

2009-11-23T13:18:19Z

On Tue, Nov 17, 2009 at 7:26 PM, Daniel Beer <dlbeer@...> wrote:

> Probably easiest just to use GID 1000, which you're already in. Try
> this (as root):
>
> umount /proc/bus/usb
> mount -t usbfs none /proc/bus/usb -o devgid=1000,devmode=0664
>
> If you want to tidy things up later, you might like to make a "usb"
> group, add yourself to it and have usbfs mounted with the GID of
> the "usb" group.
>

As it turns out, I was using the right GID but the wrong mount point.
Under Ubuntu 9.10, instead of "/proc/bus/usb", I had to use
"/dev/bus/usb". Also, I had to add my UID to the mount options
(devuid=1000). I haven't made a "usb" group yet, but I think I will.

Now if I only could make this stick across reboots. As I understand
it, one would normally use fstab to apply mounts at bootup. However,
I'm not sure if that applies here, or, if it does, how to do it. Any
ideas?

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: Ubuntu Packages, Karmic, where did the source code go in Bazaar?

2009-11-23T12:33:02Z

Hi all,

The Bazaar code has been away for over a week now so I have turned off
my automatic package building for now. I do not have packages for karmic
as I did not know the state of the source code. What did happen to the
code in Bazaar?

I am still working on packaging but at the same time I am trying to
understand some of the internals so I can better understand how the
cross compiler works.

Adam Horden

marco_sp wrote:

> Hi Adam and everybody else,
>
> Yes Adam I noted your efforts. I really appreciate the works and hope new
> packages will follow. If I could provide practical help I would, but my
> linux knowledge is too limited.
>
> As far as my understanding goes most of the compilation problems are
> caused by dependencies and interfaces with out-of-project code like the
> kernel, bin-utils, gcc, and the secret libhil.so / msp430.dll code. I
> always wondered why all these interfaces are needed (and why hacks around
> the TI secret code were not already included ;-) ).
>
> So I really hope that the mspgcc experts like Chris and others, support
> Adam in the adventure. Many would benefit and it would keep mspgcc popular
> or (most probably) attract many new users.
>
> Cheers,
> Marco
>
>
>
>> Hi All,
>>
>> First off sorry if this sounds a little harsh, I am just trying to sort
>> out the packages I created over the last six months.
>>
>> You might have or have not noticed that I have spent a considerable
>> amount of time creating Ubuntu packages for mspgcc to try and give some
>> thing back. I have asked here for advice regarding the state of the
>> source code but not had a response telling me exactly what I need to
>> know to continue building packages. Its frustrating for me as I am
>> trying to get more users to use mspgcc as well as make it easier for
>> people to install the cross compiler. I use the cross compiler but
>> without me having to dig deep into the source code and the internals of
>> binutils, gcc, libc, gdb I would rather get the information I required
>> direct from one of the developers. Is there a developer or advanced user
>> who is willing to help me at this stage to get working Karmic packages?
>>
>> At the moment there is no support for Karmic as they dropped support for
>> gcc3-4. I found the code in Bazaar and for the last few weeks tested
>> this on a Karmic system until last night when the Bazaar resporatory
>> disappered and taking down my build system with it. I make automatic
>> builds each day to test the qualtity of code. So what is the state of
>> the source code in Bazaar? and where did it go?
>>
>> Now I asked for advice if this code in Bazaar would be ready for
>> packaging but never got a reply. I also asked if it was possible to sort
>> out a release system and Rob Spanton agreed on this but nothing moved
>> forward. As a packager it gives me a headache tracking my own revision
>> numbers to a revision in Bazaar or CVS.
>>
>> People are using my packages and I can support the packages, but without
>> help from the developers I can only do so much. I did not develop the
>> cross compiler so when finding and fixing bugs in my packages I tend to
>> see if it exists when I compiler the tool chain from source in a virtual
>> machine or if its something wrong with my package.
>>
>> At the moment my packages are rebuilt each day, and I am hoping the
>> patches I generate automatically will be used across all packages not
>> just for Ubuntu so until we get a version number all the packages should
>> contain the same code for a version number / revision.
>>
>> There are commits that break things from time to time so building them
>> each day is a bad idea. We need a release schedule. I have been there
>> with my packages and it requires human intervention as I have them
>> automatically built but for testing I have to update my development
>> machines packages versions then test them to ensure nothing broke before
>> uploading them to Launchpad.
>>
>> So I am thinking that I will drop the packages soon as there is too many
>> unanswered questions. I do not mind spending the time it just seems that
>> there needs to be more documentation and non of the developers answered
>> any of my questions when I posted them to the list. There is no point
>> there been broken packages because I do not get the information I
>> required to improve and release new version of the packages. It also
>> causes users some headaches as people install a broken cross compiler.
>> The documentation is poor. I was (still will do) going to do a new
>> website, with packages, source packages, install documentation so every
>> thing would be up to date and you would not have to spend hours trying
>> to crawl through mailing list archives to get the information I required
>> as well as I would try to push new devices were possible.
>>
>> So where do I go from here is there any one willing to spend some time
>> via email going over the current state of the project with me? So we can
>> get these packages up to date with the correct source code and support
>> as many devices as possible. And try to get all the patches into one
>> place.
>>
>> Thanks again,
>> Adam
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@...
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>

Re: msp430x5529 support

2009-11-23T04:09:23Z

Hi Bernie,

we have updated our script on the webpage. It downloads the patches
automatically and builds a new toolchain with it.

Best regards,
Gerald

-----Ursprüngliche Nachricht-----
Von: Bernard Mentink [mailto:bmentink@...]
Gesendet: Montag, 23. November 2009 07:36
An: GCC for MSP430 - http://mspgcc.sf.net
Betreff: Re: [Mspgcc-users] msp430x5529 support

On Mon, Nov 23, 2009 at 7:21 AM, Bernard Mentink <bmentink@...> wrote:

>
>
> On Mon, Nov 23, 2009 at 5:40 AM, <dasaspock@...> wrote:
>
>> Hi Bernie,
>>
>> we integrated the USB peripherals.
>> Please try our new patch under
>>
>> http://www.innoventis.de/downloads/mspgcc/
>>
>> and give us feedback.
>>
>>
>>
>>

Hi,

Tried the new script, but it fails with:

""
patching file ld/scripttempl/elf32msp430_3.sc
patching file opcodes/msp430-dis.c
\n\nBinutils patch "binutils_5529.patch" not availavle! Exiting\n\n

Does the script download the patch, or do I have to put is somewhere still.
In the previous fix you did to the script, I didn't have to fetch anything
else manually, it was transparent.

Cheers,
Bernie

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: msp430x5529 support

2009-11-22T22:36:10Z

On Mon, Nov 23, 2009 at 7:21 AM, Bernard Mentink <bmentink@...> wrote:

Hi,

Tried the new script, but it fails with:

""
patching file ld/scripttempl/elf32msp430_3.sc
patching file opcodes/msp430-dis.c
\n\nBinutils patch "binutils_5529.patch" not availavle! Exiting\n\n

Does the script download the patch, or do I have to put is somewhere still.
In the previous fix you did to the script, I didn't have to fetch anything
else manually, it was transparent.

Cheers,
Bernie

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: msp430x5529 support

2009-11-22T10:21:57Z

On Mon, Nov 23, 2009 at 5:40 AM, <dasaspock@...> wrote:

> Hi Bernie,
>
> we integrated the USB peripherals.
> Please try our new patch under
>
> http://www.innoventis.de/downloads/mspgcc/
>
> and give us feedback.
>
> By the way:
> What kind of driver do you use at PC side for the USB communication?
>
> Best regards
>
>
>

Hi,

Thanks for the patch, will try it out tonight.

We are using the standard windows CDC driver to use the device as a virtual
COM port for a work project ..

At play I have implemented a MIDI driver class for the MSP and again use the
standard windows/linux driver to talk to it on the PC.

Cheers,
Bernie

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: msp430x5529 support

2009-11-22T08:40:00Z

Hi Bernie,

we integrated the USB peripherals.
Please try our new patch under

http://www.innoventis.de/downloads/mspgcc/

and give us feedback.

By the way:
What kind of driver do you use at PC side for the USB communication?

Best regards

-------- Original-Nachricht --------
> Datum: Fri, 20 Nov 2009 20:31:48 +1300
> Von: Bernard Mentink <bmentink@...>
> An: "GCC for MSP430 - http://mspgcc.sf.net" <mspgcc-users@...>
> Betreff: Re: [Mspgcc-users] msp430x5529 support

> On Thu, Nov 19, 2009 at 7:54 AM, Gerald Lutter
> <g.lutter@...>wrote:
>
> > Hi Bernie,
> >
> > > 1. I notice some MACROS around each header file
> > > entry. Are these for the linker so it knows the
> > > address of each peripheral? If so, can you tell
> > > me how to use them.
> >
> > Yes, they are used to set the addresses but not for the linker it's for
> the
> > compiler and the assembler. The linker itself compared to the
> CC-Essentials
> > Toolchain does not know anything about the SFR locations. For details
> take
> > a
> > look at my post on the mailinglist: "Complete Support for msp430x54xx
> > devices inside msp430-libc" from 2009/08/20 11:55.
> >
> > > 2. After adding the header file and adding the
> > > details to msp430x55x9-new...., can I just
> > > recompile with the script with mspgcclibc=1?
> >
> > No because the directory will be cleaned every time you start the
> script.
> > The script itself stops after adding the current patches to msp430-libc.
> > You
> > have to press <ENTER> to proceed. At this point you can apply your
> changes
> > to the library. After finishing your work just press Enter and your
> changes
> > will be part of your version of the library.
> >
> > Before continuing the build by pressing <ENTER> I recommend to create a
> > patch of your version because if anything goes wrong during compile you
> can
> > continue your work by just adding your patch to the current version of
> the
> > library.
> >
> > Best regards
> > Gerald
> >
> >
> Hi Gerald,
>
> I am having trouble including the files. I put the new
> MSP430x55x9_newversion.h into the directory build/msp430libc/include and
> the new file USB.h into build/msp430libc/include/msp430new when the
> msp430-libc compile was at the ENTER stage, and then let it complete.
>
> My output had the new USB.h file, but still had the
> old MSP430x55x9_newversion.h, it was obviously getting overwritten.
>
> Can you please explain where to put the files when at the ENTER part of
> the
> compile.
> Maybe I have to use a different name? But then how do I stop the old
> ...._newversion.h being included as well.
>
> Also is it sufficient to in the script just enable the libc compile, with
> the others set to "0".
>
> Thanks,
> Bernie

--
Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: Ubuntu Packages, Karmic, where did the source code go in Bazaar?

2009-11-21T12:33:54Z

Hi Adam and everybody else,

Yes Adam I noted your efforts. I really appreciate the works and hope new
packages will follow. If I could provide practical help I would, but my
linux knowledge is too limited.

As far as my understanding goes most of the compilation problems are
caused by dependencies and interfaces with out-of-project code like the
kernel, bin-utils, gcc, and the secret libhil.so / msp430.dll code. I
always wondered why all these interfaces are needed (and why hacks around
the TI secret code were not already included ;-) ).

So I really hope that the mspgcc experts like Chris and others, support
Adam in the adventure. Many would benefit and it would keep mspgcc popular
or (most probably) attract many new users.

Cheers,
Marco

> Hi All,
>
> First off sorry if this sounds a little harsh, I am just trying to sort
> out the packages I created over the last six months.
>
> You might have or have not noticed that I have spent a considerable
> amount of time creating Ubuntu packages for mspgcc to try and give some
> thing back. I have asked here for advice regarding the state of the
> source code but not had a response telling me exactly what I need to
> know to continue building packages. Its frustrating for me as I am
> trying to get more users to use mspgcc as well as make it easier for
> people to install the cross compiler. I use the cross compiler but
> without me having to dig deep into the source code and the internals of
> binutils, gcc, libc, gdb I would rather get the information I required
> direct from one of the developers. Is there a developer or advanced user
> who is willing to help me at this stage to get working Karmic packages?
>
> At the moment there is no support for Karmic as they dropped support for
> gcc3-4. I found the code in Bazaar and for the last few weeks tested
> this on a Karmic system until last night when the Bazaar resporatory
> disappered and taking down my build system with it. I make automatic
> builds each day to test the qualtity of code. So what is the state of
> the source code in Bazaar? and where did it go?
>
> Now I asked for advice if this code in Bazaar would be ready for
> packaging but never got a reply. I also asked if it was possible to sort
> out a release system and Rob Spanton agreed on this but nothing moved
> forward. As a packager it gives me a headache tracking my own revision
> numbers to a revision in Bazaar or CVS.
>
> People are using my packages and I can support the packages, but without
> help from the developers I can only do so much. I did not develop the
> cross compiler so when finding and fixing bugs in my packages I tend to
> see if it exists when I compiler the tool chain from source in a virtual
> machine or if its something wrong with my package.
>
> At the moment my packages are rebuilt each day, and I am hoping the
> patches I generate automatically will be used across all packages not
> just for Ubuntu so until we get a version number all the packages should
> contain the same code for a version number / revision.
>
> There are commits that break things from time to time so building them
> each day is a bad idea. We need a release schedule. I have been there
> with my packages and it requires human intervention as I have them
> automatically built but for testing I have to update my development
> machines packages versions then test them to ensure nothing broke before
> uploading them to Launchpad.
>
> So I am thinking that I will drop the packages soon as there is too many
> unanswered questions. I do not mind spending the time it just seems that
> there needs to be more documentation and non of the developers answered
> any of my questions when I posted them to the list. There is no point
> there been broken packages because I do not get the information I
> required to improve and release new version of the packages. It also
> causes users some headaches as people install a broken cross compiler.
> The documentation is poor. I was (still will do) going to do a new
> website, with packages, source packages, install documentation so every
> thing would be up to date and you would not have to spend hours trying
> to crawl through mailing list archives to get the information I required
> as well as I would try to push new devices were possible.
>
> So where do I go from here is there any one willing to spend some time
> via email going over the current state of the project with me? So we can
> get these packages up to date with the correct source code and support
> as many devices as possible. And try to get all the patches into one
> place.
>
> Thanks again,
> Adam
>

Current build

2009-11-20T10:06:05Z

The build instructions from source for Linux at:

http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Linux_installation

show a build from CVS, along the lines of README-MAINTAINER.txt

All the new code commits seem to be to the Bazaar repository. Is the CVS still
maintained? If it is not the most up-to-date version, what is the best way to
build from Bazaar?
--
Rick Jenkins <rick@...>
Hartman Technica http://www.hartmantech.com
Phone +1 (403) 230-1987
221 35 Avenue. N.E., Calgary, Alberta, Canada T2E 2K5

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: Size of functions

2009-11-20T08:20:17Z

On Thursday 19 November 2009 17:27:12 mspgcc-users-
request@... wrote:
> -------------- next part --------------
> An embedded and charset-unspecified text was scrubbed...
> Name: msp430xRAM.x

Regrettably, your linker script was removed from the digest. Could you post it
somewhere accessible, please?
--
Rick Jenkins <rick@...>
Hartman Technica http://www.hartmantech.com
Phone +1 (403) 230-1987
221 35 Avenue. N.E., Calgary, Alberta, Canada T2E 2K5

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: msp430x5529 support

2009-11-19T23:31:48Z

On Thu, Nov 19, 2009 at 7:54 AM, Gerald Lutter <g.lutter@...>wrote:

> Hi Bernie,
>
> > 1. I notice some MACROS around each header file
> > entry. Are these for the linker so it knows the
> > address of each peripheral? If so, can you tell
> > me how to use them.
>
> Yes, they are used to set the addresses but not for the linker it's for the
> compiler and the assembler. The linker itself compared to the CC-Essentials
> Toolchain does not know anything about the SFR locations. For details take
> a
> look at my post on the mailinglist: "Complete Support for msp430x54xx
> devices inside msp430-libc" from 2009/08/20 11:55.
>
> > 2. After adding the header file and adding the
> > details to msp430x55x9-new...., can I just
> > recompile with the script with mspgcclibc=1?
>
> No because the directory will be cleaned every time you start the script.
> The script itself stops after adding the current patches to msp430-libc.
> You
> have to press <ENTER> to proceed. At this point you can apply your changes
> to the library. After finishing your work just press Enter and your changes
> will be part of your version of the library.
>
> Before continuing the build by pressing <ENTER> I recommend to create a
> patch of your version because if anything goes wrong during compile you can
> continue your work by just adding your patch to the current version of the
> library.
>
> Best regards
> Gerald
>
>

Hi Gerald,

I am having trouble including the files. I put the new
MSP430x55x9_newversion.h into the directory build/msp430libc/include and
the new file USB.h into build/msp430libc/include/msp430new when the
msp430-libc compile was at the ENTER stage, and then let it complete.

My output had the new USB.h file, but still had the
old MSP430x55x9_newversion.h, it was obviously getting overwritten.

Can you please explain where to put the files when at the ENTER part of the
compile.
Maybe I have to use a different name? But then how do I stop the old
...._newversion.h being included as well.

Also is it sufficient to in the script just enable the libc compile, with
the others set to "0".

Thanks,
Bernie

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

JTAG programming slowdown

2009-11-19T16:26:53Z

With a new, faster machine I'm unable to program boards which have a reset
chip, which slows the reset signal. I'd like to use --slowdown, as in

msp430-jtag -DImEpv --slowdown=20 file.ihex

but this fails on inability to find the slowdown file. Examining the code in
msp430-jtag we see during option processing:

elif o == "--slowdown":
slowdown = long(a)
import ctypes
if sys.platform == 'win32':
HIL_SetSlowdown = ctypes.windll.HIL.HIL_SetSlowdown
else:
# XXX and posix platforms?!
HIL_SetSlowdown = ctypes.cdll.HIL.HIL_SetSlowdown
HIL_SetSlowdown = ctypes.windll.HIL.HIL_SetSlowdown
HIL_SetSlowdown.argtypes = [ctypes.c_ulong]
HIL_SetSlowdown.restype = ctypes.c_int # actually void
# set slowdown
HIL_SetSlowdown(slowdown)

It looks as if the selection of the "XXX and posix platforms" is defeated by
the line following the "else" section. Since I'm on a Linux platform, this
will always ensure that the appropriate file is not found.
--
Rick Jenkins <rick@...>
Hartman Technica http://www.hartmantech.com
Phone +1 (403) 230-1987
221 35 Avenue. N.E., Calgary, Alberta, Canada T2E 2K5

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: msp430x5529 support

2009-11-19T12:15:29Z

On Thu, Nov 19, 2009 at 7:54 AM, Gerald Lutter <g.lutter@...>wrote:

Hi Gerald,

I have constructed the new USB header (USB.h) and have included the
necessary entries in msp430x55x9_newversion.h.
About to try it out. Can you refresh my memory on how to create diff files?
When they test out, how do I get them to you for inclusion ..

Thanks,
Bernie

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: Size of functions

2009-11-18T16:14:26Z

Rick Jenkins schrieb:
>> You have seen my assembly hack? If you put your fucntion into a separate
>> object file, it will be 100% safe, even with -o3. Without any linker
>> hacking.
>
> I have, and it's clearly the most elegant solution to my original problem. In
> particular, it confines the "trickery" to the source file containing the
> function, instead of requiring an obscure, dissociated entry in a linker
> script. After trying it out I'm convinced this is the cleanest way to go.

i'll add my thoughts here too, most of it was already said in the thread
though.

with just sections for some function you always need to ensure manually
that no function outside that segment is called and that the code is
position independent. the compiler may select to call code from libgcc
to process some things (e.g. division). this would not end up in that
section. so too many things to worry about ;-)

one solution is implement all of it in assembler. you know what you have
and can write the code in a position independent way and calculate the
size easily. a good solution if you are not afraid from the assembly.

the other possibility is to use the custom linker script. compile/link
into RAM are. then take that binary and include it as array of bytes in
the code.

i've attached a linker script to link an application to RAM and a
script that collects the code/data segments from a hex or ELF file and
outputs C code as example. the script was used by be to write
"updater-updaters" for the boot-loader approach described below. so it
is used to flash the data, but replacing that with a different startup
code should be easy.

but note that copying data to RAM and executing has to be done with
care. you probably can not return afterwards as most of your
applications variables are overwritten. the stack should be set to a
well known position so that it's not right within your newly copied
functions.
a bootstrap function for the assembler variant is provided below.
however for the second solution it needs to be rewritten slightly
differently (see comments below).

> If I felt a little less fallible, I'd use the method of a fixed, unchangeable
> reprogrammer in a non-erased section of ROM. I just have a nasty, sinking
> feeling that, the moment this was widely deployed, I'd find a bug in it...

at least it is a small peace of code with one one or two features. that
makes it easier to test and have a good feeling that there is no bug
preventing basic operation.

i do use "bootloaders" that are kept in the top 2kB Flash. i've got
firmware updates over I2C as master or as slave, BSL compatible and
others. however i did not use any encryption.

---
header file (.h):
void __attribute__((noreturn)) softBSLfromRAM(void);

assembler file (.S):
; the code between the labels "softBSL" and ".LsoftBSL_end" is copied to
; RAM and launched. put you update function between those labels. this
; snipped does not show an implementation of that.

; trick used in this solution:
; the stack pointer is used to copy the data and it will end up
; BELOW the copied code. so the code needs to leave some space in
; RAM for the stack. and the code itself should be written position
; independently. if that can not be guaranteed, better copy starting
; from 0x200 and use a separate register as counter.

.global softBSLfromRAM
.type softBSLfromRAM,@function

softBSLfromRAM:
mov #0x0400, r1 ; SP is used as dst ptr
mov #.LsoftBSL_end, r13 ; source start address
.Lcopy: decd r1 ; decrement dst pointer
decd r13 ; decrement src pointer
mov @r13, @r1 ; copy one word
cmp #softBSL, r13 ; compare with lowest src address
jne .Lcopy ; keep copying while n<len
br r1 ; execute softBSL copy in RAM

.LsoftBSLfromRAM_end:
.size softBSLfromRAM,.LsoftBSLfromRAM_end-softBSLfromRAM

/* Hacked version of the linker script of a F1121.

The .text section is moved to the RAM. The segment size is set
to 2kB, so that this file can be used to link programs for all
MSP430 derrivates. However this has the disadvantage that no
error message is shown when more that the available RAM is used
on a smaller device.

chris <cliechti@...>
*/
OUTPUT_FORMAT("elf32-msp430","elf32-msp430","elf32-msp430")
OUTPUT_ARCH(msp:110)
MEMORY
{
ram (rwx) : ORIGIN = 0x0200, LENGTH = 2K
bootloader(rx): ORIGIN = 0x0c00, LENGTH = 1K
}
SECTIONS
{
/* Read-only sections, merged into text segment: */
.hash : { *(.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.gnu.version : { *(.gnu.version) }
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
.rel.init : { *(.rel.init) }
.rela.init : { *(.rela.init) }
.rel.text :
{
*(.rel.text)
*(.rel.text.*)
*(.rel.gnu.linkonce.t*)
}
.rela.text :
{
*(.rela.text)
*(.rela.text.*)
*(.rela.gnu.linkonce.t*)
}
.rel.fini : { *(.rel.fini) }
.rela.fini : { *(.rela.fini) }
.rel.rodata :
{
*(.rel.rodata)
*(.rel.rodata.*)
*(.rel.gnu.linkonce.r*)
}
.rela.rodata :
{
*(.rela.rodata)
*(.rela.rodata.*)
*(.rela.gnu.linkonce.r*)
}
.rel.data :
{
*(.rel.data)
*(.rel.data.*)
*(.rel.gnu.linkonce.d*)
}
.rela.data :
{
*(.rela.data)
*(.rela.data.*)
*(.rela.gnu.linkonce.d*)
}
.rel.ctors : { *(.rel.ctors) }
.rela.ctors : { *(.rela.ctors) }
.rel.dtors : { *(.rel.dtors) }
.rela.dtors : { *(.rela.dtors) }
.rel.got : { *(.rel.got) }
.rela.got : { *(.rela.got) }
.rel.bss : { *(.rel.bss) }
.rela.bss : { *(.rela.bss) }
.rel.plt : { *(.rel.plt) }
.rela.plt : { *(.rela.plt) }
/* Internal text space */
.text :
{
*(.init)
. = ALIGN(2);
*(.text)
. = ALIGN(2);
*(.text.*)
. = ALIGN(2);
*(.fini)
_etext = . ;
PROVIDE (__data_start = .) ;
. = ALIGN(2);
*(.data)
. = ALIGN(2);
*(.gnu.linkonce.d*)
. = ALIGN(2);
_edata = . ;
PROVIDE (__bss_start = .) ;
*(.bss)
*(COMMON)
PROVIDE (__bss_end = .) ;
_end = . ;
} > ram

/* bootloader */
.bootloader :
{
PROVIDE (__boot_start = .) ;
*(.bootloader)
. = ALIGN(2);
*(.bootloader.*)
} > bootloader

/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the beginning
of the section so we begin them at 0. */
/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
.debug_info 0 : { *(.debug_info) *(.gnu.linkonce.wi.*) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
PROVIDE (__stack = 0xa00) ;
}

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Ubuntu Packages, Karmic, where did the source code go in Bazaar?

2009-11-18T14:03:24Z

Hi All,

First off sorry if this sounds a little harsh, I am just trying to sort
out the packages I created over the last six months.

You might have or have not noticed that I have spent a considerable
amount of time creating Ubuntu packages for mspgcc to try and give some
thing back. I have asked here for advice regarding the state of the
source code but not had a response telling me exactly what I need to
know to continue building packages. Its frustrating for me as I am
trying to get more users to use mspgcc as well as make it easier for
people to install the cross compiler. I use the cross compiler but
without me having to dig deep into the source code and the internals of
binutils, gcc, libc, gdb I would rather get the information I required
direct from one of the developers. Is there a developer or advanced user
who is willing to help me at this stage to get working Karmic packages?

At the moment there is no support for Karmic as they dropped support for
gcc3-4. I found the code in Bazaar and for the last few weeks tested
this on a Karmic system until last night when the Bazaar resporatory
disappered and taking down my build system with it. I make automatic
builds each day to test the qualtity of code. So what is the state of
the source code in Bazaar? and where did it go?

Now I asked for advice if this code in Bazaar would be ready for
packaging but never got a reply. I also asked if it was possible to sort
out a release system and Rob Spanton agreed on this but nothing moved
forward. As a packager it gives me a headache tracking my own revision
numbers to a revision in Bazaar or CVS.

People are using my packages and I can support the packages, but without
help from the developers I can only do so much. I did not develop the
cross compiler so when finding and fixing bugs in my packages I tend to
see if it exists when I compiler the tool chain from source in a virtual
machine or if its something wrong with my package.

At the moment my packages are rebuilt each day, and I am hoping the
patches I generate automatically will be used across all packages not
just for Ubuntu so until we get a version number all the packages should
contain the same code for a version number / revision.

There are commits that break things from time to time so building them
each day is a bad idea. We need a release schedule. I have been there
with my packages and it requires human intervention as I have them
automatically built but for testing I have to update my development
machines packages versions then test them to ensure nothing broke before
uploading them to Launchpad.

So I am thinking that I will drop the packages soon as there is too many
unanswered questions. I do not mind spending the time it just seems that
there needs to be more documentation and non of the developers answered
any of my questions when I posted them to the list. There is no point
there been broken packages because I do not get the information I
required to improve and release new version of the packages. It also
causes users some headaches as people install a broken cross compiler.
The documentation is poor. I was (still will do) going to do a new
website, with packages, source packages, install documentation so every
thing would be up to date and you would not have to spend hours trying
to crawl through mailing list archives to get the information I required
as well as I would try to push new devices were possible.

So where do I go from here is there any one willing to spend some time
via email going over the current state of the project with me? So we can
get these packages up to date with the correct source code and support
as many devices as possible. And try to get all the patches into one place.

Thanks again,
Adam

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: Size of functions

2009-11-18T13:23:08Z

At 20:17 18-11-2009 +0000, you wrote:
>On 2009-11-18, N. Coesel <nico@...> wrote:
>> At 15:54 18-11-2009 +0000, you wrote:
>>>On 2009-11-18, David Brown <david@...> wrote:
>>>> N. Coesel wrote:
>>>
>>>>>> The old "security by obscurity" trick, that has /such/ a good
reputation?

>>>>>
>>>>> Any means of security is security by obscurity by definition.
>>>>> All protections schemes come down to hiding a secret
>>>>> (obscurity). Whether its a key, a secret algorithm, etc.
>>>>
>>>> The phrase "security by obscurity" is normally taken to mean
>>>> "security by hiding the way it works", i.e., trying to hide
>>>> the code or algorithm.
>>>
>>>Exactly. "Security by obscurity" does not refer to the fact
>>>that you need to keep a secret key a secret. It refers
>>>specifically to the dependance on keeping the design and
>>>implementation of the _algorithms_ a secret.
>>>
>>>Quoting Paul Schneier in _Secrets_&_Lies_:
>>>
>>> A good security design has no secrets in its details. In
>>> other words, all of the security is in the product itself
>>> and its chageable secret: the cryptographic keys, the
>>> passwords, the tokens and so forth. The antithesis is
>>> _security_by_obscurity_: The details of the system are
>>> part of the security. If a system is designed with
>>> security by obscurity then that security is delicate.
>>>
>>>Later in the same book:
>>>
>>> Again and again in this book I rail against _security_by_
>>> _obscurity_: proprietary cryptography, closed source code,
>>> secret operating systems.
>>>
>>>
>>>Security by obscurity doesn't work.
>>
>> Which is big a misconception!
>
>History appears to show otherwise.

If that where the case then tell me why our every day life is filled with
applications that use 'keep the lock' secret method? Lets start with the
PIN code on debit/credit cards, public travel payment systems and access
control systems. People that run those systems are not just looking at
technical possibilities they also want a system with which they can make a
profit.

>> - If you make the way the lock works publicly available then you need a
>> complex lock and a big key. This security measure relies on the key staying
>> hidden and that it will take a long time to pick the lock.
>>
>> - If you keep the way the lock works secret,
>
>You can't. At least not for long.

Well, it took 15 years before someone hacked Mifare by peeling the chip.
People don't seem to be dumping Mifare so I guess we'll see Mifare around
for another 10 years. Not a problem because you can put AES encrypted data
onto a Mifare card which solves the entire issue.

Nico Coesel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: Size of functions

2009-11-18T13:20:48Z

N. Coesel wrote:

> At 15:54 18-11-2009 +0000, you wrote:
>> On 2009-11-18, David Brown <david@...> wrote:
>>> N. Coesel wrote:
>>>>> The old "security by obscurity" trick, that has /such/ a good reputation?
>>>> Any means of security is security by obscurity by definition.
>>>> All protections schemes come down to hiding a secret
>>>> (obscurity). Whether its a key, a secret algorithm, etc.
>>> The phrase "security by obscurity" is normally taken to mean
>>> "security by hiding the way it works", i.e., trying to hide
>>> the code or algorithm.
>> Exactly. "Security by obscurity" does not refer to the fact
>> that you need to keep a secret key a secret. It refers
>> specifically to the dependance on keeping the design and
>> implementation of the _algorithms_ a secret.
>>
>> Quoting Paul Schneier in _Secrets_&_Lies_:
>>
>> A good security design has no secrets in its details. In
>> other words, all of the security is in the product itself
>> and its chageable secret: the cryptographic keys, the
>> passwords, the tokens and so forth. The antithesis is
>> _security_by_obscurity_: The details of the system are
>> part of the security. If a system is designed with
>> security by obscurity then that security is delicate.
>>
>> Later in the same book:
>>
>> Again and again in this book I rail against _security_by_
>> _obscurity_: proprietary cryptography, closed source code,
>> secret operating systems.
>>
>>
>> Security by obscurity doesn't work.
>
> Which is big a misconception!
>

Security by obscurity works until someone is bothered to break that
particular system, and then it is totally trashed.

> Part of my job involves assessing and implementing electronic security
> measures. I did a lot of thinking and reading about what security by
> obscurity actually *means* and came to the following conclusions (I'll use
> a lock and a key as metaphores):
>
> - If you make the way the lock works publicly available then you need a
> complex lock and a big key. This security measure relies on the key staying
> hidden and that it will take a long time to pick the lock.
>

The key must be big, but the lock doesn't have to be complex. A more
complex lock will let you use a smaller key for the same security,
however. Either way, you can pick a lock that many others have tried
and tested, and you can be confident is a good and safe lock. And
obviously you need to keep your key safe.

> - If you keep the way the lock works secret, you can keep the lock and the
> key very simple. This security measure relies on keeping both the lock and
> the key secret. Trying to pick the lock is an almost impossible task.
>

The bad guys will have the lock (if they don't, there is nothing to
break in to!). So they will be able to dismantle the lock and see how
it works. If it is complex, it will take some time and effort - but you
can be 100% confident that there are people with the tools, knowledge,
time and money to decipher any lock you choose to make if they think it
is economically advantageous. It is not expensive to find someone with
the equipment to saw the top off a chip and read out flash and ram
contents using electron microscopes and microscopic probes.

Then there is the traditional vector of attack - bribery, burglary, and
bribery. Find someone who knows how the lock works, and "persuade" them
to reveal the workings.

Once the workings of the lock are revealed, every device ever made using
that lock is compromised, since the keys are short and simple.

> Both methods require keeping a secret. So both methods rely on obscurity
> anyway!
>

The lock is /never/ secret - the bad guys have it in their hands. At
most, the way the lock works is obfusticated.

The key is individual to each system, while the lock is the same on them
all. So if you rely on the lock being secret, once it is broken
/everybody/ is in trouble. To protect everyone else in case this
happens, you have to make sure the keys are strong enough that other
systems will be safe even if the lock is broken. And if that is the
case, what exactly is the point in keeping the lock secret? It raises
the cost of the first crack somewhat, but you lose all the advantages of
being able to re-use known and trusted lock designs.

> So where is the real problem? Well, if you have to make the way the lock
> works public which can be required for code reviews, share source code or
> to gain trust then you can't get away with small keys. The downside is that
> the lock is complicated so it needs a lot of processing power. The lock is
> also prone to biased brute force attacks. The upside is that because a lot
> of people can look at the lock, it can be improved by the community.
>

Locks don't have to be complicated. A nice simple xor key is a
perfectly good encryption which is about as simple as could be imagined
- it just needs a fairly long key (depending on the amount of data to be
encrypted, and how hard you want it to be). There is a huge range from
such xor checks through pseudo-random number generators, through DES,
3DES, AES, to advanced stuff like elliptical codes. They offer a
balance between code complexity, run-time size and speed, and key size
for a given level of security. You pick what suits your needs.

There is good reason that anybody who /really/ knows about this stuff,
and really wants to protect something, uses standard known encryption
algorithms.

> Smart cards like MiFare typically use a secret lock. Is this bad? No, given
> the amount of processing power available it is the best choice! In order to
> hack the Mifare chip they had to examine the chip itself. It wasn't hacked
> by using brute force.
>
> http://www.computerworld.com/s/article/9069558/How_they_hacked_it_The_MiFare
> _RFID_crack_explained
>

Successful smart cards use known encryption algorithms. Have you
actually looked at the MiFare? There is a good summary at
<http://en.wikipedia.org/wiki/MIFARE>. It is clear that the so-called
"secret lock" encryption can be broken within seconds, while all other
MiFare cards are made using AES, DES, 3DES, etc.

I can think of few better examples showing why "security by obscurity"
(defined in the way the rest of the world defines it, i.e., trying to
keep the "lock" secret) does not work.

> The bottom line is: keeping the lock secret or just the key depends
> entirely on the requirements. There is no general rule of thumb.
>

There /is/ a rule of thumb, and it is somewhat scary that you don't
realise this. I don't want to tell anyone how to do their job, although
I understand it might sound like that. But take a long hard look at
MiFare and you cannot fail to understand why the "secret lock"
philosophy failed so badly, and why all newer MiFare cards use standard
algorithms.

The only exception to this rule of thumb is when you are designing a
single system and the key is fixed in each item made. Then it doesn't
matter whether the key is long or the code is complex, since they are
kept in the same place, and breaking one means breaking the other.

> When it comes to obfustigating code: it can be helpfull to discourage
> people. I recently had to asses a security measure for upgrading firmware
> options using a license key. I used a debugger and a decompiler. The text
> strings containing the error messages linked together with the code served
> very well as comments on what the code did. However, the part that
> converted the license key together with the serial number into a go/no-go
> condition was spread over several functions. Although the decompiler showed
> some insight in how the program was structured, determining the algorithm
> wasn't easy because of the many function calls. I never bothered to
> determine the algorithm though. Just skipping the check for the key made
> the program enable the next upgrade in the list of possible (cumulative)
> upgrades.
>

Obfusticated code certainly makes it harder to understand it. But if
you are protecting anything valuable with these codes, you will not stop
professional crackers no matter what you do. There are people (mostly
in ex-Soviet countries) with far more experience than you or I in this
field, and who cost a tenth of the hourly rate. They /will/ determine
the algorithm (unless they too can find a shortcut). Spreading the code
around with extra function calls is baby steps in obfustication - a
professional cracker would see it as nothing more than poor program
structure. Letting the compiler do its best optimisation and code
inlining will make harder code. There are methods for /real/
obfustication that post-process generated assembly code and produce
something worthy of the name "obfusticated code" - not that it helps in
reality.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: Size of functions

2009-11-18T13:09:06Z

----- Ursprüngliche Nachricht -----
Von: Rick Jenkins
Gesendet am: 18 Nov 2009 19:35:36

> Defining your section as:

> /* New section by rlj */
> __foobar_start = . ;
> *(.foobar)
> __foobar_end = . ;
> . = ALIGN(2);
> /* End new section by rlj */

> allows the section to be the exact size of the contents, in my case a single
> function.

There you'll see why I don't like the linker approach:
while I think I'm a fairly good programmer, I have no clue about how to script the linker :)
I'm sure that when I start to fiddle around with it and actually see all of its functionality in use, I can easily determine how to use it to my advantage (this is why I'm employed, at least partially), but I never had a reason
to do so. (yet)

But I already had to take a look at the assembler to analyze one or the other weird warning or error message.

>> You have seen my assembly hack? If you put your fucntion into a separate
>> object file, it will be 100% safe, even with -o3. Without any linker
>> hacking.

> I have, and it's clearly the most elegant solution to my original problem.

thanks :)

> In particular, it confines the "trickery" to the source file containing the
> function, instead of requiring an obscure, dissociated entry in a linker
> script. After trying it out I'm convinced this is the cleanest way to go.

I too prefer to put all project dependent stuff into the source files and (if it's really necessary) into the makefile.
I'd really prefer to have the target processor put into the source file (all my sources include a 'system.h' as the very first thing, where all hardware-dependent things adn config are defined, including the include of the
proper MSPx.h).
Unfortunately the target process has to be set using the -mmcu= commandline parameter in the makefile, requiring the makefile to be changed when the target processor changes.
A pragma doing htis form source level would be much better.

> If I felt a little less fallible, I'd use the method of a fixed, unchangeable
> reprogrammer in a non-erased section of ROM. I just have a nasty, sinking
> feeling that, the moment this was widely deployed, I'd find a bug in it...

by placing the plain 'flash write' function into ram, you can even reprogram the boot loader, if necessary.
Provided that the write function can handle the size of the loader in one piece.
And of course if something goes wrong exactly at this moment, there's no way back (except for using the original BSL and doing a completely new setup, if hardware allows using the BSL).
But this is also the case when all the flashing is done inside ram.
So it minimizes risk for 'normal' updates.

> Thanks to all who have taken the time to respond.

you're welcome.

JMGross

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: Size of functions

2009-11-18T12:17:39Z

On 2009-11-18, N. Coesel <nico@...> wrote:

> At 15:54 18-11-2009 +0000, you wrote:
>>On 2009-11-18, David Brown <david@...> wrote:
>>> N. Coesel wrote:
>>
>>>>> The old "security by obscurity" trick, that has /such/ a good reputation?
>>>>
>>>> Any means of security is security by obscurity by definition.
>>>> All protections schemes come down to hiding a secret
>>>> (obscurity). Whether its a key, a secret algorithm, etc.
>>>
>>> The phrase "security by obscurity" is normally taken to mean
>>> "security by hiding the way it works", i.e., trying to hide
>>> the code or algorithm.
>>
>>Exactly. "Security by obscurity" does not refer to the fact
>>that you need to keep a secret key a secret. It refers
>>specifically to the dependance on keeping the design and
>>implementation of the _algorithms_ a secret.
>>
>>Quoting Paul Schneier in _Secrets_&_Lies_:
>>
>> A good security design has no secrets in its details. In
>> other words, all of the security is in the product itself
>> and its chageable secret: the cryptographic keys, the
>> passwords, the tokens and so forth. The antithesis is
>> _security_by_obscurity_: The details of the system are
>> part of the security. If a system is designed with
>> security by obscurity then that security is delicate.
>>
>>Later in the same book:
>>
>> Again and again in this book I rail against _security_by_
>> _obscurity_: proprietary cryptography, closed source code,
>> secret operating systems.
>>
>>
>>Security by obscurity doesn't work.
>
> Which is big a misconception!

History appears to show otherwise.

> - If you make the way the lock works publicly available then you need a
> complex lock and a big key. This security measure relies on the key staying
> hidden and that it will take a long time to pick the lock.
>
> - If you keep the way the lock works secret,

You can't. At least not for long.

> you can keep the lock and the key very simple. This security
> measure relies on keeping both the lock and the key secret.
> Trying to pick the lock is an almost impossible task.
>
> Both methods require keeping a secret.

True.

> So both methods rely on obscurity anyway!

But the phrase "security by obscurity" (at least as it is used
in the software and crypto world) refers _specifically_ to the
"keep the lock design secret" method.

You can keep a key secret by not telling anyone.

To keep a lock secret you have avoid giving a copy of it to
anyone -- IOW the only way to keep a lock secret is to never
actually use it.

So you're right. A secret lock design is effective as long as
it is never used.

--
Grant Edwards grante Yow! I'm having a
at tax-deductible experience!
visi.com I need an energy crunch!!

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users