EK-TM4C123GXL: Viewing Registers in GDB with OpenOCD

Has not your (admitted) "messing around" (m.a.) culled you FAR from the herd?    

Might a "hybrid approach" better enable you to, "Drink from TWO cups" - rather than being "limited" to just one?

Use of a Windows Box - and your "messing around system" - satisfies (both) needs (m.a. and the ability to view multiple registers efficiently) - does it not?

One other method firm/I have developed is to have a, "Switchable Code Block" which regularly outputs, "Key/critical Register Data" - via SPI - to a dedicated display.   (similar to the "SWO function")

While you choose to, "distance yourself from the herd" - perhaps keeping their cries & tails (somewhat) in sight (as herein suggested) offers the best of two worlds.  (or cups)

Bob Crosby said:

Sorry I do not use OpenOCD. Since these are just memory mapped registers this is really a generic OpenOCD question. Have you asked there?

Good point, Bob.  Agree this is more of an OpenOCD question.  I've just located their forum and will follow up there.

cb1_mobile said:

Has not your (admitted) "messing around" (m.a.) culled you FAR from the herd?    

Might a "hybrid approach" better enable you to, "Drink from TWO cups" - rather than being "limited" to just one?

Use of a Windows Box - and your "messing around system" - satisfies (both) needs (m.a. and the ability to view multiple registers efficiently) - does it not?

One other method firm/I have developed is to have a, "Switchable Code Block" which regularly outputs, "Key/critical Register Data" - via SPI - to a dedicated display.   (similar to the "SWO function")

While your choose to, "distance yourself from the herd" - perhaps keeping their cries & tails (somewhat) in sight (as herein suggested) offers the best of two worlds.  (or cups)

cb1_mobile - Thanks for the reply.  Always appreciate your comments and analogies :)  Yes, I must admit that the GNU ARM Embedded Toolchain and OpenOCD debugger do not seem to be the well-beaten path of development and debugging but I can't help to quench my curiosity and interest of looking into the various ways different developers go about developing embedded software for this development board.

I like your suggestion.  If I'm understanding it correctly, I actually have been doing something similar recently, using UART0 and a terminal program (PuTTY) to display realtime logging information.

I'm curious,  can you clarify what you mean by "switchable" in your reference to a "switchable code block"?  Do you simply mean branching logic in code to display different information based on different conditions at runtime? 

Hi Terence,

With GDB you can query (eXamine) a register using the "x" command; for example: "x/x 0x400FE070" will show the contents of the system control RCC2 register. The /x is to format the response in hexadecimal.

Thank you - admittedly try to work in (some) humor - otherwise "all work & no play..." (adios motivation)

You have "bingo'ed" my intent via your recognition of "branching logic" which enables the most efficient "grouping" of different variables - based upon our current, "code area of greatest interest.     (for example - we may have a PWM Generator trigger the MCU's ADC - thus key registers from (both) peripherals are co-grouped.)      Another capability includes the: count, monitor & display of the "number of (actual or relative) entries into vital code blocks.      Note too - that we achieve this functionality while the code is RUNNING - not Halted!        You are clearly, sufficiently smart & aware - to create such implementation targeting (your) interests & applications.

May I note that our "hi-res" (800x480) TFT employs its own (dedicated) Cortex M7 (which runs at higher speed than devices here - AND includes a powerful, "Graphic Accelerator.")      This lessens the burden upon our "main work-horse" MCU - and better insures that our "measurement system/effort" does not weaken or confound our "work-horse MCU."

Still - multiple clients have "attempted" (variants) of your objective.       All too often - their bloody & bruised bodies - become viewable - although we must strain to look FAR from the known, SAFE, well-worn (MAIN) Trail...

[edit] Arriving 2 minutes prior to this post - one from "another" - which directed, "much keyboard activity (required my use of  "all 10" fingers - & "4 toes") - to obtain (maybe) the content of one register."    (Be still - my heart - assuming it survived the keyboard extravaganza!)      We usually process & display 5 -25 (believe that we've tested up to 30) registers - NO SUCH MANUAL DATA ENTRY/PROMPTING IS REQUIRED!      

I should note that our "Pro IDE" (IAR) includes a similar feature, "LIVE WATCH" and the ability to, "View key/critical Registers "On the Fly" (with no physical demands) has got to far exceed the key-stroked (one revelation at a time) intensely focused, alternative!        Note that our dedicated, high speed display method is NOT bound to Windows - thus seems a "high candidate" for your consideration...

Andrew_ said:

With GDB you can query (eXamine) a register using the "x" command; for example: "x/x 0x400FE070" will show the contents of the system control RCC2 register. The /x is to format the response in hexadecimal.

Hi Andrew, thanks for the response.  Yes, this is basically what I've concluded I must do, unfortunately it is not very quick as it requires looking up the memory address in the datasheet and typing it in.  I see there are macros in GDB, so possibly this is what people use who are using GDB for debugging.

cb1_mobile said:

May I note that our "hi-res" (800x480) TFT employs its own (dedicated) Cortex M7 (which runs at higher speed than devices here - AND includes a powerful, "Graphic Accelerator.")      This lessens the burden upon our "main work-horse" MCU - and better insures that our "measurement system/effort" does not weaken or confound our "work-horse MCU."

Interesting.  Yes, off-loading the display duties seems like a good tactic.

cb1_mobile said:

I should note that our "Pro IDE" (IAR) includes a similar feature, "LIVE WATCH" and the ability to, "View key/critical Registers "On the Fly" (with no physical demands) has got to far exceed the key-stroked (one revelation at a time) intensely focused, alternative!        Note that our dedicated, high speed display method is NOT bound to Windows - thus seems a "high candidate" for your consideration...

Yep, I hear you.  Having the IDE for debugging is definitely handy.

Might I note that the dedicated display - greatly duplicating the capability of the Windows-based IDE in terms of "multiple registers placed upon "automatic" display" proves (much beyond) "handy."     (the ability to watch variables "update LIVE" while code runs - proves "enormously valuable & insightful..."       And - as described - this "well meets" your specified requirement, "View Registers" when deploying "OpenOCD."

For the record - the early post (marked as verified) seems at best - to not have produced "verification!     (it directed you to vector, elsewhere - did it not?)     In terms of effort, clarity, originality (and "color") - another post (detailed) in your behalf - seems to "far better warrant"  Verification...