SPI and UART of MSP430F5438

Thanks Jens-Michael for you elaborated reply.

I would like to verify few more issues:

1. Does working with SPI clock of 2MHz still require a very optimized C code? Can we give pointer to a buffer or each word is handeled seperately? Do you have code sample?

2.Regarding the CS line. It looks like our slaves work in 16-bit words. However the msp430f works in bytes (8 bits). How is that solved? How does the CS signal behave? In the data sheets we saw the msp430f raise the CS line after 8 clock pulses, but the slave wants it down for 16 pulses. Both chips claim to support SPI. Is it not a standard?

3.What is the maximum UART rate and throughput?

Thanks you very much,

Rafi

Good questions. There' sno definitive answer, it all depends on the surrounding conditions.

1) if your MCLK is 16MHz and your SPI clock is 2 MHz, you have 64 clock cycles for checking whether TXBUF is empty (for putting next byte to send or dummy byte for receive in) and checking whether a byte was received and storign it away. It is still not much time and definitely not enough for letting in ISR handle this. But it should work.

The main advantage of SPI is that YOU clock the slave. That means, if you delay putting a byte into TXBUF, the slave won't send anything into your RXBUF. So if your code is too slow, throughput will decrease, but unless you make something terribly wrong, you won't lose data.

2) CS line is (at elast with all slaves I know) initiating and ending an SPI transmission. If CS goes high even within an SPI transmission, the slave should abort the current command and with the next CS transition to low, the slave should be ready for a new run as if nothing happened. If you use one CS line for several slaves and they are connected to different SPI lines (clock/data), all will be ready for duty, but only those who get an SPI clock signal will output data. The others will just go back to sleep when CD gets high again. So you can select up to 8 (the 5438 has 8 SPIs) at once and get data from one to 8 just as you wish, even with different clocks and asynchroneous.

SPI transmissions are in 8 bit chunks (bytes) but can consist of any number of bytes. MMC cards e.g. receive a block read command, the address, then send (still with CS low)  a number of FF bytes while the internal controller fetches the data from RAM, then a SYNC byte that is not FF and then 512 bytes of data. All with CS low. And if you're satisfied after getting the first 256 bytes or so, simply put CS high and the rest is swallowed.

There are other SPI slaves (e.g. D/A converters) which allow daisy-chaining. This means you clock in your data into their input shift register from below and the shift register will output its upper bit at teh same time to the next device. All are selected with once CS line. When CS goes high again, they will take what is in their shift register at this moment. So you simply pass the first byte you send to the last device in the chain and the last byte is taken be the first device in chain.

So you are not required to raise CS after 8 clock pulses. You rais it when the transmission is finised - how many bytes you send/receive depends on the slave.

Note that if you want to receive a byte, you need to send a byte, because sending and receiving is synchroneously and the clock pulses are generated when putting something to send in TXBUF.

Also keep in mind that the send buffer is double buffered. So if you put a byte into RXBUF, it will (on idle SPI) immediately be forwarded into the output shift register and TXBUF is empty again. you can put the next byte into it right away. When the byte in the shift register has been sent, the byte in TXBUF is moved into the shift register without delay, leaving TXBUF empty again. At the same moment, the received byte in moved into RXBUF (maybe 1/2 clock pulse later, depending on phase setting). But now you're under pressure to fetch this byte from RXBUF since the next one is already being clocked in by teh TX byte that was just moved into the output shift. And 8 SPI clocks later the next byte is ready in RXBUF. If you wait with writing into TXBUF after your read RXBUF, you have plenty of time, but also you lose throughput as SPI transfer is stopped until you put the next byte into TXBUF.

For this reason I implemented DMA transfers for larger data blocks. Will only work with USCI0 and 1, not 2 and 3 as there are no DMA triggers for USCI 2 and 3. Also only one SPI can be handled by DMA at the same time, as it requires two DMA lines (one for RXBUF, one for TXBUF) and the 5438 has only three. If only sending on SPI or sending OR receiving on I2C/UART, three could be handled at once. But since you don't know how many bytes have been received already, using DMA for continuous receive into a buffer is no good idea. Only if you exactly know how many bytes are to expect and you wait for the complete transfer to be finished.

3) for SPI, there is Fsystem as maximum clock. I didn't time it oput but it seems that this is also the maximum SPI clock (=16MHz on the non-A versions of the 5438). Would be nice. I2C is limited to a maximum of 400kHz as bit clock but can be fed by Fsystem too. In UART mode (asynchroneous operation), the maximum bit clock is 1MHz, and the maximum input clock is Fsystem too. But you shouldn't go higher than source/16 if you want the oversampling features for better synchronizing to the incoming bitstream. If you have the Source clock (e.g. SMCLK) running at 1MHz and use an UART bitclock of 1MHz, then incoming bits must be come with exactly 1MHz or chances are that the UART cannot properly receive them. With 1/16 divider, the UART can resync to the bit edges by 1/16 of bitclock, allowing a much higher tolerance for receiving.

So in theory, the absolute maximum SPI throughput is 2.000.000B/s (16MHz/8bit), for UART it is 100.000B/s (1MHz/10 bit) and I2C it is 44.444B/s (400kHz/9bit). Still you need to be able to handle these data rates in your software.

Thanks again Jens-Michael Gross,

refering to your answer number 2: I understand I can control the low duration of the cs line of the msp430f5438? I thought SPI is a fixed hardware module.

refering to your answer number 3: I wondered about the output throughput (transmit) of the UART module. We are waiting for a code from TI that suppose to output to a bluetooth module (of Panasonic) throughput > 500Kbps.

Do you see a problem in designing a system with msp430f5438 that receive data from sensors via 1M SPI and transmit it via 1M UART?

Thanks,

Rafi

The dedicated CS line of the SPI module is only used in slave or auto-master-slave mode. Then it controls the SOMI pin (it is high-impedance as long as CS is HIGH and set to putput if CS goes LOW) and the acceptance of clock signals by teh shift registers.

If you're the master, it is not needed/used at all. For the other devices you can use ans I/O pin as CS pin. YOu set it to low when you start transmission and high again when you're finished. The SPI hardware is very simple and does not know when you intend to end a transmission. (other than the I2C protocol/hardware that has dedicated start/end patterns and addressing)

The Throughput of the UART module is limited, however, UART means "Universal Asynchroneous Receiver Transmitter" and refers to the RS232-like serial transmission mode of the USCI module. In this mode, certain limitations apply so the asynchroneous transfer can be synchronized with the (unknown since not transmitted separately) bit clock etc. Thus the limitation to 1MBd. And then you should clock it with precise 16MHz (quartz based, and no low power modes used that will stop the quartz)

In SPI mode, the USCI module works synchroneously and there shouldn't be a problem operating the module at much higher speed. Provided the clock and data lines are short and with low capacitance, it should work with Fsystem. On my experiments, I was able to send and receive 512 byte bursts with 16MBd, using two DMA lines for send and receive. I didn't have any hardware attached, just connected SIMO and SOMI, so SCLK didn't count. Maybe in a real world setup it might be too fast. Anyway, on an ATMega128 with ~16MHz clock I used its hardware SPI module to interface an SD card with 8MHz SPI clock without problems. Due to the lack of a DMA controller, the effective data transfer rate was about 400kb/s. On the MSP with DMA, it _should_ run bursts with no delay.

Anyway, keep in mind that you need to handle the data, so 1MBd burst speed shouldn't be a problem, continuously receiving/sending with 1MBd surely will. And do not forget that 1MBd on UART is base don 10 bit per byte (= 100kB/s) while on SPI it is based on 8 bit/Byte (=128kB/s).

And if you just want to forward SPI to UART, you'll probably need some double-buffering (unless you make a very exact timing), that will cost even more processor load. You cannot use DMA for this purpose, as DMA only works with fixed, predefined sizes and you do not have a counter that tells you how much of a block has been transmitted already. So you'll have to go back to byte-by-byte transmissions and then DMA is mostly useless, since polling the DMA registers takes as much time as polling the UART/SPI registers manually.

If the timing is exactly balanced, there could be a setup possible that automatically stuffs every incoming byte from SPI into the TX register of the uart. So you could automate the process up to the point where no CPU action is needed at all, putting the transfer completely into the background. This should work best if the MSP is set to be slave, so the bytes are clocked into SPI when available from outside. Else you still must provide data to SPI TX to make it clock the data in. You cannot automate if the transmission shall be bidirectional, because then interpretation of the SPI data is necessary for the incoming/outgoing data flow.

What wil work or not depends on the external hardware and your imagination.

Thanks Jens-Michael Gross,

Do you have sample code for UART to USB for the "MSP-EXP430F5438 Experimenter Board"?

Do you have sample code for SPI?

Thanks again,

Rafi

Sorry, I don't have the experimenter board. My experience with the 5438 is fairly new, I have only the PS5X100 testboard (just a processor socket and some pin rows, no hardware on it).

My UART code is too much modularized (1 to 2 or 4 UARTs etc., it will compile for Atmel, MSP5438 as well as for MSP1611) so I cannot give you a working example without giving you the surrounding project skeleton too. And I doubt my boss would appreciate this :)

SPI is really straight. Once you configured the controller for clock speed, phase and bit oriientation, you only have to stuff bytes into TX and pull from RX buffer.

void SpiInit (unsigned int speed) {
  UCA0CTL1 = UCSWRST;
  UCA0CTL0 = UCSYNC|UCMST|UCCKPL;
  UCA0CTL1 |= UCSSEL_SMCLK;
  UCA0MCTL = 0;
  UCA0BR0=speed;
  UCA0BR1=(speed>>8);
  UCA0CTL1 &= ~UCSWRST;
  return ;
}

This function initializes the hardware. Speed is actually a divider for the system clock.

The data transfer is absolutely simple. Before startign any transfer, pull the CS line (whichever I/O-Pin you assigned for this) low, after done with the transfers, push it high again. In between, the following functions should be useful:

extern inline unsigned char SpiSendReceiveByteWait(const unsigned char data)
{
  unsigned char i;
  i= UCA0RXBUF;  // dummy read to reset UCRXIFG (you could also manually clear UCRXIFG I think)
  // Start transmission
  UCA0TXBUF = data;
  // Wait for transmission complete
  while(!(UCA0IFG&UCRXIFG));
  return UCA0RXBUF;
}

This one sends a byte and at the same time receives a byte, delivering this byte back as return value. SPI is bidirectional. While you send a byte, you receive a byte. If you only want to receive a byte, you have to send a dummy byte, and if you want to just send a byte, you'll receive a dummy byte. THis function does both, but since it returns after the byte has been sent and one has been received, it wastes much time for larger transfers. But for a successful SPI communication is is all you need.

it is defined as extern inline, so the compiler might compile it drectly into your code instead of calling it as a subroutine. This way, its optimizing features might shrink the code even more than with a subroutine call, as the parameters can be transformed to immwdiate values instead of being loaded into a register, clobbering it, etc.

If you need more speed and don't want to waste too much time waiting for a return byte you don't need, use these macros:

#define SpiSendByteFirst(x) do{UCA0TXBUF = x ;} while (0)                         // reset UTXIFG0, send first byte
#define SpiSendByteNext(x) do{ while(!(UCA0IFG&UCTXIFG)); UCA0TXBUF = x; } while(0)
#define SpiSendByteLast(x) do{ while(!(UCA0IFG&UCTXIFG)); UCA0TXBUF = x; while(UCA0STAT&UCBUSY); } while(0)  // do not wait for UCRXIFG0, it is not clear here

The first one starts the transfer.It does not check whether there is still a  byte sending. all subsequent bytes except the last are sent with the middle function. It waits until the transmit buffer is ready for reception of the next byte, then 'returns'. The last byte should be sent with the third macro, as it waits until really all data has been sent.

The do{}while(0) construct ensures that the macro will expand to a single C block statement, even if used behind an if() statement without brackets. So you can use it like any function.

The opposite of this is

#define SpiReceiveByteFirst(x) do{ UCA0TXBUF = 0xff; } while (0)                                     
#define SpiReceiveByteNext(x)  do{ while(UCA0STAT&UCBUSY); (x)=UCA0RXBUF; UCA0TXBUF=0xff; } while(0)                                      
#define SpiReceiveByteLast(x)  do{ while(UCA0STAT&UCBUSY); (x)=UCA0RXBUF; } while(0)

Here, the first initiates reception of a byte by sending a dummy byte, the next one waits for reception, then sends another dummy byte, the last one just waits for the last byte has been sent (and therefore a byte has received) and returns the received byte into the passed lvalue. Note that here the macro does not behave like a function. Its parameter must be an lvalue, that means a variable name or a dereferenced pointer where the macro can write something to. A constant or a pointer/reference will produce an error.

You see it is very simple to use SPI.

This is not really optimized code. Since sending is double-buffered (one byte in TX buffer, one byte in output shift register), one could put another byte in buffer while the last one is still in the output shift register. But then you had to stop interrupts, as an IRQ between stuffing the next byte into TXBUF and reading the result of the actual transfer would result in a receive overflow and also break the chain. Since disabling and enabling IRQs adds to execution time too (and saving current IRQ state on stack, so you can use the code inside ISRs, requires assembly language), it makes no real difference. It only makes sense when transfering a bunch of data at highest speed (e.g. from a memory device like an MMC/SD card or an external flash memory chip), and I developed a block transfer function using DMA for this purpose. So I didn't see a reason for further optimization.

Thank you very much Jens-Michael Gross. You helped us a lot.

We implemented your code only we used UCB0xx instead of UCA0xx like you did. Thus we removed the  UCA0MCTL = 0; in the init method as it is not available for B0.

We didn't see any activity on the SPI lines (we checked the clk line for example). What do we need to do in order to see activity?

thanks,

Rafi

Did you enable the port pins for module activity? (PxSEL=y) Since my code modules are designed for maximum portability and associated port pins are different even on processors with identical hardware modules, I didn't include the port initialisation into the init function. (the original code supports all 8 SPIs through enumeration parameter)

It might be necessary to set the SIMO and SCLK pins to output too. Some modules do require this (I don't remember for the USCI) and so I always initialize the ports that way at system startup. While the firmware is modular and used across projects, the hardware is project dependent and so is the port initialisation.

For selecting the slave, you'll also need to use any I/O line as CS signal and set it to low to tell the slave that it is selected and clock pulses are valid.

Don't select the STE line associated with the SPI with PxSEL. If you do, it will put the SPI into slave mode once low, at least in 4-wire SPI mode. The SPI hadrware will not control any CS line for slave selection, when in master mode. The hardware doe snot knwo when a new transfer startd and how many bytes it will be. It's up to your main code to manage this. Since the slave chip select is of no meaning to the SPI module, you should see activity on SIMO and SCLK without it as soon as you put something into the TX register. But of course it is necessary for any real communication.

Thanks Jens-Michael Gross. You have help us a lot.

We would like to output two clock signals: 250KHz and 1MHz from the MSP430F5438.

We understand it can be done without interrupt routine, only by configuring dividers for MCLK , SMCLK or ACLK and routing them to some port pins.

We would appreciate if you could instruct us (C code).

Thanks,

Rafi

Indeed, you can output all three system clocks to port pins.

{P2DIR|=1;P2SEL|=1;} will output the current MCLK to P2.0 (pin 25).
{P11DIR|=2;P11SEL|=2;} will output SMCLK to P11.1 (pin 85).

{P1DIR|=1;P1SEL|=1;} will output ACLK to P1.0 (pin 17).
{P2DIR|=0x40;P2SEL|=0x40;} will output ACLK to P2.6 (pin 31).
{P11DIR|=1;P11SEL|=1;} will output SMCLK to P11.0 (pin 84).

{P4DIR|=0x80;P4SEL|=0x80;} will output SMCLK to P4.7 (pin 50).
{P11DIR|=4;P11SEL|=4;} will output SMCLK to P11.2 (pin 86).

Depending on clock sources and dividers you'll get the required frequencies.

You can also generate a clock signal by using the timer(s). Clock the timer from e.g. SMCLK (assumed 1MHz), setting TAxCCR0 to 3, TAxCCTL0 to up mode, toggle, will output 250kHz at P1.1 or P8.0 (TA0.0) or P2.1 or P8.5 (TA1.0). You can also use TimerB with output to P4.0 (TB0).

Thanks Jens-Michael Gross.

Reffering to the first half of your reply - how do we configure the dividers of MCLK,ACLK and SMCLK?

thanks again,

Rafi

I strongly recommend reading chapter 3 of the users guide slau208. It explains the usified clock system module in detail.

On the 5438, the dividers are defined by setting the appropriate bits in the UCSCTL5 register. You can set them to divide the assigned oscillators frequency by 1,2,4,8,16 or 32. You can even set an additional  divider for the external ACLK output pins (DIVPA) that will output only a fraction of the internal ACLK to the pins.

Thanks again Jens-Michael Gross.

I got there and managed to output the desired clocks (divisions of SMCLK sourced by several options I tried).  The trouble is they are not stable.

What is the most stable configuration (source + dividors/multipliers) for creating 1MHz and 250MHz in your opinion?

Thanks again,

Rafi

What do you mean with 'not stable'? Wrong frequency or frequency drift or both?

The stability of the clock outputs solely depends on the stability of their oscillator source. They are just digitally controller dividers for thir input clock (you can even drive them by an external clock of your choice, abusing them as pulse dividers/flipflop stages.) So if you see instability, it is their oscillator source that is instable.

If you use plain DCO as source, it has a large tolerance and a large temperature coefficient.

If you use FLL stabilized DCO, then the long-term stability of the oscillator matches the one of the reference (usually internal 32kHz oscillator or even external 32kHz clock crystal). However, its short-term stability is not es good as the FLL adjusts the DCO based on its frequency in relation to the reference. So DCO jumps between 'slightly too high' and 'slightly too low', matching the desired value in the average. This adjustment is done every reference clock pulse. If you enter low power modes which turn off the clock sources, all calculations are void, as it takes a relatively long time before the DCO reaches its operating area again.

If you use an external quartz crystal as oscillator for the clocks, you'll need to ensure that it is running peroperly (else your clock will fallback to unstabilized DCO) by clearing the OFIFG bit and ensuring it stays cleared for >50ms. Then you can switch your clocks (SMCLK etc.) to the LFXT1 or XT2 oscillator and enjoy the most stable clock you can get, with excellent short-term stability and good long-term characteristics (you can increase them by applying controlled heating to the quartz, keeping it at a higher, but constant temperature than the environment, so you eliminate the temperature drift.

I have no problems with an internally FLL stabilized DCO running at 16MHz and clocking the USCI modules for stable 115200Bd transfers. On other MSPs I used 8MHz quartz for the same purpose.

How much effort you should make depends on your exact requirements.

Thanks.

I meant that the phase of the clock is not stable (observed by oscilloscope). The signal jitters in time.

How can I be sure the FLL is indeed working. This is my code:

UCSCTL2 &= 0x9c00; // sets D=1,N=1 for FLL deviders

UCSCTL3 &= 0xff08;  //select XT1CLK as FLL reference and divide it by 1

UCSCTL4 &= 0xff0f; 
UCSCTL4 |= 0x0030;   //select source for SMCLK  as DCOCLK

P4DIR|=0x80;
P4SEL|=0x80;        //will output SMCLK to P4.7

thanks,

Rafi

First, before you use XT1CLK as clock source, you'll have to ensure that LFXT1 is running stable. The detailed procedure is in the users guide. If LFXT1 failes or is not running, the FLL will be clocked by REFO instead, which of course isn't as stable as the crystal (still much better than the DCO alone).

The FLL will adjust the DCO, if necessary, every XT1CLK tick. The base algorithm is to count the number of DCO ticks during two XT1CLK ticks and adjust the DCO by one step if the count is lower/higher than it should be. 
Also, since the number of possible DCO settings is limited, there's a modulation setting that will switch the DCO between its current settign and the next higher setting for a given pattern. This modulation is most likely the cause of the jitter you observe:
Over a period of 32 clock cycles, DCO will be set to the next higher setting for 0 to 31 clock cycles, causing a clock speed increase of 2 to 12% (factor between two DCO settings) for 0 to 31 of the 32 clock cycles, evenly distributed. See figure 3-2 of the family users guide.

So using the FLL will give you a fairly stable average frequency, but the phase jitter of the clock can be up to 12%.

You can try to extract the current DCO values determined by the FLL, disable FLL and manually set them. And then check phase jitter again. If it is cause by the FLL, it should be gone then, but the frequency might be off and the final values depend on the actual device. You can enable FLL, let it adjust the frequency, then disable FLL and live with temperature drift and the ferquency error caused by the limited number of DCO steps.

Or add an high-frequency crystal and take MCLK and SMCLK from there. It will give highest precision and remove all phase jitter. At the cost of, well, increaed cost :)

Thanks jens-Michael Gross.

You are right. The modulation was on. Also the reason the dividers didn't work is because I didn't set the DCO frequency range correctly.

How can I extract the DCO steps to minimum. I prefer inaccuracy over instability.

Is it the DCO bits in UCSCTL0?

Thanks,

Rafi

Yes, you'll need the DCO bits in UCSCTL0 and the DCORSEL bits in UCSCTL1.

If you disable modulation, you don't see any clock jitter anymore. You should be still able to use the FLL, resulting in a frequency change every 1/32768s., keeping the average frequency on the correct level. If you disable FLL too, you'll have temperature drift and device-dependent variations in frequency. You can stretch this adjustment interval by settign FLLREFDIV in UCSCTL3. (and of course increase the FLLD and/or FLLN bits in UCSCTL2 acccordingly)

You can turn FLL on at startup and then turn it off after a certain time. It should have settled (with modulation off) after 32/32768s = ca. 1ms. Once FLL is turned off, the DCO will continue with the last setting.

There are, however, some issues with writing to the FLL registers and the DCO settings. See the errata sheet of the 54xx. Else the whole thing won't react as expected.

thanks again for the great help.

I thought it was behind me but when I integratet those lines (please see at the end) in our code, the phase has started jitter again. I saw there was no change in the UCSCTLX registers. the line that caused the jitter is (surprisingly) P8DIR = 0xFF;

I output the clocks from P4.7 and P11.0 so there is no connection to P8.

thank again,

Rafi

The clocks code is:

//1MHz to P4.7 
UCSCTL1 =0x0031; //disable modulation,frequency range 0.64-1.5MHz
UCSCTL2 =0x0020; //N divider of FLL is 32
UCSCTL3 =0x0002; //select X1 as ref to FLL and divide it by 1
UCSCTL4&=0xff0f;
UCSCTL4|=0x0330; //unsure DCO->SMCLK and DCO->ACLK
P4DIR|=0x80;
P4SEL|=0x80;    //will output SMCLK to P4.7

//250KHz to P11.0
UCSCTL5&=0xf0ff;
UCSCTL5|=0x0200;//divide ACLK(1MHz) by 4
P11DIR|=0x01;
P11SEL|=0x01;   //will output ACLK to P11.0

That's weird. The P8 pins are only attached to P8, TA0 and TA1 CCR outputs. There's nothing that could do a feedback/distortion and cause a jitter on the other clock signals.

You should post both versions of the code (with P8 and without) and a detailed description (an oscilloscope screenshot is nice), so a TI employee can take a look at it. Maybe you discovered a silicon bug.

Thanks again.

Do you know where I can see what is my code size,data size and flash consumption?

I'm using IAR.

Thanks again,

Rafi

IAR can generate a map file that is an ASCII text file indicating memory resource consumption, etc.

Thank you very much.

I just want to verify something regarding the A2D of the MSP430F5438. What is the maximum sampling rate?

Can I get 500KHz at some version of the chip (maybe with the "A" suffix. If I used it - are there any differences to the regular  MSP430F5438 I should be aware)?

Thanks,

Rafi

BrandonAzbell said:

IAR can generate a map file that is an ASCII text file indicating memory resource consumption, etc.

rafi zachut said:

What is the maximum sampling rate?

maximum ADC12CLK frequency: 5.4 MHz.
Conversion time 13*ADC12CLK,
minimum sample time: 4*ADC12CLK.
plus 1 ADC12CLK for synchronizing

300kHz. One channel only.

If you only need 8 bit conversion, thr conversion time is reduced to 9 clock cycles, giving a maximum sampling frequency of 385kHz.

The A chip isn't faster, only that the internal ADC12 oscillator is trimmed a bit closer to the maximum that can be achieved with an external clock source (ACLK/SMCLK/port)

rafi zachut said:

are there any differences to the regular  MSP430F5438 I should be aware

The A is faster (max. 25MHz), consumes a bit less power, is significantly more expensive, has a replacable bootstrap loader and some different silicon bugs. And some peripherals (especially the SPI) have faster maximum speeds. Not the ADC12.

BrandonAzbell said:

IAR Systems Embedded Workbench provides documentation for the code generation tools targeting the MSP430.  The particular document to reference is the EW430_CompilerReference.pdf.  Search for "map" in Adobe will result in page 44 describing how to create this map file.

Use the "Generate linker listing" in the IDE project options, or -x on the command line.

Thanks for this detailed answer. I'm not an IAR user myself, but this question has been asked several times in the last months, so it seems to be difficult for people to find it.

p.s.: searching for 'map' requires that you already know that you have to look for this term. Also, it isn't obvious for a beginner that you'll find the requested information in a 'linker listing'.

Jens-Michael Gross said:

IAR Systems Embedded Workbench provides documentation for the code generation tools targeting the MSP430.  The particular document to reference is the EW430_CompilerReference.pdf.  Search for "map" in Adobe will result in page 44 describing how to create this map file.

Use the "Generate linker listing" in the IDE project options, or -x on the command line.