• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 221 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.

MSPM0G3107-Q1: Unable to debug or flash using Uniflash on one system

Aman Bhasin
Prodigy 10 points
Part Number: MSPM0G3107-Q1
Other Parts Discussed in Thread: MSPM0G3507

Tool/software:

I have a custom board based on MSPM0G3107-Q1 that I'm trying to debug using the XDS110 debugger. I get the following output in the debug console:

Flash Programmer: Hard reset before programming
Writing Flash @ Address 0x00002000 of Length 0x00001398
Flash Programmer: Uploading RAM loader to device
Flash Programmer: RAM loader returned after 10 ms 
Flash Programmer: Device init finished
Flash Programmer: Erasing main memory
Debug: Returning from main erase
Flash Programmer: RAM loader returned after 10 ms 
Flash Programmer: Main erase finished
Flash Programmer: Attempting to halt device for write operation
Flash Programmer: Device halted for write operation
Flash Programmer: Beginning write operation
Flash Programmer: Writing 5016 bytes for address 0x2000, Checksum: a8bf97f7 
Flash Programmer: RAM loader returned after 20 ms 
Flash Programmer: Write speed 12.9 kB/sec
Flash Programmer: Hard reset after programming
Error: (Error -1001 @ 0x0) Requested operation is not supported on this device. (Emulation package 20.2.0.3536) 
Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 20.2.0.3536) 
Error:  Connection to MSPM0 core failed.  Possible root causes: 1) Debug access within NONMAIN was disabled or enabled with password. 2) Peripheral mis-configuration (e.g improper watchdog or clock).  To see a more detailed diagnostic of the issue, please press the 'Read boot diagnostic'

Please note that verbose output is enabled. The same setup works on a different PC. I have tried reinstalling everything to no avail. How do I narrow down the problem?

  • 0
    TI__Intellectual 2300 points

    Hi,

    Let's try to narrow it down:

    1) It sounds like you are trying to enter debug mode?

    2) Does this problem persist across multiple M0 devices/boards?

    3) What version of CCS are you using? What about the computer that does work?

    4) Have you tried a different XDS110 (the launchpads have an XDS110 that can be connected to a different board)

    5) Have you tried doing a factory reset on the device?

    -Matthew

  • 0 in reply to Matthew Komitsky
    Prodigy 10 points

    1. Yes

    2. Yes

    3. The system that works is on 20.0.1, the one that doesn't is on 20.2. Compiler versions are TI ARM Clang 4.0.2 and 4.0.3 respectively, I'll get both on the same version and update here shortly.

    4. Yes, tried two different launchpads (one is an MSPM0G3507 evaluation kit, other is a C2000 evaluation kit, but I don't think that should make a difference)

    5. Yes, a factory reset is the only way to recover the device to get debug working on the other computer.

    Adding a bunch of context that I've since gained:

    1. In our use case, as you can see in the logs is well, we want to write the application from address 0x2000 as the rest of the address space is reserved for a custom bootloader application. To achieve this we have modified the .cmd file. I'm attaching it with this reply. 

    2. Referring the TRM (section 1.4), we can see that booting from a custom location should not be possible. So the controller not entering debug makes sense with this config. We're now confused about what is different about system 2 which is being able to debug with the custom config.

    Is my understanding about the boot sequence correct? 

  • 0 in reply to Aman Bhasin
    TI__Intellectual 2300 points

    Hi,

    (I don't see the attached file; could you try uploading again?)

    Have you enabled static write protect in the BCR configuration for the region in which the custom BSL resides?

    In the meantime --> Have you explored the secondary BSL example and BSL user guide?

    There is some useful information in the readme

    -Matthew