Hi Team,
We are using the S32K388 MCU. We have a developed a piece of code to read the temperature of the MCU using the available TEMPSENSE module of S32K388.
The required MCAL modules are configured including the ADC. We have enabled the below marked parameters as per the user manual. We are testing this on S32K388 Evaluation board.
We are having the UART command so that when the user types the command from the serial terminal, the MCU software reads that command and then reads the internal temperature of MCU using the API Adc_TempSenseCalculateTemp and prints the read results.
As the document says, the read value from the above API is in fixed point format. I have converted these values to the floating point value and printed both the values in the serial terminal.
Below is the command log copy (read multiple times continuously). The yellow highlighted values are converted floating point values while the blue ones are the fixed format value read from the above API.
I have observed that the read values change drastically, and the values are ranging from 120 degree centigrades to 190 centigrades. And I doubt that the read values are not correct.
Could you please check and let us know your opinion on the above values?
Also, I checked the result register for the temperature sensor (ADC channel 49) which is ICDR17 and it' s value keeps changing continuously.
Coming to the configuration we have configured one ADC channel where we have connected external temperature sensor and we are enabling the group conversion, wait for the end of conversion notification function for this group, read the result. Once we readout the external temperature sensor value, then call the function Adc_TempSenseGetTemp to get the temperature from the MCU TEMPSENS module. Since the manual says that the above function is a synchronous call which enables the temperature ADC channel 49, start the conversion, wait for the conversion to complete, read the ADC values, calculate the temperature based on the read value, disables the ADC channel 49 we haven't configured the ADC channel 49 separately.
I met something similar in the past and it was caused by too short sampling time. It can significantly affect the accuracy. See please the requirement below:
Regards,
Lukas
Hi Lucas,
I am reading the values directly from the API Adc_TempSenseGetTemp which will return the temperature value in the fixed point number format.
I tried printing the read value and below are the values in fixed point format.
"Temp in Fixed point format : 0xb55
Temp in Fixed point format : 0xb56
Temp in Fixed point format : 0xb55
Temp in Fixed point format : 0xb55
Temp in Fixed point format : 0xb53
Temp in Fixed point format : 0xb55
Temp in Fixed point format : 0xb55"
The values are equal to approx 181.2 degree in floating point number format. I verified this conversion as well from the online tool Fixed-point-float-point-conversion . This value is when I tried flashing the same code in the other board.
I got the response right now. See please below. It's a problem of RTD:
***
I reviewed this case and tested the internal temperature sensor. I used RTD 4.0.0, and it seems that it is a TempSense API problem. The Adc_TempSenseGetTemp() returns an incorrect convert value, but if we calculate as the RM says, we can get the internal die temperature correct:
First, let me show you my RTD environment:
Once the temp API, the VREF, and the channel ADC group are set, We can read the ADC temp sensor Vest:
So as the RM says:
Making the calculation with a 14bit resolution ADC:
VETS = 5687 * (5V/2^14) = 1.7355
we need also the TCA0, TCA1 and TCA2 values:
Those values are in fixed point, so if we make a conversion:
TCA0 = 0x1A4E = 420.875 C
TCA1 = 0x8AFE = -175.875 C
TCA2 = 0x81DE = -29.875 C
Then, we can apply the formula:
TETS = 420.875 + (-175.875 * 1.7355) + (-29.875 * 1.7355^2) = 25.66 °C
25.66 C will be the correct internal temperature because I also get incorrect higher temperatures with the API, but it seems that is due to the RTD version:
Let me address this issue with the SW team to fix this issue.
Hi Lukas,
Thank you for the explanation. I want to highlight few observations.
The reference voltage supply is 3.3V not 5V. Value 53 in hex is 0x35 which is in fixed point format. Converting it to float point format, it is 3.3V. With the same formulae whatever you have used and the voltage supply of 3.3V will produce almost same result as being generated from the Tempsense API.
Could you recheck once again?
Here's the response:
Thanks for the observation. Changing to 5V (0x80):
ADC Value group:
VETS = 5677 * (5V/2^14) = 1.732 V
TCAx Values:
TCA0 = 0x1A4E = 420.875 C
TCA1 = 0x8AFE = -175.875 C
TCA2 = 0x81DE = -29.875 C
So the temperature will be:
TETS = 420.875 + (-175.875 * 1.732) + (-29.875 *1.732^2) = 26.63 °C
Results are still similar to the ADC Voltage supply reference of 5V.
Hi Lukas,
Lot of confusion is going on.
The design what we have is that the ADC reference voltage and the tempsense module supply voltage is 3.3V. So the read temperature value for these voltage supply values should be the valid values. We cannot change the reference voltage value to 5V.
As per the above response, I can see that only the tempsense supply voltage is changed to 5V. While debugging the code I found that if the ADC reference voltage value is more than the tempsense module supply voltage, then only the tempsense supply voltage is used for the calculation of the temperature value. Otherwise, always the ADC reference voltage is used of the calculation.
If the above parameter is not changed to 5V, the temperature calculation will consider the ADC reference voltage value as 3.3V for the calculation.
As per our requirement, both these voltage values should be configured as 3.3V and the read temperature value should be the valid value.
Please give us the analysis why the temperature value is around 180 degree centigrade when the ADC reference voltage as well as the tempsense supply voltage is 3.3V.
Please let us know is it the issue with the RTD package and if yes what would be the timeline to get it fixed?
Request you to check this on priority as the ticket is open for more than a month and this is a blocker for us.
