Strange Problem on Prop LCD controller board

T Chap

In the past when a stack overflows or variables are overwritten, it is pretty easy to track these issues down and the crash is usually obvious about the reasons. I have a Prop controller board that drives and cap touch LCD screen. The code has been stable for a year, then last week I made a lot of changes to the screen adding a menu method of scrolling to options for change versus having dedicated graphic buttons you would touch to access a value to change. The LCD Driver has not changed at all. Over the past week, about 3 different occasions the screen has turned solid white and the piezo buzzer started making a consant screeching sound as if the Prop was sending it random signals versus a steady frequency for beeps.. The instances were all such that the module had not even been touched for many hours( possible last touch was 5 to 12 hours), and while sitting in the main loop there is nothing happening other than reading for touch input info. A stack overflow is usually instant and you can usually find cause and effect relationships by using the device. In this case there is no cause and effect so I am trying to figure out where to start to diagnose. Any ideas on how to chase down a problem like this? The code is to big and messy to post. 7209 longs, 4308 lines of code compiled.

Here is the main loop. It just sits waiting for touch, the omron sensors are disabled in the menu to they are not being read.

PUB RunLoop   |  h
  i2c.initialize
  i2c.StartCapTouch
  i2c.WriteThreshHold($30)     '46
  i2c.WritePeak($c0)  'c0
  MenuCount~
  AllowWatch := 1
  AllowAdjust := 1 
  ValueChange := 2    'neutral value   fix
  ButtonType~   ' ?
  repeat 
     'beep2500
     ValueChange := 2
     'w(10_000_000)  ' set loop rate /*
     ReadOMronA    '   *** DISABLED, not even being read still causes crash
     ReadOMronB    '   *** DISABLED, not even being read still causes crash
     ReadOMronC   '   *** DISABLED, not even being read still causes crash
     tempcount := cnt
     'helpclearcounterval := 5000
     IF ReadTP== 1     'there a response from a touch
         CheckMainButtons(touchx/16,touchy/16)  ' - /  +    Menu < >    button input
         PaintMainParts      '  print($100) erase screen and add parts back per menu requirements
         UpdateMenu          '  IF MenuChanged == 1     if menu changed  ESTABLISH MODE#
         EnterMode             '  Get mode of button pressed then parse the mode  USE MODE#
         'WaitTouchRelease   ' do not wait for release
         w(5_000_000)  
         'HelpClearFlag := 1
         IF A_on + B_on + C_on == 0   ' if all sensors are off, the loop goes too fast (buttons too fast) 
              helpclearcounterval := 10000
              w(10_000_000)   
         elseIF A_on + B_on + C_on ==1
              helpclearcounterval := 150
              w(4_000_000)   
         elseIF A_on + B_on + C_on ==2
              helpclearcounterval := 150
              w(3_000_000)   
         elseIF A_on + B_on + C_on ==3
             helpclearcounterval := 150
         ShowEscapeicon := 1
         PaintEsc
     ButtonType~ 
     AClearA         'A>  Trig part 1 clear graphic icon
     ABClearA
     AClearB
     ABClearB
     ClearContact1
     ClearContact2
     IF ClearArrayFlag == 1
       IF Cnt - ClearArrayCnt  > 160_000_000
         'beep2500
         ClearArrayFlag++
         ClearArrayCnt := cnt
     IF ClearArrayFlag == 2   ' this is a backup plan to clear array
           IF Cnt - ClearArrayCnt  > 160_000_000
             'beep2500
             ClearArrayFlag~
     IF HelpClearFlag == 1    ' set in ReadTP    ***RESET SCREEN AFTER X seconds idle***
       helpclearcounter++
       IF  helpclearcounter > helpclearcounterval     'may set this rate based on how many sensors scanned
         beep2500
         ShowEscapeicon~
         helpclearcounter~
         helpclearflag~   
         LockStatus := 1 
         prgmode := 0   ' time out PRG icon input
         'ClearProgramScreen   ' no longer needed
         Unlock~ 
         Mode~    '  kill MODE to stop any array edits.  
         MenuCount~
         PaintMainParts
         PaintWatch
         UpdateWatchValue
         PaintAdjustSection
         AllowWatch := 1
         IF Watch == 0
            IF A_on == 1
              PaintArrowGreen 
              PaintBoxNumbers
         elseif Watch == 1        
            IF B_on == 1
              PaintArrowGreen
              PaintBoxNumbers 
         elseif Watch == 2  
            IF C_on == 1
              PaintArrowGreen2

kwinn

That's a tough one. Any cogs and pins free to use as a watchdog timer/execution logger?

T Chap

Discovery. It locked up again just now after about 8 hours, so I kept it on and used a scope and meter to see what was going on. There is a main input 5V LDO regulator that receives exactly 12VDC from a wall mount supply. The 5V feeds a 3v3 LDO. When locked up, the frequency of the piezo screeching increases as I press on the regulator. The 5V reg output voltage is 2.5V when locked up, so this looks like the 5V reg is going into oscillation. The only new thing is that is always have used a 6VDC input, but this time I used a 12VDC input since I was out of the 6.

http://www.st.com/web/en/resource/technical/document/datasheet/CD00000443.pdf

The 5V LDO claims 16V max. I am using a .1uf, 10uf non electro on both the input and output of the regulators, same design as I have done for years with no issue. Maybe the 12V is the problem. I can't see how this could be going into oscillation. I think the regulator is running too hot so the temp may be affecting the nearby capacitors. I will switch back to the 6VC input.

kwinn

The 12V is most likely the problem. I have seen that problem with 3 terminal regulators many times when they are near the overtemp shutdown point. You wouldn't think it would oscillate at such a high frequency but it does.

kwinn

BTW, the regulator will work fine at 16V as long as the current draw is low enough that the regulator does not overheat.

T Chap

Thanks for the info Kwinn.