Forums

Hi Dung,

The linker/memory problems have been fixed. But the MSP430F5438A will only program with JTAG now. This problem seems to be an immediate result of these fixes.

I've attached the most recent project which programs with JTAG on an EXP430F5438, but no longer programs with Spy-by-Wire (Error: Unknown Device).

Thank you

Russ

Russell Lemburg

I've attached the most recent project which programs with JTAG on an EXP430F5438, but no longer programs with Spy-by-Wire (Error: Unknown Device).

When I build that attached project, the reset and timer interrupt vectors are now set correctly in the executable.

Failure to program can be caused by a program running which crashes the processor before the debugger has a chance to attach to the device.

The following code initializes the Unified Clock System:

void initClocks(void)
{
UCSCTL0 = 0x1F00; //DCO and MODulation registers (see p. 50 of chip datasheet) DCO=31, MOD=0
UCSCTL1 = 0x0040; //DCO table for selecting clock ranges on p. 50 of Chip Datashseet DCORSEL = 4
UCSCTL2 = 0x02DC; //DCO multiplier Divide by 1, multiply by 732
UCSCTL4 = 0x0333; //Clock source is DCO for ACLK, SMCLK, MCLK
UCSCTL5 = 0x0550; //Clock divide source (set MCLK to /1, set SMCLK and ACLK to /32)
UCSCTL6 = 0x01DC; //Set up maximum capacitance for XT1, LF mode, turn off XT2
}

It is not commented what frequency crystal is connected to XT1, but assuming a standard XT1 32768Hz crystal that means the MCLK is set to 24MHz. On a MSP430F5438A to allow reliably operation with a MCLK of 24MHz, the PMMCOREV level must first be raised to 3 (see the Recommended Operating Conditions section of the MSP430F5438A datasheet). Looking at the attached code I can't see anything which writes to the PMMCTL0 register. As a result, when initClocks runs to set the MCLK to 24MHz the PMMCOREV will still be at the power on default of zero and the processor will probably crash.

Chester Gillon

assuming a standard XT1 32768Hz crystal that means the MCLK is set to 24MHz.

This is in a risky range even with the correct PMMCOREV setting. Since the DCO mos tlikely won't have the exact frequency available, it will modulate for an average between a higher and a lower frequency. And the higher one could be (worst case) above the allowed maximum.
With a real 24MHz crystal, there is no modulation and 24MHz are no problem.

Chester Gillon

It is not commented what frequency crystal is connected to XT1

On further investigation the code isn't actually selecting an external XT1 crystal since:

a) I can't see any code which is selecting P7.0 / P7.1 for the XIN / XOUT module functions, and thus the pins will be I/O.

b) The write to UCSCTL6 sets XT1BYPASS bit.

When the initClocks code was tried in a MSP430F5510 (same UCS and DCO Frequency Ranges as a MSP430F5438A) the resulting MCLK was ~20MHz. The XT1LFOFFG and DCOFFG flags were set (DCO bits were maximum of 31). Presumably the device is using the UCS Fail Safe of souring FLLREFCLK from the REFO.

We're not using an external crystal, because we do not need very high precision. Is this somehow related to the Spy-by-Wire issues we're having? Perhaps it's related to the frequency difference between 2 and 4-wire JTAG? Quite bizarre.

Russell Lemburg

We're not using an external crystal, because we do not need very high precision.

OK, can you clarify what frequency you want MCLK to be. Is it 24MHz derived from the internal REFO?

Russell Lemburg

Is this somehow related to the Spy-by-Wire issues we're having?

Using the initClocks() function I created a test program in a MSP430F5510 (haven't got an actual MSP430F5438A to try - the MSP430F5510 has the same UCS module and DCO frequencies). With the PMMCOREV set to the default level of zero (VCORE measured at 1.4V) then the program didn't crash and I haven't had any debug failures when using a MSP-FET430UIF connected by Spy-By-Wire. i.e. suspect your failures are caused by some other problem, but I don't know what. 

I am getting the same error for .cinit not being able to fit.  NOTE: I am using CCS v5.3.0.00067 (RC1) and targeting MSP430F2618.

"../lnk_msp430f2618.cmd", line 94: error #10099-D: program will not fit into available memory.  placement with alignment fails for section ".cinit" size 0x7d .  Available memory ranges:
   FLASH        size: 0xcebe       unused: 0x0          max hole: 0x0       
error #10269: output file "xyz-trunk-codecomposer.out" exceeds code size limit

It looks like the FLASH section is getting filled first.  I tried putting all FLASH sections before any FLASH2 sections but got the same result.

I then tried replacing the ">> FLASH | FLASH2" with "> FLASH | FLASH2".  The error about .cinit disappeared, but still getting code size limit errors.

error #10269: output file "xyz-trunk-codecomposer.out" exceeds code size limit

So what does the >> symbol do, and why is it only used for the .text section ??  I can't find any documentation that describes it :(

OK, found it here:

http://www.ti.com/lit/pdf/slau131

The >> is used for automatically splitting the section into different areas of a memory region, or across multiple memory regions.

Now off to find out why my code (ported from IAR) doesn't fit .....

Brendan Simon

So what does the >> symbol do, and why is it only used for the .text section ??

The >> symbol controls "section splitting". For documentation see section 7.5.4.7 Automatic Splitting of Output Sections Among Non-Contiguous Memory Ranges of the MSP430 Assembly Language Tools v 4.1 User's Guide SLAU131G

See also MSP430 linker reports "error #10099-D: program will not fit into available memory" even when there is space

^{I had a similar problem, I'm using an MSP430F5419 with 128K of memory.  The ">>" didn't seem to work, it should have split the code ".text" but didn't, the two Flash segments are separated by the interrupt vectors, my code is reported to be 42.342K and the lower Flash "FLASH" is 41.856K it gave me an error about ".cinit" possibly since it was linked after the code.  Since FLASH2 on my chip is 89.088K I just changed the command to ".text      : {} > FLASH".  I don't know why the linker reports the wrong section or why the ">>" command didn't split my code.  I was using the Large Memory model so I didn't think there would be a problem.}

Mark James

 I was using the Large Memory model so I didn't think there would be a problem.

THis isn't important for the linker. It just controls which kind of call/ret instructions the compiler generates (16 or 20 bit). The init code, since it is reached through the reset vector, needs to be in low memory. And it is placed after your code because it is loaded from a library while youre code is loaded from explicitely given object files. Also, you don't use large memory model, so it may be (and that's just guessing) that the linker script in this case will put the init values for your global variables into lower FLASH too. Since this section is placed after all global and static variables are collected, it is too placed after your code.

You can explicitely put some of your functions into FLASH2 by putting the proper pragmas into the source code.

Sure, teh linker could do a multi-pass run and optimize placing with the results from the first failed pass (that's actually what you do when thinking 'the linker should...') but it hasn't been designed this way.