This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR2311: Writing to FRAM over JTAG

Part Number: MSP430FR2311
Other Parts Discussed in Thread: MSP430FR5872, MSP430FR5959, MSP-FET

I'm currently unable to program or verify the MSP430FR2311 over JTAG. I'm using the Replicator430FR code as reference. So far I am able to read out registers from the chip, including Device ID. However, when I try to program FRAM it has the appearance of being programmed (I can see my data being sent and the polling being done for 0xCAFEBABE from the JTAG Mailbox), but a verify or read afterwards shows that the data was not actually written. I am unsure if I am reading or erasing FRAM properly, since everything is reading 0xFF and I can't program.

The process I'm following is this: I start JTAG communication and disable the MPU (referencing JTAGfunc430FR.c and Replicator430FR.c). At this point I can look at SYSCFG register and see that data and program write protection is disabled (reads 0x9600) and the watchdog is also disabled (WDTCTL reads 0x6980). Then, I follow the WriteFram_430Xv2() function to write FramWrite_o[] from FramWriteFR4xx.c into the RAM at address 0x2000, along with the start address and length. The device is then released (per ReleaseDevice_430Xv2) and the program data sent to the JTAG Mailbox. I believe this is running correctly because I can see my program waiting to see 0xABADBABE from i_readJmbOut() before loading data and checking that it reads 0xCAFEBABE before finishing. The RAM is then cleared by writing 0x3FFF to it. But when I execute a POR and perform ReadMemQuick_430Xv2 on my FRAM (0xF000-0xFFFF) everything reads out as 0xFF.

I should note that I've been able to program the MSP430FR5872 and multiple MSP430FR59xx chips using this method, so I suspect that the issue must stem from a difference in parameters that I missed or an issue with FramWriteFR4xx.c (since the MSP430FR5xxx uses FramWrite.c instead). I've updated the RAM_START_ADDRESS and MAIN_START_ADDRESS to reflect the changes in chips. Are there any other parameters that need to be updated that I might have missed?

Another thought I've had; is there any other write or read protection that needs to be disabled (besides what I'm doing in SYSCFG0)?

On a related note, I am a bit confused about the FramWrite_o_start and FramErase_o_start variables. It looks like FramWrite_o_start is set to 0xC400 and FramErase_o_start is set to 0x5C00. Those don't look correct to me for the MSP430FR2311, but it also doesn't look like those variables are even being used. I've tried updating them but haven't noticed it changing any behavior.

Finally, I'll describe my setup. The MSP430FR2311 is soldered to a breakout board with only power and JTAG connections (4 wire). There are also 2 decoupling capacitors on the power input (10uF and 100nF). I'm using my own software and hardware for the JTAG communication, though the software is almost identical to the Replicator430FR reference.

  • Hi,

    I didn't look to original replicator source for a long time, so I forget about things related to FRAM. However, I also started too from this source, developing my own flasher software  / hardware side. If I read your post correctly, I don't understand why mailbox is used for writing to FRAM, because I don't see any reason for this, but only making simple thing more complicated. I am using mailbox only for unlocking / mass erase FRAM target devices. For FRAM read / write are used standard ReadMem / WriteMem functions. Downloading special function to target RAM for downloading firmware is used for flash family, not FRAM.

    My number of tested FRAM devices is less than ten, but AFAIK all are the same related to SBW / JTAG interface and write / read operations. Only some registers are on different addresses. Don't have FR2xx, but I have FR4133 that is similar to FR2xx and doesn't have any problem with it. I am using SBW because it use less wires and it is fast enough.

    After SBW entry sequence, there is only target reset and WD disable, nothing else. Don't have setup on table right now to show you master device logs, but here is PC side...

    d:\msp>flash -f msp430fr5959_red_blink.txt -w -v

    File: "msp430fr5959_red_blink.txt"
    @4400 64512 bytes
    Total Size: 64512 bytes

    Found master device at COM14

    Get Device
    # JTID Fuse Device Core Hard Soft LotWafer DieX DieY
    2  99   OK   6581  1106  30   30  E1271D07 2F00 1900
    3  99   OK   6181  1106  30   30  C1F22407 2B00 2200

    Write 271 ms 231,7 KB/s

    Verify 296 ms 212,6 KB/s

    Release Device

    Total Time: 672 ms

    d:\msp>

  • Hi Nick,

    The only difference in the JTAG system (besides memory address) on the FR2xx/FR4xx devices and the FR5xx/FR6xx devices are the JTAG locking systems. For JTAG on the FR2xx devices there is no password protection but just a simple lock mechanism. To enable FRAM access, clear bits DFWP and PFWP in the SYSCFG0 register.

    Some important resources for this is the datasheet for the MSP430FR231x as it will give you the memory addresses and figure 7-3. depicts the hardware setup for the JTAG process. There is also the MSP430FR4xx and MSP430FR2xx Family User's Guide this specifies the unique features on the JTAG interface for the device and will assist in the family specific details. The last document to look through would be the MSP430 Programming With JTAG Interface, this goes through the overall process. These documents are long but they include other devices (besides the datasheet) so a lot of the information won't directly apply to the MCU you are using.

    Seeing as you have past experience with the other FR devices the issue might be with the locking system. Can you test our code directly to check? Otherwise I would carefully compare your process flow to the TI code. Also are you using the MSP-FET to interact with the JTAG interface or are you using a different programmer?

    Regards,

    Luke

  • Thank you guys for the insightful replies! After I run DisableMPU() I can read 0x9600 from the SYSCFG0 register (0x0160) so I think I'm unlocking the JTAG; I read 0x9601 from the register before I write the password to it. 

    I'm currently using hardware developed by my company to perform the JTAG communication. The software is a modified version of TI's Replicator software (modified to work with our hardware; all of the higher-level functions are identical). We've tested this setup on MSP430FR5xx chips, but not on the FR2xx/4xx family.

    My coworker found a GangPro430 along with a few MSP430FR2xx and FR5xx chips that he's shipping to me, so I should be able to learn more once I get those set up and looked at.

  • I figured out the issue! I was Disabling the MPU at the beginning of my programming sequence, but failed to real that any POR or Erase was resetting that and locking the FRAM. I added a DisableMPU() directly before programming and it all works now!

**Attention** This is a public forum