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.

MSP430FR5849: Configure Port 2 Pins 0 & 1 for UART function erases main memory

Part Number: MSP430FR5849

I am using an MSP430FR5849 part and trying to implement the Main Memory Bootloader described in document SLAA721C.

When I attempt to configure RXD & TXD lines for eUSCI_A mode (secondary function selected for bits 0 & 1 of Port 2), it causes the part to erase all main memory FRAM back to all 0xFF bytes.

I am setting up the clock system to use the DCO at 24Mhz, with SMCLK and MCLK both set to 3Mhz (DCO/8), in case this matters.

Below is the code I'm having trouble with:

// eUSCI_A0 held in reset and use SMCLK

// Select secondary (UART) function on Port 2 pins 0 & 1
P2SEL0 &= ~(BIT0 | BIT1);
P2SEL1 |= (BIT0 | BIT1);

// Set baud rate per conditionally compiled baud rate settings
UCA0BR0 = (UCBRx_VAL & 0xFF); // Set Low baudrate byte
UCA0BR1 = (UCBRx_VAL >> 8); // Set high baudrate byte
UCA0MCTLW = UCOS16_VAL | // Set modulation values
(UCBRSx_VAL << 1) |
(UCBRFx_VAL << 4);

When I execute the assignment to P2SEL1 to OR in BIT0 and BIT1, the part erases all FRAM memory.  What am I doing wrong?



  • Kent,

    normally these instruction are not able to erase the main memory. Does this code and the UART works if you execute it out of main memory and not from BSL area?

    Can you please provide the disassembly view of this code?

  • Dietmar,

    The code is running from main memory - it the main memory boot strap loader code described in document SLAA721C.

    Here is the disassembly:

    00fd34: 40B2 0081 05C0 MOV.W #0x0081,&USCI_A0__UART_Mode_UCA0CTLW0
    81 P2SEL0 &= ~(BIT0 | BIT1);
    00fd3a: F0F2 00FC 020B AND.B #0x00fc,&Port_1_2_P2SEL0
    82 P2SEL1 |= (BIT0 | BIT1);
    00fd40: D0F2 0003 020D BIS.B #0x0003,&Port_1_2_P2SEL1
    85 UCA0BR0 = (UCBRx_VAL & 0xFF); // Set Low baudrate byte
    00fd46: 43D2 05C6 MOV.B #1,&USCI_A0__UART_Mode_UCA0BRW
    86 UCA0BR1 = (UCBRx_VAL >> 8); // Set high baudrate byte
    00fd4a: 43C2 05C7 CLR.B &USCI_A0__UART_Mode_UCA0BR1
    87 UCA0MCTLW = UCOS16_VAL | // Set modulation values
    00fd4e: 40B2 00A1 05C8 MOV.W #0x00a1,&USCI_A0__UART_Mode_UCA0MCTLW

    When I execute the instruction at address fd40 is when all of main memory FRAM (i.e. all of the main memory boot strap loader) to be erased to all 0xFF bytes, even though the MPU has been set to prevent writes to that space (0xF800 - 0xFFFF).


  • Kent,

    disassembly looks fine to me but these instruction can never erase it. So does it mean you need to reprogram it than or is the code still present after a RESET?

    Are you sure you're running below 8 MHz for the MCLK otherwise you need to implement wait states?

    How do you recognize that the code is erased? Via debugger can it be that you might lost connection and only think it is erased because you overclocked the CPU?

  • I am thinking the code is erased because as I single step in the debugger, immediately upon executing the instruction that writes to the P2SEL1 register, all bytes go to 0xFF in the Memory Browser panel of the debugger.  The debugger still appears to have connection, as I can change the address in the Memory Browser and view different address ranges.  All bytes seem to now be 0xFF from 0xF800 through 0xFFFF which is where the main memory boot strap loader code is located, and the memory address values are not showing up as question marks.

    I verified immediately before executing the instruction writing to P2SEL1 that the clock system is set to DCO clock of 24Mhz, MCLK and SMCLK are sourced from DCO, and MCLK and SMCLK are both dividing DCO by 8 (CSCTL1 = 0x004C, CSCTL2 = 0x0133, CSCTL3 = 0x0033).  I did notice that after I execute the instruction that writes to P2SEL1, these registers are reset to 0xFFFF, as well as the FRAM.

    I just noticed that if I single step one more time after this instruction, it appears to go through a reset and the code is back, with the program counter at the reset vector, and the clock system restored to the settings I described above.  So I guess it isn't actually erasing the FRAM or registers, but is somehow resetting at that instruction.  Any ideas why that might be?



  • Hi Kent,

    ok that you get a reset might make more sense but erase would be really really strange.

    Do you have anything connected to these pins which can cause a short or pull supply hard down?
    Also you can check which reset appeared by checking the SYSRSTIV register after your reset.

    But please set it to 0x0000 before you do it to ensure you erased all previous reset sources. Once you know the source we can support you further.

  • I have configured all the IO ports in in this main memory BSL the same way that they were configured in my application before I started trying to use the main memory BSL, and the application worked fine at that time.  So I don't think it would be an issue caused by what is connected to the pins.

    I checked the SYSRSTIV register - it has the value 0x0004.

  • I think this has pointed me to the issue.  I have another processor on the board that generates an NMI interrupt to the MSP and I think it is doing so when it powers up, and the main memory BSL does not have the NMI pin configured for NMI functionality yet.  So this appears to be what is causing the reset.  Thanks for helping me track this down.

  • Hi Kent,

    perfect the you're right the 0x04 indicates a BOR by the RST pin so now you now what to look for.

    By the way in general good practice to analyze the SYSRSTIV register at each reset to get information which reset source kicked in. Even in applicaiton very helpful if any kind of returns might appear in future. So assume the thread can get closed right?

  • Well, I guess I spoke too soon.  I added configuration in the main memory BSL to set the RSTn/NMI pin for NMI functionality, leaving the NMI interrupt disabled.  In our design, the MSP controls power to the other processor that I mentioned was generating an NMI interrupt pulse.  And this reset that I'm seeing happens on the write to the P2SEL1 port before this other processor has been powered on.  So it can't be the NMI interrupt pulse it generates that is causing this.

    I'm still seeing 0x0004 in SYSRSTIV.  The SFRRPCR is configured to enable the internal pullup - there is also a 47k external pullup.  I've tried it both with the internal pullup enabled and disabled.

    Any other thoughts?

  • Kent,

    do you have cleared SYSRSTIV to 0x0000 before you single step over your instruction. Ensuring all previous stored events in the register are deleted.

    When you do modifications on SFRRPCR did you check if you considered PORT28 ERRATA properly.
    Also interesting is do the pins you configuring drive maybe a current sink which is larger then the port spec?

    So if you take the other IC out of the game are you still experiencing it? Important that you do not supply any GPIO pin with a voltage higher than DVCC to let current flow via the ESD diodes to your supply.

  • Apparently I had broken hardware.  Appears like the eUSCI_A TXD line maybe is shorted, such that when I try to enable this function on that pin, it is causing a reset.  After switching to a different hardware board, I don't have this problem.  Thanks for your help!

**Attention** This is a public forum