• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 325 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP432-RTOS: Unable to perform CCS debugging in MSP432P401R

Shriganesh Shenbagamoorthy
Prodigy 40 points
Part Number: MSP432-RTOS

Configuration :-

1) Using MSP432P401R& TI's MSP-FED Flash Emulation Tool

2) Using CCS for dev. Got a Custom BSL and an application code

3) Need to perform "ERASE_TOTAL" and then flash the image is generated as TI's TXT file. I was able to use MSP430Flasher.exe tool

4) After REBOOT, Custom BSL and Application are running

Problem 1:-

1) After all steps in Configuration as said above, I am not able to start DEBUGGING session in CCS for BSL. I get below error.

"CORTEX_M4_0: Error connecting to the target: Could not write device Register"

Problem 2:-

1) After all steps in Configuration as said above, I am not able to start DEBUGGING session in CCS for Application. I get below error.

"CORTEX_M4_0: Trouble Reading Memory Block at 0x20100c on Page 0 of Length 0x4: Could not read device memory
CORTEX_M4_0: GEL: Error while executing OnTargetConnect(): Target failed to read 0x0020100C
at gGEL_DeviceID=*((unsigned int*) 0x0020100C) [msp432p401r.gel:247]
at OnTargetConnect()
CORTEX_M4_0: Failed Soft Reset: Could not reset device
CORTEX_M4_0: GEL: Error while executing GEL_Reset(): Reset failed: retcode=-1
at GEL_Reset()
CORTEX_M4_0: Trouble Writing Memory Block at 0x0 on Page 0 of Length 0x5428: Could not erase device memory
CORTEX_M4_0: File Loader: Verification failed: Target failed to write 0x00000000
CORTEX_M4_0: GEL: File: C:\EDGE\NEMO\src\firmware\Application\Debug\nemo_sleep_micro_MSP_EXP432P401R.out: Load failed."

Problem 3:-

1) Perform ERASE_TOTAL using .\MSP430Flasher.exe

2) Now 

  • 0
    Prodigy 40 points

    Problem 3:-

    1) Perform ERASE_TOTAL using .\MSP430Flasher.exe

    2) Try to start debugging the application in CCS.

    3) Now it starts and control comes to main(). But when selected to continue, it runs few steps (I can see serial port debug output) and halts. It stops working.

    Any clue or suggestion to debug this issue is advisable. Thanks

  • 0 in reply to Shriganesh Shenbagamoorthy
    TI__Mastermind 35720 points

    Can you check if you use the high optimization mode?

    Can you try a code example without RTOS to check whether you still have this problem?

  • 0
    Expert 1431 points

    If I understand correctly, you are using a custom bootloader application at the start of memory, which loads and runs your application that lives at a higher address.
    if you load your application with the CCS debugger, by default it erases the whole flash - including your bootloader application.
    When you start debugging, the processor still needs to find executable code at address 0 (your bootloader). This would then jump to your application and wait at the debugger breakpoint on main() - all good.
    You need to change the default settings for your application so that it does not erase the bootloader when you load your application.
    Run menu - debug settings - Target tab - - MSP432 Flash Settings - select "Erase and download necessary segments only".

  • 0 in reply to Jim Whitehouse
    Prodigy 40 points

    Thanks Jim.

    I did the change and still face the same problem.

    Issue 1:    When I do a debug run from CCS (after doing ERASE_ALL using MSPFlasher), it starts from main() of the app properly. But execution crashes after executing a line "MAP_GPIO_setAsOutputPin(GPIO_PORT_PJ, PIN_ALL16);". This happens all the time. But the same code works good when we build the app from outside CCS, create a flash update file (bootstrap + application) and burn it.

    Issue 2:    After doing ERASE_ALL and when I run the application once, the JTAG gets LOCKED. From that point, I am not able to start debug again. I get the error that JTAG is secured. FYI, We tried to UNLOCK JTAG using Boot-override operation and it won’t unlock after bootup and run. IF you are aware of any example code that describes how to UNLOCK JTAG from application, please share it.

    Any help appreciated.

  • 0 in reply to Shriganesh Shenbagamoorthy
    Expert 1431 points

    Hi,
    I have been using the MSP432E series, and I believe there are some significant differences but:

    I have generally found that when debugging "crashes", it is because I have hit an ASSERT. Functions like MAP_GPIO_setAsOutputPin() are pretty simple, and only assert if the GPIO_PORT argument is illegal - could your CCS build setting be using the wrong processor include file?
    For the E series, these GPIO functions are mapped to a ROM version, but you can undefine ROM_GPIOPinTypeGPIOInput, to link in a standard library version which is easier to debug - you can then single step in!
    I have had something similar and I remember it was trivial - something like calling the init functions in the wrong order - but I can't remember what it actually was. Pinoyt.c includes driverlib.h and, if you comment out #include <ti/devices/msp432e4/driverlib/rom.h>, then you can single step into the GPIO setup functions.

    Since you are calling MAP_GPIO_setAsOutputPin(), it sounds like you are using the generated pinout.c file. I did exactly this and it locked my debugger out because it set the JTAG pins as GPIO.
    I needed to factory reset the processor which I describe in the following forum link, but I'm not sure if that will work for the P series.
    https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1074622/msp432e401y-launchpad-cortex_m4_0-file-loader-memory-write-failed-flash-programmer-verify-error-writing-to-flash-failed

    Someone else was having a problem with resetting a P series at:
    https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1087114/msp432-and-xds110-debug-probe-error-261

  • 0 in reply to Jim Whitehouse
    Prodigy 40 points

    Thanks Jim,

    Thanks for the insight. I really appreciate your help. This seems to be the root cause.

    I checked the code with respect to the data sheet and found that the PJ ports Pin_4 and Pin_5 are related to JTAG/SWO. That tells why the JTAG port getting locked when the application is running and just after that line, the debugger stops.

    It seems, Pin_0 and Pin_1 of PJ port is for the low frequency oscillator. Since our feature needs clock, the earlier engineer configured ALL the pins in PJ port. This resulted in locking the JTAG too. Now I am working on isolating and using just the pins we will need.

    Best regards,

    Shriganesh

  • 0 in reply to Shriganesh Shenbagamoorthy
    TI__Mastermind 35720 points

    Hi Jim,

    Thank you for helping solve the problem!

    Eason