• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 923 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

LP-MSPM0G3507: Connection Problem / Device Locked

Marco Marder
Prodigy 100 points
Part Number: LP-MSPM0G3507
Other Parts Discussed in Thread: UNIFLASH, SEGGER, MSPM0G3507

I have a LP-MSPM0G3507 board and I am trying to flash it with a binary file from an example of the MSPM0 SDK build with CCS.

Unfortunately I can't access the core.

XDS110 USB Debug Probe

When trying to flash from CSS I get the following message:

Error connecting to the target: (Error -614 @ 0x0) The target indicates there is an error condition from a previous SWD request. Clear the error the condition, and try the SWD request again.

J-Link Ultra+ Debug Probe

When I disconnect SWD from J101 and connect a J-Link Ultra+ to J103 and start J-Link Commander and just try to connect I get:

AP[0]: Stopped AP scan as end of AP map seems to be reached
Iterating through AP map to find AHB-AP to use
Attach to CPU failed. Executing connect under reset.
DPIDR: 0x6BA02477
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map has been reached
Iterating through AP map to find AHB-AP to use
Could not find core in Coresight setup
Cannot connect to target.

To me it seems as the device is somehow locked or in a state where it does not accept SWD commands anymore.

Any hints/ideas what I can do to get it back to operation?

  • 0
    TI__Intellectual 960 points

    Hello Marco,

    Can you try preforming a BSL reset before flashing? To do this, hold down the RST and BSL button (left side button) at the same time. Then, release the RST button before the BSL button. In this mode, you have about a 10 second window to flash the device. If this works, there is an issue with the M0 support package for CCS.

    Which version of CCS are you using?

    Regards,

    Greg

  • 0 in reply to Greg Lanier
    Prodigy 100 points

    Hello Greg,

    with the described BSL reset procedure I can flash the board and debug and execute the code.

    Versions:

    CCS: 12.3.0.00005 

    MSPM0 SDK: 1.10.0.5

    I have the same issue with UniFlash 8.3.0.4307 .. with the BSL reset procedure above I can also flash with UniFlash.

    Can I update/downgrade some of the tooling to versions which do not have this issue?

    Regards Marco

  • 0 in reply to Marco Marder
    TI__Intellectual 960 points

    Marco,

    Good to hear that fixed it! I can help you getting around having to reset every time.

    You do not have to roll back the SDK or CCS, but installing an M0 support package into CCS/Uniflash should do the trick. I see that you should have access to M0 files under Secure Resources. The QuickStart guides on that page describe how to implement the support package into CCS once downloaded.

    I believe the support packages themselves linked on that page are outdated, and you should have received a newer support package via email. The directions for installing are almost the same. Tell me, are you able to see the support packages at this link? This version should fix the BSL bug. If you can see the download links, download the one ending in p2 (assuming you are using Windows) and follow the QuickStart guide, but unlike the guide says, you shouldn't have to edit the archive name (don't add p2 in the file extension).

    Let me know if there is any step of this process I can help you with.

    Regards,

    Greg

  • 0 in reply to Greg Lanier
    Prodigy 100 points

    Hello Greg,

    I continued working on this topic. We are also directly in contact with TI FAE - they pointed out that with the new CCS 12.4 version the problem should be gone. I updated CCS to 12.4 and I can flash, run, debug MSPM0 SDK code examples from CCS (with XDS110 USB Debug Probe and J-Link Ultra+ Debug Probe).

    I also build a min. example project with our own toolchain (GNU GCC, CMake, SEGGER Ozone Debugger, VS Code Editor). I can flash the binary to LP-MSPM0G3507 and the code runs (LED flashes with correct frequency).

    Yet when trying to flash and debug with SEGGER Ozone v3.30a  I observe the following behavior:

    • sometimes flashing works and SW ends up in DefaultHandler
    • sometimes the connection to the target is reported as interrupted during flashing
    • sometimes I get no connection to the target at all

    In my min. example I use the startup file and linker script for GCC from the MSPM0 SDK 1.0.1.3. The Ozone project file is just the standard on which is created when I select the MSPM0G3507 device in Ozone.

    Under https://wiki.segger.com/TI_MSPM0G Segger points out some special notes on watchdog and reset handling for the MSPM0G3507 device.

    Is there any special care needed regarding watchdog and reset handling in the Ozone config? Any other ideas what my problem might be?

    Regards Marco

  • 0 in reply to Marco Marder
    TI__Intellectual 960 points

    Hello Marco,

    I do not personally have experience with the Ozone, but I talked with my team about possible causes.

    I do have one question for clarification.

    Marco Marder said:
    In my min. example I use the startup file and linker script for GCC from the MSPM0 SDK 1.0.1.3.

    Is there a reason you got the files from an older version of the SDK? Always good to try the files from the latest SDK release.

    There are some suggestions for if Ozone is the issue here:

    1.) There was a known limitation with the SEGGER J-Link where we had to tell it to use the un-checked SRAM region because it wasn't properly handling the ECC corrected SRAM. We are not sure if Ozone has the same issue, but it is worth taking a look at.

    2.) Double check that you are using the latest version of Ozone. The release notes for the latest version says that it uses drivers 7.88j, and several recent issue fixes have had to do with this driver version.

    Let me know if either of these fixes work.

    Regards,

    Greg

  • +1 in reply to Greg Lanier
    Prodigy 100 points

    Hello Greg,

    1.) I updated the MSP0 SDK from 1.0.1.3 to latest (startup file and linker script for MSPM0G3507 are unchanged) yet the problems are the same

    2.) I talked to Segger and they mentioned that Ozone modifies the PC after downloading application to flash. If a bootloader is run before the application (which is the case as the TI bootloader is programmed during chip production as I understand it) this can cause problems. The modifications described under https://wiki.segger.com/Debug_on_a_Target_with_Bootloader#ROM_bootloader of the Ozone settings allow me to flash and debug now. 

    When trying to erase the chip memory the erase for sector 0x41C00000 fails as the bootloader config sits there and the sector is locked/protected.

    I am just ignoring this warning for now. I think to proper way would be to instruct Ozone or JFlash to only erase sectors where no bootloader config is stored .. but I did not find time to try this.

    Anyway I can work for now.

    One last question: Can you specify how long the programmed bootloader takes to complete after reset?

    Marco

  • 0 in reply to Marco Marder
    TI__Intellectual 960 points

    Hello Marco,

    We have details on reset time in the datasheet for the M0G on page 33. I believe what you are looking for is Startup Timing on the device.

    Regards,

    Greg