Register content on debugger connect in CCSv4

Eugene,

If you add one or more of the registers to the expressions view which value does it show (power on default or app value)?  i.e. add them to the expressions view at the same time as you are trying the reviews on the registers view.

Regards,

John 

John,

Adding register to Watch window or displaying register at its address in the memory window does not change the PORTS value hat is presented at launch connect/halt. Only reset and run to some BP shows application programmed values.

Regards,

Eugene

Eugene,

I am going to move this into the TMS570 forum to see is someone from the device team can help.  As far as CCS is concerned those are the values of the registers when you are reading them.  Something must be happening on the device after the reset and run to a breakpoint to change them.

John

John,

It does not look to me as device feature. Whatever happens on the device after CCS reset is the same as in the case of non-CCS start. Application code does not change.

Incorrect values are shown when CCS connects and halts the target at the start of the debug session. For whatever reason CCS does not read registers when it connects. Single step right after connect or window refresh does not help. Where does CCS get PORST values at connect?

Eugene

Eugene,

What registers are you trying to display?

When updating the display of the registers CCS reads the location whether it be on connect, hitting refresh or running into a breakpoint.  Seems to me that your application values are not loaded until you do a reset and then run from your reset vector.

Regards,

John

John,

I am looking at System frame registers at address 0xFFFFFF00 and I use XML file that came with CCS for the device. The code has artificial blocking loop in the form of B $ way after all registers are set. CCS stops at that location at connect and all system registers (and others) are in PORRST state. Reset and run from CCS (with required stop from GUI because of the blocking loop) brings CCS to the same point but now all registers are as expected (red indicates the changes). I use JS to start debug session. May that be a problem?

Eugene

Eugene,

Can you compare the mode states in the 2 situations?

I.e. after you connect and manually halt in the loop what does it show on the CCS status bar at the bottom right?  it should show the processor modes.

Similarly what does it show when you reset and run to a breakpoint?

Regards,

John

John,

There is no manual connect. Launch configuration is set up to connect to target at debugger start up and code does not run to BP it runs to the same blocking loop.

In both cases status bar shows ARM, BE8, SPV. It is handwritten ARM assembly code.

I noticed however that if I do not start debug session with JS but with Target->Debug->Debug then register values are correct but the moment I manually load symbols all registers go back to their PORRST values?

Eugene

Eugene,

Loading symbols shouldn't issue any writes to the target, although it will cause the views to refresh so registers will be re-read.  What's more likely is that your application contains symbols that replace the register definitions. 

Could you right click on one of the registers that is not working and select "Create watch expression".  In the watch view, look at the "Address" and "Type" fields for the register expression both before and after the symbol load and see if the they change.

Darian

Darian,

Yes, the code contains register definition for addressing them with required set up values. These definitions are from HalCogen files. None of those definitions matches stock XML register names. Refreshing register view does not change values. Displaying register address in memory window does not change values. The values stay the same as in the 'bad' case. More on that below.

Bad case:

Sys_PllCtl1 = 0x2F025F00, Address=0xFFFFFF70, Type=pointer, Format=Natural

'Good' case:

Sys_PllCtl1 = 0xA0846300, Address=0xFFFFFF70, Type=pointer, Format=Natural

Bad case. I also noticed that if I re-load JS through scripting console then registers go PORRST after loading symbols. I use command file "loadJSFile <file>". If I load the same JS with hotmenu and load(<file>) method then register window shows PORRST value but memory window shows correct one. Refresh on memory window in later case brings all registers to incorrect PORRST values. Hot menu loads the same script.

There were also some launches when "Create watch expression" was grayed out. In some cases it would come back after delay.

Eugene

Eugene,

Could you try adding the expression "*(int**)0xffffff70" to the watch window and compare the results of that expression with the register and memory views before and after loading symbols?  That expression shouldn't access symbols at all, so it should just be a raw target access (and not a block access like the memory view case).  If that still shows incorrect values, then there's something going on accessing that location.

Darian

Darian,

Isn't it the same as memory view that did not work? Anyway, bad case *(int**)0xffffff70 = 0x2F025F00. Good case *(int**)0xffffff70 = 0xA0846300.

From the symptoms it looks to me like CCS launch connect problem rather than location access issue. As it was mentioned in this post it only happens at launch connect. After CCS reset and run it works as expected.

Eugene

Eugene,

It should be identical.  My thought was that it was an issue with the symbolic name, or with the way the memory view accessed that memory.  Accessing just the one word directly without a symbol lookup eliminates both.

However, I thought from an earlier post that the value was incorrect, you'd load symbols, and then it would be correct.  I thought all you were doing was a symbol load.  However, it sounds like you're also resetting and running.  I'd like to first try isolating which step causes the value to change from incorrect to correct:

• If you load symbols alone, is the value correct?
• If you reset after loading symbols, but don't run, is the value correct?
• Or is the value only correct after a symbol load, reset and run?

If it's the last case, could you try setting a watchpoint to see if that location is ever written to (perhaps unintentionally) in the program?  If not, could you try running to earlier locations and find out exactly where in the program execution the value changes?

Darian

FYI, Eugene and I took debugging this offline.  The conclusion is that 4.2.0.10017 fixes this issue.