CCS/TM4C123GH6PZ: if UART 5 Rx is disconnected , we are receiving the Fault ISR and and FAULT address is 0x20008000 which is above the SRAM size of 32KB

Greetings,

Feel your pain - yet the 'clue' you offer up - while perhaps 'necessary' - is not fully 'sufficient'  to enable full & resolving diagnosis.    

Might you be so good as to add:

• Does UART_5 'behave' normally/properly when (still) connected to your remote device - either (past) or present?
• If the above proves 'true' - what (likely) has happened between (past) success and your current situation?
• Have you 'ordered' this 'Disconnection' deliberately - perhaps as some test or (other) accommodation?
• Kindly further describe what is meant by your UART's being, 'Disconnected?'  
  • Are you 'breaking the connection' physically?   (i.e. 'Cutting the connecting wire.')
  • Or are you having the remote UART source - cease its output?
  • By 'disconnecting' - is the UART RX line (post the disconnect) then allowed to 'float?'

Questions, questions (I know) - yet these lead & guide to successful resolution.    More 'focused & complete' data, 'Speeds, Eases & Enhances' such 'Remote Diagnosis.'    (as we here are 'unable' to, 'See, Feel, Touch or sniff' - your MCU board!)    Allez!

• Does UART_5 'behave' normally/properly when (still) connected to your remote device - either (past) or present?
• • • Reply : Yes 

• If the above proves 'true' - what (likely) has happened between (past) success and your current situation?
  • • Reply :when connected works properly 
• Have you 'ordered' this 'Disconnection' deliberately - perhaps as some test or (other) accommodation?
• Kindly further describe what is meant by your UART's being, 'Disconnected?'  
  • Are you 'breaking the connection' physically?   (i.e. 'Cutting the connecting wire.')
    • Reply : yes we are disconnecting the RX wire physically
  • Or are you having the remote UART source - cease its output?
  • By 'disconnecting' - is the UART RX line (post the disconnect) then allowed to 'float?'
  • Reply : YES 
  •  

Hello Mallikarjuna,

In addition to cb1's guidance, it should prove helpful if you go through our Fault Debug documentation to see what you can track down regarding possible root causes for the Fault: http://www.ti.com/lit/an/spma043/spma043.pdf

Let us know your results with that debug and we can hopefully offer further feedback.

Hi Ralph,

I am (again) mobile - sea-side - and await client's delayed flight.   (thus here...)

Now I just spoke w/our young/gifted staff - and they assured me that we, 'Regularly Clip the connecting cable'  - joining one of our boards to multiple 'others' via RS485.   (balanced/differential signaling)    And NEVER do we, Enter into the Fault_ISR.   (this on our '4C123 boards - and also - on ARM Cortex MO, M3 & M4 of 'others.')   

In fact - our predominantly young/female staff have found this 'Deliberate Signal Clipping' to prove a 'Beyond Compelling, Board-Competency  Proof/Demonstration!'   Rather than succumb to 'Fault-ISR' - our boards, 'Quickly Detect' and/or 'Announce and Display' the Failure (most all of our boards support: OLED, TFT or character displays) - ideal for such 'Issue Identification.'    Then - once detected - and if the client has chosen the 'Back-Up Commo Channel Option' - our Board Switches to the (still uncut) backup channel - and communication is quickly and 'automatically' restored!    (Such proves an excellent Sales Tool - don't you agree?)

So - armed w/your (considerable) TM4C specific knowledge - might the loss of a physical connection (just as poster has noted) - be expected to 'Cause  entry to the always dreaded, 'Fault-ISR?'   (which appears to prevent the 'solid diagnostic routines' - which our boards ALL Perform!)    Unless such routines may be called - from w/in the Fault-ISR - and thus 'Escape that haven - and attempt some form of 'Auto-Recovery.'   (i.e. exactly as ALL of our boards - already do!)

Unless transients impact poster's UART_RX - is it your opinion - that a signal 'loitering' w/in 'No Man's Land' (neither @ logic Low or High) may trigger entry to (some say dreaded) 'Fault_ISR?'    If that proves true - then the earlier guidance here - which aims to prevent such 'loitering' - has earned its 'fair Splash of  Green.'    And I can continue my 'pool review'  - until client's plane passes overhead - on final...

it,s Great,

Thanks for your immediate support on FORUM

cb1_mobile : suggestion.

Proper logic level maintenance at/around UART_RX - along w/a protective series resistor (between UART_RX & the outside world) often will reduce - and (sometimes) correct such an unwanted event..

Reply :I think its solved the problem

As per your guidelines/Suggestion. 

1. Updated the hardware with resistor.

2. kept the module in observation for about 12 hours ,

3. will update the status once the testing completes from our end. 

My friend - the fact that you, 'Allowed yourself to be directed' (and followed the suggested guidelines) ...  was it not 'that'  (your willingness) which proved, 'Great!'    Good for you - and thanks for, 'Closing the Loop' - which (likely) enables this thread to 'benefit others!'    (Always a cb1 goal...)

Now to be thorough - you've marked your post as the, 'Verified Answer.'    Yet in fact - was it not (my post) - which 'Identified the likely 'Transient Impulse(s)' - and which offered up (multiple) effective 'Counter-Measures?     That then - is the post which should be marked as, 'Verified Answer' - is it not?   (i.e. your post 'Confirmed' that my earlier posting proved correct - and 'Resolved your Issue.'

To your latest question - I've (earlier) asked vendor's (skilled) agent 'Ralph' to comment upon the, 'Likelihood of such a 'Transient Attack' - to generate a, 'Trip to the Fault_ISR.'    

My small firm has NOT observed this behavior - either upon our TM4C123s - or multiple other ARM Cortex M0s, M3s, M4s and M7s.    (while our 'other' branded ARM MCUs do not employ (this vendor's) 'Fault_ISR' - they have (similar)  'protective & trap-mechanisms' - specially designed to assist in the 'Eased recognition' of, 'Fault Cause & Effect!')

Firm/I have not employed the MSP family for over a decade.    Perhaps those MSP boards 'employed' such protections - as I earlier recommended.    We find the M0 & M3 (again ARM devices) superior - thus we are unable to offer MSP guidance.    (And - should not  that MSP issue generate an independent post?)   Cramming too many subjects w/in one thread - makes the final 'classification' of such (over-loaded) thread - beyond difficult!

My time here draws to a close - not all here prove as, 'Accepting & Appreciative' as you - and my preference is to, 'Venture ONLY where one IS truly appreciated!'

My friend - it is noted that  'STILL' - that post (i.e. my past post) which effectively 'Directed You' to your issue's resolution'  has not been 'Marked as the VERIFIED ANSWER!'

That post 'July 16 @ 10:04' (the 4th post from the top) - apparently 'Marked by the Vendor as a 'Suggested Answer' - more properly was the  REAL ANSWER - thus 'it' should be awarded the

Green, "THIS POST RESOLVED MY ISSUE" click.   (the posts you are presently 'marking' (your own (only) confirm) that the earlier post - was in fact - the 'TRUE, ISSUE RESOLVING POST' - and thus warrants such (proper) award!

Aha - 'Mission Accomplished' - thank you, my friend.

For years I've suggested that, 'Better Forum Guidance' IS needed.    (which may prevent - or at least reduce - 'Verification Issues as arose here.')

I wish you the best in your development efforts - do continue in your logical progressions and systematic analysis...