• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 426 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C123GH6PM: Unable to read a subset of an enabled peripheral's memory with a debugger in certain cases

Charles Hache1
Prodigy 30 points

Part Number: TM4C123GH6PM

Hello,

I'm trying to debug a malfunctioning UART but running into issues when debugging the UART's peripheral memory.

After my device has run for a few days it no longer responds to requests over the UART, so I've been trying to debug this.  I've verified that electrically the UART data is making it to the UART2 pins properly, so I figure it is a problem with the firmware.  I connected a debugger and found that the UART ISR is no longer being triggered.  The firmware enables and disables the UART RX and TX interrupts at various points, so I think there is a race condition somewhere and the RX interrupt doesn't get re-enabled, so I'm trying to confirm or disprove this.

I checked the NVIC registers to make sure that the UART2 interrupt is still enabled, which it is.  Then I went to check the UART2 peripheral memory to see what interrupt sources it had enabled, but I'm unable to read the memory I need to.  I'm using Eclipse, GDB, and OpenOCD to connect to the board.  What I'm seeing is that I can read the UART2's peripheral memory from it's base and offset 0x00 to offset 0x2C, but all further memory is just showing as ????????.  I think this typically means the memory doesn't exist, or is outside the readable range etc, or possibly that the peripheral is disabled.  I am assuming the peripheral is enabled since it works for a while then stops, and the peripheral doesn't get disabled anywhere in the code.

The memory I can read, from 0x00 to 0x2C, is what I would be expecting.  I can see the data in the UART data register changing, so the UART seems to be enabled and receiving data.  I can see the overrun bits in the data register and receive status register are set (which is what I would expect to see if the ISR is not taking the data out).  But I cannot read offset 0x38 to see what interrupts are masked, nor 0x3C to see the raw interrupt status etc.  I can also successfully read all of the relevant memory for the other UARTs I'm using, it's just the one I'm most interested in that I can't.

After rebooting the board I can read those memory locations properly, but after the reboot the UART is back working so it's less interesting to me.

I'm not sure what I could be missing or what else I can check.  Besides a peripheral being disabled are there conditions where some memory may be unreadable?  Next time it happens I can doublecheck that the peripheral is enabled, but if it is, I'm not sure where else to look.

Thanks,

Charles

  • 0
    TI__Guru*** 135355 points

    Hello Charles,

    When you say Eclipse are you referring to Code Composer Studio here? If so I can try and check with our CCS experts about what might be going on.

    I can't think of a situation where I have seen that particular behavior before with registers that you would normally be able to read.

    Also what debug probe are you using?

    Could you post a screenshot of what you see in the memory browser?

  • 0 in reply to Ralph Jacobi
    Prodigy 30 points

    Hi Ralph,

    Thanks for the response.

    I am using vanilla Eclipse CDT unfortunately (2020-12 (4.18.0)), with a KT-link clone JTAG debugger.  My GDB is GNU gdb (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.1.90.20201028-git.

    I've downloaded CCS and will look into getting that working.  From the release notes it doesn't appear that my debugger will work with it, but I do have some Tiva launchpads that I believe I used as standalone debuggers a number of years ago that I think I can get to work.

    I recognize that using an unsupported toolchain your ability to help is limited, but I appreciate you noting that you would expect me to be able to read those registers; I was mostly wondering if there were other situations where memory reads through JTAG might not be working, but it appears that it should have been working.  I had tried disconnecting and reconnecting to the target, deleting and recreating the memory view, trying different memory addresses around that area, and resuming and pausing execution all with the same results.

    The target is still running but when it fails next I will do some more experimentation both with our setup and with CCS and see what happens.  We're also setting up a bunch more units for long term testing to see how commonly we run into the issue, though with the memory I did manage to see I'm confident that it's an interrupt re-enabling problem but it would be nice to know for sure before going down that road.

    Regards,

    Charles

  • 0 in reply to Charles Hache1
    TI__Guru*** 135355 points

    Hello Charles,

    Yeah I don't believe CCS will support that JTAG debugger. You may be able to get an XDS200 to work instead with your board.

    If you can reproduce it on the LaunchPad that'd be great because then I could dig into it more.

    Let me know what comes of your attempts to use CCS, it could be maybe that IDE isn't expecting there to be values in those locations and doesn't try and read them? I'm not sure how the support for TM4C would be implemented for it.

  • 0 in reply to Ralph Jacobi
    Prodigy 30 points

    Hi Ralph,

    I haven't been able to reproduce the memory read issue.  When our UART issue reoccurs I'm able to read the memory successfully both with GDB directly and through IDE, so I think it was just some sort of fluke that it wasn't working originally.

    Thanks for the help!

    Charles

  • 0 in reply to Charles Hache1
    TI__Guru*** 135355 points

    Hi Charles,

    Gotcha, good to hear the IDE piece is working at least, good luck with the debug / analysis!