An Overview of MSPM0 Debug Subsystem
Understanding the MSPM0 Debug Subsystem by Henry Nguyen covering topics such as expected behaviors in low-power mode, SWD initialization sequence, modifying PWR-AP for low-power handling, utilizing RSTCTL bits, and more. The content includes details on proper sequences, behaviors in low-power states, and essential configurations for efficient debugging on MSPM0 devices.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
MSPM0 Understanding the Debug subsystem Henry Nguyen 1
Topics Overview Expected behaviors from the device while it is blank or in low-power mode Proper SWD initialization sequence Modifying the PWR-AP to enable low-power mode handling Utilizing the RSTCTL bits Utilizing the SEC-AP for DSSM commands Mass erase Factory reset Wait for debug Password authentication Counter measures for noisy programming environment Resets of MSPM0 2
Behaviors of MSPM0 in a blank/low-power state When the MAIN memory of the device is empty, once powered on for ~5-10 seconds the device will automatically go into STANDBY0 mode. If the device enters low-power mode via user application or blank memory. The AHB-AP is not discoverable, causing access to the M0+ core to not be possible. To handle re-enable access to the AHB-AP then the PWR-AP to wake up the device, upon doing so debugging while in a low- power state is possible again. 3
Proper SWD initialization sequence MSPM0 uses the ARM M0+ core, allowing the user to follow the procedure described by ARM to switch the device from JTAG to SWD. Upon executing the described sequence by ARM for JTAG to SWD, the Wake Logic unit within the DebugSS will send a wake-up request to the device allowing the IDCODE to be read no matter any low-power state. Best practice when initializing the SWD lines is to have the SWD to JTAG sequence executed first, this is to ensure it is in a known state. Once completed the JTAG to SWD should be executed. Upon completion it is best to have a small amount of delay before attempting to read the IDCODE. Within the CMSIS-pack for MSPM0, seven delay cycles is added before attempting to read the IDCODE 4
Modifying the PWR-AP to enable low-power mode handling For MSPM0 they contains an access point known at the PWR-AP, it is utilized to enable access to the M0+ core when the device is in a low-power state. To access the device and maintain a connection while it is in a low-power state the user must write a 1 to these bits. FRC ACT (bit 20) IHIB SLP (bit 3) Enabling FRC ACT will allow the AHB-AP to become discoverable when it is in a low-power state, enabling access to the M0+ core. Enabling IHIB SLP allows the connection to the device to be maintained even when it is in a low- power state. The expected reading from the IDR of the PWR-AP is 0x002E0002. 5
Utilizing the RSTCTL bits The RSTCTL bits from 14-17 will modify the behavior of the device upon reset depending on configuration. It is vital that at least one of the two configurations is implemented as it can be used to deal with misconfiguration of the peripherals that prevent access to the M0 Halt on reset Behavior Halts the device upon any reset and CPU does not go into the rest handler Configuration RSTCTL = 100 Wait for debug Behavior Forces the device into the reset handler upon any reset Configuration RSTCTL = 001 6
Utilizing the SEC-AP for DSSM commands MSPM0 has an access point know as the SEC-AP, it is utilized to recover the device in situations where the user misconfigures the device. Depending on the severity it can also recover the device if the user misconfigures NONMAIN. By sending commands to the mailbox within the SEC-AP, the user can then execute the command by performing a BOOTRST or toggle the nRST line for less than 1 second. The expected reading of the IDR for the SEC-AP is 0x002E0000. The command available are: Mass erase Command: 0x020C Description: Erases all of MAIN memory Wait for debug Command: 0x0206 Description: Resets the entire device and forces it to remain halted in the reset handler. Upon execution the user must read the DHCSR register and then write to the IN RST bit (bit 17) located within the DPREC register of the PWR-AP Factory reset Command: 0x020A Description: Erases all of MAIN and NONMAIN memory then re-populates NONMAIN memory with the default content Password authentication Command: 0x030E Description: Allows the user to send the password to unlock access to the device Data exchange Command: 0x00EE Description: If the user requires a password every executing a command, the data exchange command must be sent alongside the 32-bit password chunk each time 7
How to send and execute commands to the SEC-AP Flow chart key SECAP_TCR -> TXCTL SECAP_TDR -> TXDATA SECAP_RCR -> RXCTL For further questions please refer to the device specific .gel and mspm0_cs_dap_init.gel files that are available in all installations of Code Composer Studio 9
Countermeasures for programming in a noisy environment When programming MSPM0 this is the flow that should be followed. This is to ensure external factors such as noise being introduced cannot cause issues such as device lock Erase NONMAIN memory Program NONMAIN memory Yes Good? No Connect to the M0 Erase MAIN memory Program MAIN memory Program NONMAIN? Success! Verify content Restore default contents of devices Report error 10
Resets of MSPM0 MSPM0 utilizes the AIRCR to perform resets but it does not perform a system reset when utilizing the system reset as described by ARM. The AIRCR register performs a pure CPU reset, only resetting the core and no peripherals when utilizing the AIRCR. A system reset can be done via PWR-AP by utilizing the SYSRST bit within the SPREC. Or through the SYSCTL module which is documented within the device TRM. 11
