[Mspgcc-users] Bug in MSP430-AS
Hello All, I have a project which is build with IAR in the past and contains a couple of assembly sources. When building it with the lastest binutils(msp430-as) I am struck with a bug in calculation of offsets. ALL versions of msp430-as, the latest included, generate faulty code here. I simplified one code sample to intern1:mov #1,r15 dec r14 jz lab1 nop jmp lab2 intern2:dec r15 jnz intern2 ret lab1: mov #2,r14 callintern1 callintern2 ret lab2: mov #3,r13 ret .end When I assemble it with msp430-as -c bug430as.S the resulting code shows weird offsets for the 'jumps' (jmp, jz jnz), even the calls... What is happening here? In the final linked binary with a lot of .c and .S files the offsets are also wrong in the same way. Another project, solely of .c files runs well Kees -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Bug in MSP430-AS
Please clarify whether you are using msp430-as (from mspgcc) or msp430-elf-as (from upstream binutils). Several bugs like this were fixed for mspgcc, but I don't believe RH picked up the fixes. There's discussion in the archive around February 2012 on this, and it's fully documented on the mspgcc wiki but SourceForge isn't serving up those pages right now. Peter On Mon, Mar 24, 2014 at 4:53 AM, Kees Schoenmakers ksli...@gmail.com wrote: Hello All, I have a project which is build with IAR in the past and contains a couple of assembly sources. When building it with the lastest binutils(msp430-as) I am struck with a bug in calculation of offsets. ALL versions of msp430-as, the latest included, generate faulty code here. I simplified one code sample to intern1:mov #1,r15 dec r14 jz lab1 nop jmp lab2 intern2:dec r15 jnz intern2 ret lab1: mov #2,r14 callintern1 callintern2 ret lab2: mov #3,r13 ret .end When I assemble it with msp430-as -c bug430as.S the resulting code shows weird offsets for the 'jumps' (jmp, jz jnz), even the calls... What is happening here? In the final linked binary with a lot of .c and .S files the offsets are also wrong in the same way. Another project, solely of .c files runs well Kees -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[Mspgcc-users] bug in msp430 headers, involving svsctl and dcoctl
We recently switched to the msp430f2618 from a msp430f1611 and on boot up I noticed that DCOCTL was getting zero'd. This occured when I set SVSCTL=0. On further investigation, I noticed that SVSCTL and DCOCTL were both being set to 0x56. I tracked this down to msp430/include/msp430x261x.h which includes msp430/svs.h but doesn't define __msp430_has_svs_at_0x55. This is an artifact of the evolution of the chips over time. Earlier chips (no DCO, FLL) had the SVS at 56. Those chips are in the x3 and x4 families. I've carefully researched this including looking at how the h/w on the 2618 works and the DCOCTL is at 56 and SVSCTL at 55. There is a typo in the User Guide (slau144e.pdf) for the MSP430x2xx Family. It says that both DCOCTL and SVSCTL are at 56. I've also looked at the data sheet for the MSP430F241x, MSP430F261x (msp430f2618.pdf) and it shows DCOCTL at 56 and SVSCTL at 55. This is also consistent with the x15xx and x161x processors which also have SVS and DCOs. A simple fix would be to add #define __msp430_has_svs_at_0x55 prior to the #include msp430/svs.h in msp430x241x.h, msp430x24x1.h, msp430x24x.h, and msp430x261x.h since these cpus all have svs and dco h/w. Who controls the upstream? How does one go about getting changes into the upstream? -- Eric B. Decker Senior (over 50 :-) Researcher
Re: [Mspgcc-users] bug in msp430 headers, involving svsctl and dcoctl
I'll merge this into my msp430-libc this weekend. I hope to get that moved onto the mspgcc4 project soon. Peter On Wed, Mar 31, 2010 at 2:13 AM, Eric Decker cire...@gmail.com wrote: We recently switched to the msp430f2618 from a msp430f1611 and on boot up I noticed that DCOCTL was getting zero'd. This occured when I set SVSCTL=0. On further investigation, I noticed that SVSCTL and DCOCTL were both being set to 0x56. I tracked this down to msp430/include/msp430x261x.h which includes msp430/svs.h but doesn't define __msp430_has_svs_at_0x55. This is an artifact of the evolution of the chips over time. Earlier chips (no DCO, FLL) had the SVS at 56. Those chips are in the x3 and x4 families. I've carefully researched this including looking at how the h/w on the 2618 works and the DCOCTL is at 56 and SVSCTL at 55. There is a typo in the User Guide (slau144e.pdf) for the MSP430x2xx Family. It says that both DCOCTL and SVSCTL are at 56. I've also looked at the data sheet for the MSP430F241x, MSP430F261x (msp430f2618.pdf) and it shows DCOCTL at 56 and SVSCTL at 55. This is also consistent with the x15xx and x161x processors which also have SVS and DCOs. A simple fix would be to add #define __msp430_has_svs_at_0x55 prior to the #include msp430/svs.h in msp430x241x.h, msp430x24x1.h, msp430x24x.h, and msp430x261x.h since these cpus all have svs and dco h/w. Who controls the upstream? How does one go about getting changes into the upstream? -- Eric B. Decker Senior (over 50 :-) Researcher
