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

Other Parts Discussed in Thread: TMS320F28027

Hello All,

I am seeing the attached - just stepping into a function that is in the gel memory map (gel file attached) - yet the debugger says it isn't in the memory map.

The function is in FLASH and has a valid address as in the attached.

Thanks In Advance for taking a look at this.

Regards,
johnw

this_f28027.gel

  • John Westmoreland43 said:
    I am seeing the attached - just stepping into a function that is in the gel memory map (gel file attached) - yet the debugger says it isn't in the memory map.

    The screen shot shows the debugger reporting "Memory map preventing reading 0x0D577@Program", with the current program counter at address 0x00D577 with no symbols defined for address 0x00D577.

    The TMS320F28027 datasheet shows the address 0x00D577 is part of "Reserved" address space:

    Therefore, is the actual problem that the program has "crashed" by jumping to the reserved address 0x00D577?

  • Hello Chester,

    From the pic that shows the address 0x3f4121- and also from the .map file:

    0 003f4121 _vTaskDelay

    That is a valid address and what should be in the PC when that is called.

    The program may be crashing - but why can't I step to a valid address that is in the memory map and is enabled in the
    gel file?

    It would seem I could at least step to that address before things stopped working.

    Thanks,
    John W.
  • John Westmoreland43 said:
    but why can't I step to a valid address that is in the memory map and is enabled in the gel file?

    Were you trying the assembly step-into option, i.e. to step one instruction at a time?

    That might give more of an indication at what point the problem occurs.

  • Hello Chester,

    If you look at the first pic posted in the OP - that is exactly what's going on.

    Again, it does not make it to 0x3f4121; which it should.

    Here's a pic of the adress 0x3f4121 and a breakpoint on that - and the debugger crashes before getting there.



    Regards,
    John W.

  • John Westmoreland43 said:
    If you look at the first pic posted in the OP - that is exactly what's going on.

    OK, thanks for confirming.

    Maybe enabling Debug Server Logging and posting the log file will give more information about what is going wrong.

  • Hello Chester,

    Debug server log attached.

    Thanks,

    John W.

    ds1.zip

  • And here's a log file that's smaller that shows the same issue.

    Thanks,

    John W.

    ds2.zip

  • John Westmoreland43 said:
    Debug server log attached.

    Looking at ds1.log I can see the program halted at a valid address in flash:

    0x00003A84 45948 3  MEM_SVR I: MemoryServer.handleHaltEvent : Halt Event: PC = 0x3f4b5e

    Where the instruction at address 0x3f4b5e is "767F411F    LCR          vTaskDelay"

    But after the next step operation the program is halted at an invalid (reserved) address:

    0x00003A84 47525 3  MEM_SVR I: MemoryServer.handleHaltEvent : Halt Event: PC = 0xd56d

    i.e. the debug server log file shows the same issue in the CCS debugger that after a step the program counter changes to a reserved address. However, I still don't know what the root cause of the problem is.

    Hopefully someone from TI will be able to analyse the contents of the debug server log file in more detail.

  • Chester,

    Thanks for looking at this - I would have though someone from TI would have commented on this by now.

    Regards,
    John W.