Which gcc for fr5969?

Yes, mspgcc is dead: no point spending effort on it once msp430-elf development started.

msp430-elf from TI or from upstream sources is the right GCC for FR5969.  I use it with mspdebug and the tilib driver from http://processors.wiki.ti.com/index.php/MSP_Debug_Stack slac406j (slac460k just released).

Okay, good to know. Thanks for the upstream link; it's much more informative than TI's page.

(It's a whole new port for copyright reasons? Wow. I've done stuff with gcc in the past, and know how much that would be...)

Just to be absolutely clear: using that compiler and mspdebug 0.22-2 from Debian, is there any risk of damaging my device? Or do I need to upgrade mspdebug too? (I'm a Linux user so the debug stack DLLs don't help me.)

David Given said:

Okay, good to know. Thanks for the upstream link; it's much more informative than TI's page.

You're welcome.  (All readers please understand that page is informational only.  Don't ask me for additional help building your own copies of the toolchain.)

David Given said:

(It's a whole new port for copyright reasons? Wow. I've done stuff with gcc in the past, and know how much that would be...)

Fundamentally, yes.  mspgcc started in 2001 and many of its contributors are no longer available to provide releases.  I only took over in 2010, and one of the companies that funded my efforts wouldn't provide a release either (ironically).

David Given said:

Just to be absolutely clear: using that compiler and mspdebug 0.22-2 from Debian, is there any risk of damaging my device? Or do I need to upgrade mspdebug too? (I'm a Linux user so the debug stack DLLs don't help me.)

I can't say because I don't use debian.  I use the MSP Debug Stack "open source" release built locally on Ubuntu with the current head of the mspdebug master branch.  I believe you will need at least slac460j to work with the new FR5969 launchpad, so I suspect you will need to build both those pieces as well.

I've just confirmed that slac460k also works.  You will need to update the firmware on the FR5969 [correction: EXP430FR5969 or FET-UIF] to match the MSP Debug Stack version.  Be sure to do that as root as the USB device ids change temporarily during the update process:

sudo mspdebug tilib --allow-fw-update

I'm unaware of any way mspdebug would brick the device.  It only happened in mspgcc because TI started using the lower bytes of the vector space for FRAM soft fuse passwords, and mspgcc's linker scripts assumed the area could be safely overwritten.

There's probably also a non-mspdebug solution somebody else could describe.

Recently, the CCS linker scripts have been changed for exactly this reason, so that the JTAG password is no longer part of any interrupt vector or code segment. IIRC it got its own segment, so you can’t accidentally overwrite it anymore. However, this has shifted the vector offsets, and older projects (new header files from the compiler but old linker scripts in the project folder) didn’t work anymore.

Edit: note that this change happened for CSS. I don't know whether a similar change has been done for MSPGCC. Seeing Peter's reaction, it is apparently not the case.

This is the sort of mis-information presented with false authority that really gores my ox.  But what the hey, let's get into it.

For historical reasons, mspgcc modeled the vector space as a single linker section containing 16, 32, or 64 word values depending on MCU. It initialized the entire space, using the address of a fallback handler when the application didn't provide a specific handler.  It identified peripheral-specific entries using an offset from the MCU-specific base address of the vector table (0xFF80, 0xFFC0, 0xFFE0), rather than the absolute address used in CCS (and I presume IAR).

This model broke in 2011 with the introduction of the FR57xx family which put soft fuse passwords around 0xFF80, memory that the datasheets still (slas639j table 6-1) describe with the note:

Reserved interrupt vectors at addresses [sic] are not used in this device and can be used for regular program code if necessary. To maintain compatibility with other devices, it is recommended to reserve these locations.

Because that memory is used (for soft-fuse passwords), the value of the fallback handler address in mspgcc-compiled applications on FRAM devices could make mspdebug and CCS's flashing tools emit a diagnostic and refuse to re-program the board.  Recovery methods were identified that involved using BSL.

In July 2012 I discovered that some values would even prevent BSL from working, which ultimately led to public cognizance of the presence of these passwords, which was the underlying cause of this major headache.  A fix was implemented in the 20120716 release of mspgcc by recognizing that no MCU ever used the first 32 entries of a 64-entry table, and so those entries were initialized to 0xFFFF in the table written to the interrupt vector section.

This solved the problem, for a while.  Then in early 2013 TI released a new set of headers, which changed the header offsets so they were based at 0xFF90 instead of 0xFF80 and so introduced a 56-element vector table.  This completely broke mspgcc's model, leading to https://sourceforge.net/p/mspgcc/bugs/349/.  While I implemented the compiler changes necessary to support 56-element vectors, I never published them because we had expected the first msp430-elf releases to be available that spring, the fix required a new release of the toolchain that would be backwards incompatible with existing object files, and I was tired of putting a buttload of unpaid effort into an end-of-life system.

To my knowledge, CCS and msp430-elf and presumably IAR all identified vector table entries by absolute addresses and used separate linker sections for each entry.  As such, they were never affected.

Peter Bigot said:

I'm unaware of any way mspdebug would brick the device.  It only happened in mspgcc because TI started using the lower bytes of the vector space for FRAM soft fuse passwords, and mspgcc's linker scripts assumed the area could be safely overwritten.

Jens-Michael Gross said:

Recently, the linker scripts have been changed, so that the JTAG password is no longer part of the interrupt vector or code segment. IIRC it got its own segment, so you can’t accidentally overwrite it anymore. However, this has shifted the vector offsets, and older projects (new header files from the compiler but old linker scripts in the project folder) didn’t work anymore.

So, nearly everything in this follow-up is wrong in fact or in implication.  It was a shift in vector offsets that prevented the problem from ever receiving a proper fix.  Other than that it wasn't recent, at least some data sheets still don't separate a signature area from the vector table, there's no evidence it ever affected any toolchain other than mspgcc, no solution involved changing linker scripts, and no sanctioned combination of mspgcc toolchain components since 20120716 would have re-introduced the problem.

Peter Bigot said:

there's no evidence it ever affected any toolchain other than mspgcc, no solution involved changing linker scripts, and no sanctioned combination of mspgcc toolchain components since 20120716 would have re-introduced the problem

I remember suggesting some sort of verification mechanism, so that the linker can identify whether header files used and linker script in use do fit together. In order to generate a 'telling' error message.

But you're right,  this wasn't related to GCC and I apologize for mixing this in. Apparently I missed the 'GCC' in the topic when writing my previous reply.

Thanks for the clarification.  The change you mention was apparently introduced in CCS 5.3.0 (released Nov 26 2012), and is probably why the MSP430FR5739 assembly language examples were wrong as recently as a couple weeks ago.

In this case TI shot itself, since there was no reason why the base address needed to change: because they use a different region/section for each entry, they could have simply renamed/resized the memory regions corresponding to the signature range, leaving the old ones unmodified.

So... one of the things I liked about mspgcc was that it gave me an out-of-the-box working development environment. It looks like that if I build my own gcc, then I don't get that.

Can anyone point me at a set of guaranteed non-breaking linker scripts and headers that will work on the FR5969? I don't particularly care about a libc, as I'm intending to write bare-metal stuff, but I do want to make absolutely sure I don't wreck the thing.

Hi David,

If you want an out-of-the-box working environment for msp430fr5969 launchpad you can try CCS v6.

CCS v6 support the new ti gcc 4.9, it is a professional enviroment, free without size limits if you use gcc.

If you prefer a dev environment with mspdebug it is feasible, but with some effort.

See for example http://www.colotronics.blogspot.com.ar/2014/08/msp430-toolchain-in-ubuntu-1404-with.html

greetings

Attilio  

Thanks, but CCS is of no interest to me.

David Given said:

This change went in in 2014-01-30; the most recent version of gcc before than was 4.8.2, but that dates from October 2013. Will this predate the msp430 code generator?

Yes.  If you want to build from upstream sources use the trunk versions of gcc and binutils.  The git revisions identified at http://pabigot.github.io/bsp430/releases.html work.