Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
Forum Thread Details
  • Replies 7 replies
  • Subscribers 666 subscribers
  • Views 596 views
  • Users 0 members are here
Related

Question Regarding Experiences With Internal Temp Sensor

ejohnfel

Hi All,

 

I have trying to track down a bug, either in my code, or with my Pi B or possibly a Adafruit RGB LCD Plate. Initially I thought the problem may have been with the Pi's thermal sensor as it had appeared from research that there was such a problem in the past.

 

However, I've run about a half dozen experiments to isolate the problem and it appears that any time I am outputting to the Adafruit LCD and reading the internal thermal sensor, the python script will freeze randomly over a couple of days of running.

 

The setup is basically, a Pi Model B, a Wyolum Alamode and the LCD Plate stacked on top with a ribbon cable.

 

The significant code in the python script is...

 

with open("/sys/class/thermal/thermal_zone0/temp","r") as file:

        value= float(file.readline().strip("\n"))

 

It always freeze either at the open or the read.

 

I also have a temperature sensor connected to the Alamode. If I read from the internal temp sensor and utilize the LCD (for example, to display the temperature), I get the random freeze. When I use the Alamode's sensor and the LCD, it runs no problem. I have also removed the LCD and read the internal sensor and... it runs no problem. So I'm kind of getting the impression the Adafruit LCD might be the problem. I am going to take this up with them at some point... but a final note, the LCD uses I2C for communications and I am reading from the Alamode over serial.

 

However, all that being said, has anyone else experience a similar problem or conflict while reading from the internal CPU temperature sensor... or have any ideas what might be the problem???

  • I would document all pins being used on what device in a table. Either there is an overlap or your voltages do not match. Check out this install guide too 3. AlaMode Arduino – Connect to the Pi’s GPIO | zapmaker and this one https://learn.adafruit.com/adafruit-16x2-character-lcd-plus-keypad-for-raspberry-pi?view=all. I am a bit puzzled how you connect the LCD on the Alamode without covering up the pins for the Arduino? Pictures may help.

    Clem

  • in reply to clem57

    Hi Clem,

     

    Thanks for the response. The two references you gave, I know them well already. I am pretty sure the LCD and Alamode are not interfering with each other since, when I use them without reading the CPU temp sensor, I get absolutely no problems. But as a just in case, I am running another experiment without the Alamode just to be sure.

     

    Please see the included picture. I basically extended the LCD out from the Alamode using and extra long Pi header and extension cable (both from Adafruit). In the photo, you can see the TMP36 sensor sticking out of the Alamode to the right. The Alamode, actually, mainly the AVR chip's function is to make sure the Pi and other hardware its driving, do not overheat and should that happen, will power the whole thing down until it cools off.

     

    Also, I have a similar setup already working. The basic difference is that there is no Alamode and instead of one controlling Python script I have two Python scripts and a few shell scripts that run independently to each other (ie. A shell script reads the temp sensor (and various other things) along with another python script to collect a little more data, then calls the final python script to display that data on the LCD.

     

    At this point, I suspect, its the Adafruit library code. Mainly because, the working project is using a much older version of the Adafruit code. The project in the picture (the replacement for the old one) uses a much newer version. I do know the script freezes while reading the internal temp sensor because of debugging code I have around the read and that flushes I/O on every write shows it does not complete.

     

    image

  • in reply to ejohnfel

    Are you talking about /opt/vc/bin/vcgencmd measure_temp for the internal Pi temps?

  • in reply to clem57

    Hi Clem,

     

    Tried that too. Also freezes when I try to run that via a python popen and parse the output. But no, I simply try to read the CPU temp from the class file /sys/class/thermal/thermal_zone0/temp. In fact, I just tried to "cat" it out and collapsed my latest experiment. Also, you bring up a good point, I am under the impression that the temp that vcgencmd is getting is from the same sensor in the class file, given the Pi is driven by a SoC and there is only one thermal zone. I also just got a Jetson TK1 and it has a boatload of thermal zones... after all, it does have 192 CUDA cores... anyhow... assuming its the same sensor, I also was curious if its a sensor for the video circuit or the CPU? I mean, either way, its getting the temperature of the SoC, which is good enough for my needs.

     

    I have already posted to the Raspberry Pi forum and no one has been able to reproduce the problem by, just reading the file alone. I can confirm that, I ran a test where all I did was read from the file and output to a log and stdout, it ran for 5 days, no problems. The x-factor here appears to be the LCD, except for the fact that, in a slightly different incarnation, minus the Alamode and some older code, its been working on a running project for months with no problems.

     

    I currently have the newer project reduced to the same hardware as the running project (I removed the Alamode) but I am still running on the newer LCD code and it just froze up.

     

    The only other thing I can think of, the older project reboots every night at mid-night, while the newer one does not. The older one reboots because sometimes the array of ASICs it controls, one or two of the ASICs go brain dead and a power cycle is needed to get them back up again. The old project cannot detect the failures, the new one can, so the new one does not reboot (or completely power cycle the system) until an ASIC in the array goes offline. Anyhow, my thought is, it might also be an "over time" issue that doesn't express itself when the Pi reboots every day.

     

    Anyhow, any thoughts would be appreciated.

  • in reply to ejohnfel

    The I2C hardware module in the raspberry pi is buggy. It claims to support clock stretching, but gets it wrong. The I2C spec requires a "clock high" of 5 microseconds when running with a 100kHz clock. But when the slave stretches the clock for 4.9, 9.9 or 14.9 microseconds, the broadcom will look at the clock (at 5, 10, or 15 microseconds) and see: Hey: it's high, so I can continue with the next LOW cycle. This results in a clock of only 0.1 microseconds, with "funny" results. Broadcom has known about this bug in the 2835, and apparently decided not to fix it for the BCM2836.

     

    When I see this bug, it leaves the bus in an invalid situation after one transaction, but after mangling the next i2c-tranaction, it recovers and the i2c-bus starts to work again.

  • in reply to rew

    Ok, now that is a golden nugget of info right there... I don't know if that's the problem, certainly seems it could be. Thanks Roger. It gives me an excellent place to focus my attention.

  • In case anyone was interested.... I know this is a bit late... I never solved the problem. I eventually went to the RPi foundation's forums to get help. I was very quickly slapped down; no one could reproduce the problem.

     

    There was one other person who was experiencing the same problem though.

     

    So the effort to figure out what was wrong went no where.

     

    However, some time later, apparently the bug reared its ugly head... it seems during the Sense HAT development and the AstroPi project it was discovered.

     

    So the RPi foundation finally acknowledged there was a problem and fixed it.

     

    The other person having the problem notified me that they had fixed it. I immediately downloaded the latest Raspbian and I can say for certain, the problem has been fixed. The original project that exhibited this bug, now works flawlessly.