TM4C123GH6PM: TM4C123GH6PM

Greetings,

May it be noted that your post (your 'first ever' post here, btw) is, 'Off the Charts well thought' -  & contains (likely)  the 'most exhaustive (helpful) array of comments' - ever witnessed here!     (this from a poster here from the earliest 'Luminary Micro' days ... that firm subsequently acquired by this vendor...)    It must be that you've (other) MCU background & experience - and it rings poetic - that you now arrive at 'other's' MCU Forum.    (how proud the parent/producers must be - to quite deliberately - 'craft' such a name!)

Now your code is implemented in a perfectly 'reasonable' Direct Register style - yet that may 'not' prove to your advantage:

• Direct Register Manipulation requires highly detailed examinations of multiple MCU Registers - both Control & Peripheral - and that requires significant time/effort.
• While in 'No way' reflecting upon you - such 'DRM' code - due to the 'volume of exacting detail' - is prone to uncertainty & mistake 
• And due to that 'volume of exacting detail' - and the fact that 'each/every code generation is unique' - the demands forced upon 'diagnosis' are high
• Vendor has long supplied a, 'Far more Usable & Succeeding Alternative' - that being the TM4C family's 'API.'    Unlike unique 'DRM code' - the API has a 'years long' history of success - thousands have employed it - and in almost all cases the resulting coding efforts have enjoyed, 'Speed, Ease & Enhancement.'    Thus this vendor (and others) will most always 'Steer users' toward the API - and away from 'DRM!'
• It is (beyond) strongly recommended - that you contact the sensor vendor - and determine, 'How the sensor may be 'basically tested' - to insure that, 'Intense & Prolonged diagnostic efforts are not launched - while unneeded!'    (Note: my firm 'deservedly charges' clients who claim 'all is well' - when it can be well proven - that such proved untrue!)     It is, 'w/in the realm' - that MCU AND Sensor issues (together) are both being encountered - although (only) the MCU - or the sensor alone - may be at fault...

Within that background -  (Should you desire to, 'Keep your present code - and as intact as possible') you might:

• clearly (further) identify and/or 'divide your existing code' into 'stand-alone' code blocks or code segments
• deploy 'KISS' to systematically, 'test & verify' each of your individual code blocks or segments
  • you must create easily 'measurable tests' for each such code block - so that you can positively confirm that it succeeds
  • certain code blocks (may) require 'inputs' from (other) code blocks.   (which may be unavailable)    In such cases employ 'dummy values' - so that your code block may (still) be tested.
• 'KISS' informs & advises that you 'start' from the simplest code blocks - and proceed methodically to the most complex.   Again 'always' testing - so you 'know' each block behaves & performs
• the likely 'final steps' in this 'code build & evaluation process' will see you, 'Pass data to & among various code blocks - each one contributing - to the 'successfully executing program!'

As the vendor is 'unlikely' to, 'Review & Advise' when presented w/'Your 'DRM code' in its (present) entirety' - your following the 'game plan' (authored by 'KISS', above) should enable you to, 'Discover & then Highlight'  (i.e. 'Present to the vendor') 'ONLY the code block (or blocks) which appear suspect!   

Vendor agents ARE skilled & dedicated - by limiting their 'Field of Battle' (my objective, here) - you stand the greatest odds of, 'Vendor Quickly & Efficiently - guiding you to a robust solution...'

Hello Hossam,

We do not support Direct Register Modification (DRM) only programming on the E2E forums. This is stated on our forum guidelines see item #4. For your application, we strongly recommend that you instead use TivaWare.

You can download TivaWare from: http://www.ti.com/tool/SW-TM4C