CCS/MSP430L092: CCS 9.3.0.00012 under Linux crashes when starting a debug session for a MSP430L092

Hello Chester,

Thank you for the dump files and DS log. I will send them to the debugger experts for analysis. Note that much of the team is away for the holidays so it will be a few days before I will have an update for you.

I tried to reproduce this on my Ubuntu 18.04.3 laptop but was not able to reproduce with CCSv9.3.0 and another MSP430 target (as I don't have an MSP430L092 to try with). Hopefully the dump files and log will have the information needed to debug the issue.

Thank you and happy holidays

lo

Ki said:

I tried to reproduce this on my Ubuntu 18.04.3 laptop but was not able to reproduce with CCSv9.3.0 and another MSP430 target (as I don't have an MSP430L092 to try with).

The problem does seem related to the MSP430L092 target.

With the CCS 9.3.0 installation under Ubuntu 18.04.3 LTS I have been able to debug other MSP430 targets connected to a MSP-FET; it is only with a MSP430L092 that have seen the CCS crash.

From  trying some other CCS versions already installed under Ubuntu also saw a crash when trying to debug a MSP430L092 with CCS 9.0.1, CCS 9.1.0 or CCS 9.2.0.

When tried CCS 8.3.0 with the following could then successfully debug a MSP430L092:
- CCS 8.3.0.00009
- Debug Server 8.3.0.1611
- TI Emulators 8.2.0.00004
- Code Composer Studio IDE MSP430 Components 8.3.0.201810301800
- TI MSP430 tool-chain 9.0.1

Chester Gillon said:

With the CCS 9.3.0 installation under Ubuntu 18.04.3 LTS I have been able to debug other MSP430 targets connected to a MSP-FET; it is only with a MSP430L092 that have seen the CCS crash.

The crash doesn't occur with CCS 9.3.0 under Windows 10, but found a different problem CCS/MSP430L092: CCS 9.3.0 under Windows 10 successfully programs MSP430L092 external SPI image using a MSP-FET430UIF, but not with a MSP-FET

Chester - sorry for the delay in response. I am still trying to acquire an MSP430L092 target to try on.

The engineering team has analyzed the logs. It appears your workspace has a lone breakpoint set for that debug configuration. The properties for this breakpoint appears to be the cause of the crash. Can you remove all breakpoints (clear all entries in the Breakpoints view) and try to relaunch the debug session? 

Thanks

ki

Chester,

I was able to secure a L092 kit here (L092S device) on a MSP-FET S/N 1407xxxxx (old one, according to this).

It worked for me using stock CCSv9.3 in both Windows 1903 and Ubuntu 18.04.3 native (Ubuntu 19.10 on a VmWare did not work).  

The MSP-FET correctly shows up in lsusb as VID:PID 2047:0014 and it worked out using the project msp430x09x_ta_01 from the MSP430Ware 3.80.07.00.

I am unsure what may be happening in this case, then. 

Regards,

Rafael

Ki said:

The properties for this breakpoint appears to be the cause of the crash.

Thank for the information. I will try again at the weekend when next have access to the MSP430L092 target and PC with the workspace in which the problem was found.

Since CCS crashed, should I try and determine which breakpoint is triggering the crash (if that was not visible from the logs)?

Chester Gillon said:

Since CCS crashed, should I try and determine which breakpoint is triggering the crash (if that was not visible from the logs)?

It appears to be a breakpoint with a specific trigger type (register trigger) that is no longer valid/supported... 

Ki said:

The properties for this breakpoint appears to be the cause of the crash. Can you remove all breakpoints (clear all entries in the Breakpoints view) and try to relaunch the debug session? 

I found that the workspace in which the crash was originally occurring had a "Break on Stack Overflow" set which was causing CCS to crash when attempting to start a debug session for the MSP430L092. Either of the following prevented a crash when starting a debug session with the MSP430L092 target:

a. Disable the "Break on Stack Overflow" prior to starting the debug session.

b. Removing all breakpoints.

Chester Gillon said:

Since CCS crashed, should I try and determine which breakpoint is triggering the crash (if that was not visible from the logs)?

When a debug session is running for a MSP430L092 target CCS doesn't allow a "Break on Stack Overflow" to be set, as is presumably not supported by the EEM in the MSP430L092.

Since a CCS crash was occurring found the following sequence could reliably repeat the failure with CCS 9.3.0 under Ubuntu 18.04.3 LTS:

1. Create a new CCS workspace, and import the following projects from https://github.com/Chester-Gillon/E2E_example_projects :

a. MSP430F5528_blinky_filled_flash : For a MSP430F5528 in a MSP-TS430RGC64USB. Used a MSP-FET to debug.

b. MSP430L092_blinky_duty_cycle : For a MSP430L092 in a MSP-TS430L092. Used a MSP-FET430UIF to debug.

2. Connect the MSP430F5528, and start a debug session for the MSP430F5528_blinky_filled_flash. When the program has reached main set a "Break on Stack Overflow" with the defaults:

Which created the following breakpoint:

The program runs successfully, and doesn't trigger the stack overflow breakpoint.

3. Terminate the debug session, and then re-start CCS to cause the breakpoint set above to be stored in the workspace settings (since upon a CCS crash the settings don't get stored).

4. Disconnect the MSP430F5528 target, and connect the MSP430L092 target.

5. Start a debug session for MSP430L092_blinky_duty_cycle, and CCS crashes before main is reached.

6. Following the crash, start CCS. Open the Debug perspective and disable the "Break on Stack Overflow" in the Breakpoints view. Start a debug session for MSP430L092_blinky_duty_cycle, and the program reached main.

Enable the "Break on Stack Overflow" in the Breakpoints view, which causes CCS to crash.

Chester Gillon said:

Since a CCS crash was occurring found the following sequence could reliably repeat the failure with CCS 9.3.0 under Ubuntu 18.04.3 LTS

Using the above sequence, I can now also get a crash with CCS 9.3.0 under Windows 10 Pro. The attached zip file contains the debug server log and .dmp file from the crash in step 5 of the above sequence.

Opening the .dmp file in Microsoft Visual Studio reports:

Unhandled exception at 0x00007FF99B0DDF2C (msp430_emu.dvr) in 479b7ceb-d956-4a62-a541-6c43dd0a16f1.dmp: 0xC0000005: Access violation writing location 0x0000000000000014. occurred

MSP430L092_CCS930_crash.zip

Chester Gillon said:

I found that the workspace in which the crash was originally occurring had a "Break on Stack Overflow" set which was causing CCS to crash when attempting to start a debug session for the MSP430L092

Thanks Chester. It must be a regression of some sort since it worked in CCSv8.3. Looks like two issues here - the fact that the trigger type is no longer supported and that CCS crashes. We will try to reproduce locally and file bugs for these.

Thanks

ki

Chester,

I was able to fully reproduce the issue on Windows 10 build 1903. 

I tried to reproduce the issue on Ubuntu 18.04.3 but I couldn't find my UIF pod (as you posted somewhere else, the MSP-FET does not connect to the L092 on this OS). 

In this case, I will inform the MSP tools team about this issue as well - it may be either from the interface or from the driver. 

I apologize for the inconvenience,

Rafael

Chester Gillon said:

I found that the workspace in which the crash was originally occurring had a "Break on Stack Overflow" set which was causing CCS to crash when attempting to start a debug session for the MSP430L092.

With CCS 9.3 in a workspace which had "Break on Stack Overflow" set, I also found that CCS crashed when attempting to start a debug session for a MSP430F2274.

desouza said:

I tried to reproduce the issue on Ubuntu 18.04.3 but I couldn't find my UIF pod (as you posted somewhere else, the MSP-FET does not connect to the L092 on this OS). 

Just to clarify, I am now seeing the same behaviour with CCS 9.3 under Windows 10 Pro and Ubuntu 18.04.3 when ensure there is no "Break on Stack Overflow" set in the workspace before starting a debug session for a MSP430L092 (the subject of this thread).

The behaviour is:

a. With a MSP-FET and MSP-FET430UIF can successfully download a program into the RAM of a MSP430L092.

b. With a MSP-FET430UIF can successfully use the "Copy application to external SPI memory after program load" to store the downloaded program into external SPI memory.

c. With a MSP-FET attempts to use the "Copy application to external SPI memory after program load" results in the external SPI memory having a corrupt image; which causes the MSP430L092 loader in ROM to show an "Error Blink". This is the subject of the https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/869319/3230870#3230870 thread.