MSP430FR2355: stopping debugger, viewing memory browser and trying to restart?

Hi, 

I already test the sample code from TIRex with MSP430FR2355 lauchpad with CCS9.10/win10 64bit. It cannot repeat your situation. Everything is OK after sw reset or hw reset through a memory browser. 

Please check your environment and test the sample code in case there is something wrong with your own code. 

Hawken

No more info to give....viewing memory browser halts debugger on target and from then forward you cannot even set simple breakpoints...must reload code

I haven't observed this symptom either. What memory were you reading? I don't really trust the Memory Browser to read peripheral registers-with-side-effects, so maybe that's something to consider.

It's in permanent info around 0x1800

#pragma DATA_SECTION (permanent_Info, ".info")
char permanent_Info[5] = { [0 ... 4] = 0xFF};
#pragma RETAIN (permanent_Info)

#pragma DATA_SECTION (whitelist, ".info")
char whitelist[HOW_MANY_SENSORS] = { [0 ... (HOW_MANY_SENSORS - 1)] = 0xFF};
#pragma RETAIN (whitelist)

These two sections get modified as I join nodes to the client or as I move data around the network.  As I am debugging my code if I break somewhere I need to check these regions to see which channel I may be on.  The minute I look at this space and then try and continue on with the debugger I seem to know longer operate .....now I suppose my code could be written in such a fashion as to cause the code to miss an ISR or not clear an array when the debugger stops and cause the code to blink out into space somewhere???  In any event I am finding I click run again but if I try and place a breakpoint after this they do not take.  I am forced to reload code.

I don't have a MSP430FR2355, but investigated using a MSP430FR5969 with CCS 10.1.1.00004. Used a simple program which has TIMERB1_ISR toggle a LED.

If the memory browser is on display starting at address 0x01800, which is the start of Information memory (FRAM), than the program continues to operate correctly when resumed:

If after pausing, the memory browser is scrolled up so that address 0x01740 is the starting address, then on resuming the program no longer executes correctly, in that the LED no longer toggles:

The example used isn't accessing information memory.

Steve Wenner said:

The minute I look at this space and then try and continue on with the debugger I seem to know longer operate

0x1800 and up....

Mem.docx

Steve Wenner said:

I am forced to reload code.

The Run -> Load -> Verify Program menu option can be used to verify if the program is intact.

Verifying the program passed when the Memory Browser was on display starting at address 0x01800, when I could pause and resume the program which continued to run.

However, with the program paused:

a. Moved the cursor up in the Memory Browser window to change the first address displayed from 0x01800 to 0x017E8.

b. Without resuming the program, went to perform another verification which failed, reporting:

MSP430: File Loader: Verification failed: Values at address 0x0FF80 do not match Please verify target memory and memory map.

Not sure if I have created the same failure or not.

I ran the application, paused it with mem browser open at 0x1800 and I got an error doing a Run - Load - Verify

see attachment7077.Mem.docx

Steve Wenner said:

These two sections get modified as I join nodes to the client or as I move data around the network.  As I am debugging my code if I break somewhere I need to check these regions to see which channel I may be on.  The minute I look at this space and then try and continue on with the debugger I seem to know longer operate

As noted by CCS/NFC-DATALOGGER-EVM: Can CCS 9.1 Verifiy Program be configured to check all sections rather than stopping on the first error? the verification stops on the first error which makes debugging such issues difficult.

Can you:

a. Download the program with the memory browser not on display.

b. Pause the program before is has modified the contents of permanent_Info[] and whitelist[] in information memory.

c. Perform a verification.

d. Open the memory browser at address 0x01800.

e. Perform another verification.

The difference between c. and e. is to try and and determine if the memory browser is corrupting the program.

A work-around to your debugging problem could be to try using the Expressions view to display the contents of just the permanent_Info and whitelist arrays,. rather than the Memory browser.

Expressions window works....

case 1: Erase main memory only (Project - Properties - Debug - MSP430 Flash Settings)....

Perform steps a - c.  Break point set right after program_Info (0x1810) gets set.  View Memory fine.  Hit the run button and code does not stop at next breakpoint a few lines down.  Hit pause code stops with play button green and code is stopped way down waiting at LPM3.  I then hit reset and the green play button never gets highlighted again (pause and stop are only highlighted) and code doesn't go back to the beginning.......

case 2: Erase main, information and protected memory (Project - Properties - Debug - MSP430 Flash Settings)....

Same as case 1....Reset button no longer resets code

case 3:  Erase main, information and protected memory (Project - Properties - Debug - MSP430 Flash Settings)....

Keep memory browser open and forefront....download code.  Go to (Run - Load - Verify)....get immediate error:

MSP430: File Loader: Verification failed: Values at address 0x08104 do not match Please verify target memory and memory map.

Address seems random....saw 0x08114 last time.

What is going on here?  Sometimes when I load the application and look at memory browser before starting anything....permanent_Info seems to have 0's or other numbers in it but all the other blocks of information memory that I set look good....

Steve Wenner said:

Address seems random....saw 0x08114 last time.

Steve Wenner said:

What is going on here?  Sometimes when I load the application and look at memory browser before starting anything....permanent_Info seems to have 0's or other numbers in it but all the other blocks of information memory that I set look good....

While I though the act of using the memory browser was corrupting FRAM, due to the verification error not so sure now. This is because:

1. Can start a debug session which downloads the program, and get a verification error after displaying the memory browser.
2. Terminate the debug session.
3. Perform a Manual launch, which doesn't download the program. Perform a verification which then passes.

Steve Wenner said:

What is going on here?

I intended to raise on the CCS forum, but somehow managed to raise on the MSP forum.

Hi, 

I just tried some actions on my side. (win10/CCS9.10/MSP430FR2355 launchpad/UART_01 sample code)

I just added a breakpoint at any point before LPM3 and when break, do a memory browse @0x1800. And read upper or lower memory from memory browser. Then run from breakpoint, it can go normally. 

I don't think it will cause any reset by the action of memory browser. The only consideration is during the memory refreshing, the data connection is easily to be corrupt due to a large data transfer which would cause the CPU cannot be hold properly then the PC mismatched after the action so debugger request a reload. 

In order to check if there is any FRAM problem or debugger problem, you can readout the FRAM then compare with original one.