• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Subscribers 82 subscribers
  • Views 2114 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.

CCS 6.2 Debug C28x Piccolo - Memory Map Prevented Reading Program

John Westmoreland43
Guru 13875 points

Hello All,

I may have asked the original question in the wrong forum - if so; can you please look here:

I thought this was more of a debugger issue.

Thanks In Advance,
John W.

  • 0
    TI__Guru** 112995 points

    Hi John,

    Going through the detail in main post, it seems like stack corruption issue. Have you checked the stack?

    Regards,

    Vivek Singh 

  • 0 in reply to Vivek Singh
    Guru 13875 points
    Hello Vivek,

    I thought the stack was OK - I think some of the pics could show what's there - I looked at the SP - is something getting popped off the stack and loaded into the PC before the valid FLASH address is loaded? I thought in this case - a regular function call - that even if the stack was corrupted; won't the PC fetch the next instruction for the FLASH address?

    I am not sure how it could have entered the 'parent' function if the stack was corrupted - seems that is more of an issue on a call exit or IRQ than what should be a PC fetch from memory, correct?

    Thanks,
    John W.
  • 0 in reply to John Westmoreland43
    TI__Guru** 112995 points
    Hi John,

    Is it possible to get the CCS project which we can use to reproduce the issue.

    Regards,
    Vivek Singh
  • 0 in reply to Vivek Singh
    Guru 13875 points

    Vivek,

    OK - Project file sent via PM.

    Thanks,
    John W.

  • 0 in reply to Vivek Singh
    Guru 13875 points

    OK Vivek.

    How is it going?  You've had plenty of time to look at this, correct?

    Thanks,
    John W.

  • 0 in reply to John Westmoreland43
    TI__Guru** 112995 points

    Hi John,

    Sorry for late response. Yes, I was able to run the code and see the issue. But I do see that CPU status bits are not correct when this issue occurs. Basically most of the status bits are getting cleared. In the attached image you can see that VMAP = 0 and OBJMODE = 0 which is not correct and this happens after retuning from "portRESTORE_CONTEXT" in side "_xPortStartScheduler". Inside this function we are changing the stack point value which I am not sure why, but that seems to be causing this issue.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Guru 13875 points

    Hello Vivek,

    Thanks for getting back to me; OK - I've gone through this - and when vLEDFlashTask gets called after an IRET; those bit fields are being cleared.  I tried to set them before that - but they're still getting reset.

    I've looked at compiler and linker options - do you have any idea why that could be happening?  Maybe something with the IRET?  But before the IRET all looks OK.

    Thanks,
    John W.

  • 0 in reply to John Westmoreland43
    Guru 13875 points

    Hello Vivek,

    Also - I can step when both of those are set to zero - it's just when the call to vTaskDelay is made - so why am I able to step OK with those registers set to zero but the call fails?

    Pics included:

    Thanks,

    John W.

  • 0 in reply to John Westmoreland43
    Guru 13875 points

    Hello Vivek,

    I see what I did now - it's a stack frame 'bug' - I don't have the correct stack frame for an IRET return - I did a manual fix up and that works.

    I do have a question about DBGSTAT - I don't see how to save/restore that from the debugger - I see DBGM in ST1 and the DBGIER register - but don't see DBGSTAT - how do I access that register?  (Ref. Table 3-3 in spru430e.pdf)

    I am supposed to restore that and it looks to be 16-bits wide. If there is no direct way to access - can I get a bit-field definition so I can fill in the bits with appropriate information?

    Thanks,
    John W.

  • 0 in reply to John Westmoreland43
    TI__Guru** 112995 points
    Hi John,

    Some of these registers can not be accessed directly. These are managed via stack push/pop operation only. I would suggest to fix the stack issue in SW and that should take care of these values.

    Regards,
    Vivek Singh
  • 0 in reply to Vivek Singh
    TI__Guru** 112995 points
    Hi John, Is your issue resolved?
  • 0 in reply to Vivek Singh
    Guru 13875 points
    Hello Vivek,

    The root cause is known - but why the debugger says it's a memory map issue isn't really correct; that could be considered orthogonal to the issue and certainly sends you down the wrong path when trying to figure issues like this out.

    Seems there could be an improvement to the debugger when a stack frame has an unexpected value vs. displaying a memory map issue.

    I asked this previously:
    I do have a question about DBGSTAT - I don't see how to save/restore that from the debugger - I see DBGM in ST1 and the DBGIER register - but don't see DBGSTAT - how do I access that register? (Ref. Table 3-3 in spru430e.pdf)

    I am supposed to restore that and it looks to be 16-bits wide. If there is no direct way to access - can I get a bit-field definition so I can fill in the bits with appropriate information?

    So, how does one push DBGSTAT? Is it possible to get a definition of the bits for this register?

    Thanks,
    John W.
  • 0 in reply to John Westmoreland43
    TI__Guru** 112995 points

    Hi John,

    The root cause is known - but why the debugger says it's a memory map issue isn't really correct; that could be considered orthogonal to the issue and certainly sends you down the wrong path when trying to figure issues like this out.  

    In this case due to wrong state of CPU, debugger is not able to read the memory content hence a generic error is created (which is the issue most of the time). I agree in this case it's not the correct issue but it's also difficult to know the exact issue. I'll pass this feedback to our CCS team anyway and see if they can do something about it.

    I do have a question about DBGSTAT - I don't see how to save/restore that from the debugger - I see DBGM in ST1 and the DBGIER register - but don't see DBGSTAT - how do I access that register? (Ref. Table 3-3 in spru430e.pdf)

    I am supposed to restore that and it looks to be 16-bits wide. If there is no direct way to access - can I get a bit-field definition so I can fill in the bits with appropriate information?

    So, how does one push DBGSTAT? Is it possible to get a definition of the bits for this register?

    To restore this, one has to do push and pop operations only.  Please see "Table 3-4. Register Pairs Saved and SP Positions for Context Saves"  in spru430e.pdf to know the location. 

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    TI__Guru** 112995 points
    Hi John, Let us know if you have any further queries on this one.