MSP430FR2632: Spy-bi-wire locking up

Hi bo,

It might be a timing issue.

Not sure what document you are following for the SBW protocol but you might want to check you are not violating some specification.

Do you have a logic probe or oscilloscope to verify the signals and timing?

Here is MSP430JTAG Programming Interface that might provide some additional information.

And how you reading / writing small / alot data to target device? slau320 / replicator or something else? Maybe this can help...
forum.43oh.com/.../

Hi Dennis,

I am looking at slau320ad and www.ti.com/.../msp430fr2632.pdf for memory address references.

I have a logic analyzer and oscilloscope. On a small transmit time scale, I don't see any issues. However it is much harder to verify on a bigger scale. Do you guys have any debugging tools that can be used to decode logic analyzer data to determine if there is a bug or error somewhere?

Hey I am indeed looking at slau320ad and www.ti.com/.../msp430fr2632.pdf.

As far as timing issues are concerned, I am only aware that you cannot hold TCLK low for greater than 7us or else the MSP430Fr2632 would go into reset. In addition, I am pulsing the clock signals at 3us similar to the 5 NOP cycles at 18mhz you have in the examples.

I am monitoring the transfers on a logic analyzer that I have hooked up to TST and RST. Do you have any debugging software that would help me decipher the stream of transfers to determine if there is a problem? I can only look at macro-structures in the timing graph to see that it is not going into reset but it is a little harder to see if anything else is not working correctly.

I did see this too. I am using 2 wire Spy-bi-wire so doesn't seem very useful.

Hi bo,

I'm not aware of any specific tools (hardware or software) to debug the SPY-BY-WIRE protocol. Our tools team in Germany may have some suggestions. Let me check with them.

When you are successful to write small amounts of data, what memory locations are you writing to?
When writing larger amounts of data, is there a possibility you are accessing a non-existing memory location?
How much data or what is the size of the image you are attempting to write?

From my read of the manual(www.ti.com/.../msp430fr2632.pdf), it shows on page 67 of the manual that the memory address space of MSP430FR2632 starts from 0xe000 and stretches to 0xffff. This corresponds to 8kb worth of memory.

I've generated the hex from code composer and output file is of this structure:
@<address of segment 1>
BYTE_1 BYTE_2 BYTE_3 ....
@<address of segment 2>
BYTE_1 BYTE_2 BYTE_3 ....
After parsing this file, I try to program in the various segments by combining every 2 bytes and writing them out starting from the address of the segment.

Therefore, given a simple segment:
@e000
01 FF 00 00 86 22 ..
I would write 0x1ff to address 0xe000, 0x0 to address 0xe0002, 0x8622 to 0xe0004 and so forth.

The size of the first segment is 7224 bytes and starts from 0xe000. 0xe000 + 7224bytes is 0xfc38 and that segment is less than 0xff80 which is the location of the interrupt vectors and signature FRAM area. The next segment starts from 0xff80 and is 8 bytes. This corresponds to JTAG signature 1 according to table 6-2 of www.ti.com/.../msp430fr2632.pdf. The last segment is at 0xffd8 and is 40 bytes this is for CapTIvate interrupts.

Ergo, I don't think i am writing to a nonexistent memory address location but I could be wrong (please enlighten me if my read of the manual is wrong)


When I am writing smaller amounts of data, I have tested random areas of the FRAM address space to ascertain whether there are problems but so far it seems like it is more of a timing issue that a memory issue.

Is there a way we can tell if the device has gone into reset perhaps by probing an MSP430 IO pin?