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.

Program/data space confusion

We're seeing a very strange problem on a 28335.  We have code in external RAM loaded in through the debugger.  In one spot, when we open the code space in a memory window in the debugger, we see one location which shows a different value when we switch from Program space to Data space.  It appears that at this location the memory access reads/writes a different memory location for Program and Data space.  We can write a value into each location and it stays there.  So, for example, we can set the window to Program space and write a 0x1111, then change to Data space.  In Data space we see some other value.  We then write a 0x2222 to Data space and it sticks.  If we then switch to Program space, that location shows 0x1111 and when we switch back to Data space it shows 0x2222.  All of the rest of the memory in that area acts as you would expect -- Program and Data space are the same.

Any ideas what could cause this?  It is also repeatable between boards, so it isn't a broken processor or memory chip.  It also effects real code -- we found it because we were doing an AND of 0x00FF with data, and the 0x00FF was being pulled from Data space (apparently) and so it was getting 0x1275 (or something like that).  When we change the 0x1275 to 0x00FF it works, but we can't really do that.

Dave

  • David Rice said:

    We're seeing a very strange problem on a 28335.  We have code in external RAM loaded in through the debugger.  In one spot, when we open the code space in a memory window in the debugger, we see one location which shows a different value when we switch from Program space to Data space.  It appears that at this location the memory access reads/writes a different memory location for Program and Data space.  We can write a value into each location and it stays there.  So, for example, we can set the window to Program space and write a 0x1111, then change to Data space.  In Data space we see some other value.  We then write a 0x2222 to Data space and it sticks.  If we then switch to Program space, that location shows 0x1111 and when we switch back to Data space it shows 0x2222.  All of the rest of the memory in that area acts as you would expect -- Program and Data space are the same.

    Any ideas what could cause this?  It is also repeatable between boards, so it isn't a broken processor or memory chip.  It also effects real code -- we found it because we were doing an AND of 0x00FF with data, and the 0x00FF was being pulled from Data space (apparently) and so it was getting 0x1275 (or something like that).  When we change the 0x1275 to 0x00FF it works, but we can't really do that.

    Dave

    Dave,

    I wonder if code composer is cashing the value and not actually getting it fresh or sending it out to the memory.  Can you try refreshing the memory window and see if it makes any difference?  In CCS 4 there is a little button to do this shown below:  Another way is to monitor the XINTF chip select line or read/write strobes and see if it is actually performing an access.

     

    The XINTF on 2833x is unified - there are no strobes to indicate a program data read vs a data bus data read.

  • We figured it out.  Somehow, code composer had a breakpoint set in the wrong place -- it was in the second word of the instruction instead of the first word.  When we removed all breakpoints it went away.  I've never seen that happen before!!  That word that replaced the 0x00FF was apparently the breakpoint opcode.  Must be when you view memory in the Program space view, CCS knows enough to swap the breakpoint, but when you view it in Data space, you see the breakpoint opcode!

    Dave