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.

MSP432P4111: Power Cycling or Resetting Microcontroller Halts EUSCI Module

Part Number: MSP432P4111
Other Parts Discussed in Thread: UNIFLASH, MSP-FET

Hello,

I am working with a custom MSP432P4111 microcontroller board that has a UART (EUSCI) interface, I2C interfce, and SPI interface all connected to the DMA controller to handle interrupts. I've been developing on a dev board and debugging the code just fine, it functions as expected. Now that I have the hardware I've loaded the direct exe onto the board through an MSP-FET using Uniflash. I can see the board function great, LEDs turn on how I expect and am able to receive UART commands that function how I want it to. Once I power cycle the board the micro of course resets, I can see I2C data come out on the SDA line and the LEDs all light up the same way, but I am unable to ever receive UART data. I know this since the DMA interrupt never occurs as it doesn't flip the LED that is flipped when I've freshly flashed the board. I've additionally seen that connecting the debugger after a power cycle (but not flashing the board), the UART RX buff register is always empty. When I did this after a fresh flash it gets filled and the code operates. When initiating a "hard" or "soft" reset with Uniflash this also results in the UART module not operating.

The jist of it is that whenever the micro resets either from power off, hard reset, soft reset, or directly pulling the NRST line low, my code doesn't operate the same way as if I'd fresh flashed it from Code Composer or Uniflash. 

If anyone has any suggestions or thought on what might be happening I'd appreciate the advice.

  • Are you sure the MSP is behaving strangely and not the MSP-FET? I recently had a very similar problem. In my case, I was able to prove that my MSP was behaving normally by unplugging the MSP-FET, plugging in the ezFET, and verifying that the UART communication was still working.

    The only way I've found of fixing the issue with the MSP-FET is a full PC reboot.

  • EmbeddedMike,

    Thank you for your reply, we are not using the MSP-FET's UART pins to communicate with the MSP. That is an external interface that connects to our computer, but I will try to use an XDS110 debugger and see if that helps

    I've also just found out that  when I transmit data on that same EUSCI module the baud rate is completely wrong when power cycled. Investigating that further I found that the CS register is setup differently on power cycle than when freshly flashed, specifically the DCO is not enabled and the frequency is not set to SEL5 for the CTLW0 register. It's odd that this only happens on a reset since the reset handler should run the SystemInit function which sets up the clock the same way it does when we flash it. I'm off to do more testing and will update the thread if I find anything else out.

  • Thanks for the update and additional information.

    Note that there are different types of resets and they affect the register settings differently. On startup, I use a switch case on the value stored in SYSRSTIV to make sure that I always identify the cause of reset and am able to reinit appropriately.

  • I have found the solution. Apparently the startup file for the MSP432P4111 is different than the MSP432P401R and is wrong on a specific section. The flash bank read wait states lines are setting it to 2 and not 3 like it should which causes my system to change the frequency down from 48MHz. This causes me to seem like I'm running, but my baud rate for the EUSCI module to be wrong. Don't know if there is some sort of internal protection to change the CS register if the read wait state value is wrong, but my system was changing the CS register when the board reset. The solution I used is here:

    https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/787876?MSP432P4111-set-system-clock-48MHz-and-flash-wait-states

**Attention** This is a public forum