DS1822

[MMG135]

Hi there,

I am using a 13192-EVB board from Freescale. It has a MC9S08GT60 MCU. I am trying to get the DS1822 temp. sensor to communicate with the MC9S08GT60. I keep getting a temperature value of -255 all the time. Was wondering if someone can help me troubleshoot the issues I'm having. I'm using a 4.7 k pullup resistor and I am providing approx. 5V to power the DS1822. I am connecting a wire from pin 2 of the DS1822 to one of the IO pins (J107) on the 13192-EVB boards. I have pasted the code below to see if someone can help me. I am not sure if I have the bus speed configured correctly. I was using the Device Initialization Expert and I enabled the FLL clock to try to manually set the internal bus frequency to approx. 8 Mhz (7.776 Mhz is the closest I could get). I think that is what the code requires according to the delay function that I am using, but I could be wrong. Also in the device initialization expert I enabled PTA0 and PTA1 for input and output respectively with pullup enabled. The problem is when I compile the code and run it - I keep getting a uiTemperature value of -255. I don't know what the problem is. It seems to me like the DS1822 is just not communicating properly with the MCU and that the timing (delays) must be wrong. Would really appreciate all of your thoughts on this. Thanks.

Here are the definitions:

#define TRUE 1
#define FALSE 0


#ifndef PORTS_DQ
#define PORTS_DQ 1
#define DQ_RX     PTAD_PTAD0
#define DQ_TX     PTAD_PTAD1
#define DIR_DQRX  0
#define DIR_DQTX  1
#endif

[JimDon]

Yes, the pin does need to be driven high.

Again:

However, when the DS1822 is performing temperature conversions or copying data from the scratchpad memory to EEPROM, the operating current can be as high as 1.5mA. This current can cause an unacceptable voltage drop across the weak 1-Wire pullup resistor and is more current than can be supplied by CPP. To assure that the DS1822 has sufficient supply current, it is necessary to provide a strong pullup on the 1-Wire bus whenever temperature conversions are taking place or data is being copied from the scratchpad to EEPROM. This can be accomplished by using a MOSFET to pull the bus directly to the rail as shown in Figure 4. The 1-Wire bus must be switched to the strong pullup within 10μs (max) after a Convert T [44h] or Copy Scratchpad [48h] command is issued, and the bus must be held high by the pullup for the duration of the conversion (tconv) or data transfer (twr  = 10ms). No other activity can take place on the 1-Wire bus while the pullup is enabled. 

If you run the part at 3.6 v, at .5v drop (spec for the output) should still leave 3.1 v, but the output must be high.

[MMG135]

Thanks so much Mac and Jim. I finally got it working in parasitic mode! I ended up just having to use a second GPIO pin to drive the bus high during the conversion time. After I did this, everything seems to work fine!

[JimDon]

Glad we could help....

I figured that since it worked in non-parasite mode, it must be that it was not getting enough current in parasite mode.

Just for fun, (carefully) dunk the sensor rapidly boiling water to see if it works at 100C.

[JimDon]

Not sure if this has been mentioned but to use parisite power you MUST have a mosfet to pull up the pin.

"However, when the DS1822 is performing temperature conversions or copying data from the scratchpad memory to EEPROM, the operating current can be as high as 1.5mA. This current can cause an unacceptable voltage drop across the weak 1-Wire pullup resistor and is more current than can be supplied by CPP. To assure that the DS1822 has sufficient supply current, it is necessary to provide a strong pullup on the 1-Wire bus whenever temperature conversions are taking place or data is being copied from the scratchpad to EEPROM. This can be accomplished by using a MOSFET to pull the bus directly to the rail as shown in Figure 4."

Also:

"The use of parasite power is not recommended for temperatures above 100°C since the DS1822 may not be able to sustain communications due to the higher leakage currents that can exist at these temperatures. For applications in which such temperatures are likely, it is strongly recommended that the DS1822 be powered by an external power supply. "

[MMG135]

I just wanted to mention as well that each Zigbee packet in this case is 10 bytes and it requires that I transmit a '0' to begin. This is why every transmission starts with a zero and then I transmit the temperature information 9 times after that. I should also mention that it is not necessary for me to use the smac_per_tx application to transmit the DS1822 temperature information. If you know of a simpler zigbee application that I could use, I would gladly use that as well. I am basically looking for the simplest way to take the data from the DS1822 and transmit it via Zigbee to another 13192 EVB-board. The number of transmissions I require is not more than 10 measurements per day for example but more measurements would not be a bad thing if that is easier to implement. I suspect it is the same difficulty to implement 10 measurements or greater than 10.

[MMG135]

I'm also posting some code that I found that implements the Search Rom algorithm to read multiple DS1822's. The code isn't a complete program but I believe it contains the necessary functions I will need. I have modified it to use the functions that you posted. I was hoping you could take a quick look and let me know if it looks ok. I will try to implement and test this in the next couple of days.

[MMG135]

Hi Mac,

It finally works! I'm able to make reliable temperature measurements with one DS1822 sensor. Thanks for all your help. The next step is: I have to modify this code to include a "search ROM algorithm to display values from multiple DS1822 sensors (up to 6). I'm assuming, to display values from multiple sensors, I will need this algorithm. I have to integrate this code into that Zigbee application I was mentioning before so that I can transmit the temperature information wirelessly to another 13192-EVB board. I know the Zigbee application uses 8 Mhz so I may have to either try to modify the Zigbee application to use 4 Mhz or modify the 1wire code to use 8 Mhz instead of 4. Also, I have to change the code in order that it works in parasitic mode. From what I understand, the only change I need to make is: disable polling to see if temp. conversion is complete and enable strong pullup while temperature conversion is occuring (or alternatively can I just set the GPIO pin to output and then make the output high?). Of course I would only be able to do this while conversion is taking place and then stop this operation once conversion is complete. Any suggestions as to how I could best implement this only during temperature conversion? Thanks for all your help.

[MMG135]

Hi Mac,

Would you say it is essential to have a common power source for both the DS1822 and the MCU? Is this required to enable the proper functioning of the pullup resistor when the GPIO pin is in High-Z state? Hypothetically, if a common source is not possible between the DS1822 and MCU and I did not want to go to a separate MCU, could I use something like the DS1WM (1 Wire Master) from Maxim and feed the output into the MC9S08GT60 via one of the GPIO pins and then transmit this data via Zigbee using the same 13192-EVB board. Here is a link to information on the DS1WM: http://www.maxim-ic.com/datasheet/index.mvp/id/2834. If I need to get a separate MCU and go that route I will. 

[bigmac]

Hello,

---

MMG135 wrote:

Would you say it is essential to have a common power source for both the DS1822 and the MCU? Is this required to enable the proper functioning of the pullup resistor when the GPIO pin is in High-Z state?

---

What I was previously referring to was the Vdd voltage applied to the MCU.  If you are using a plug pack as the primary source, its output will be regulated down to 3.0 or 3.3 volts.  To avoid any potential damage to the MCU, the pullup resistor must be returned to a similar voltage level (the GPIO pins are not 5 volt compliant).

If you were to then connect the DS1822 to 5 volts, rather than the lower voltage level, it is possible that a 3 volt maximum at the DQ pin might be insufficient for proper logic switching within the device.  You will need to check the datasheet for the DS1822 to see if this is so.

---

MMG135 wrote:

Hypothetically, if a common source is not possible between the DS1822 and MCU and I did not want to go to a separate MCU, could I use something like the DS1WM (1 Wire Master) from Maxim and feed the output into the MC9S08GT60 via one of the GPIO pins and then transmit this data via Zigbee using the same 13192-EVB board. Here is a link to information on the DS1WM: http://www.maxim-ic.com/datasheet/index.mvp/id/2834. If I need to get a separate MCU and go that route I will. 

---

This device uses a parallel interface, and would require access to many more GPIO pins.  This would not solve the interface problems that you may have.

I notice that there are other versions that have a IIC (or I2C) interface.  These might be useful should the disabling of interrrupts during one-wire communications prove to be problematic for Zigbee operation, particularly with the longer duration one-wire reset pulse.  However, significant additional code would be necessary for the operation of the IIC module.

Regards,

Mac

[MMG135]

Hi Mac,

Thanks for the reply. I think we may have found my problem then. I was powering the DS1822 and the MCU from different power sources. I believe these two sources also had slightly different voltages. The source I was using to power the DS1822 was 5.16 V. I was plugging the wall adapter directly into the demo board (13192-EVB) to power the MCU. I'm not sure if it is possible to power the demo board and DS1822 from a common source. The 13192-SARD and the 13192-EVB boards are the ones that I have. The 13192-SARD does allow for separate 9V power as well as plugging it in from a wall outlet. However, it doesn't seem like I would be able to use the 9V power since I would not be able to power the DS1822 with 9V.  It takes between 3-5.5 V according to the manual. There is one more option I can think of but I'm not sure if it will work. The 13192-SARD boards that I have come with separate 3V pins that are attached to the board itself. The 13192-EVB does not have this. Would I be able to power the SARD board via the wall adapter and then use the 3V supply onboard the SARD board to power the DS1822? As a last resort, if I could provide exactly 5 V to the DS1822 and 5V to the MCU via the wall adapter, even though they are separate sources, would this work? If this option won't work I suppose I would just have to get  a separate standalone MC9S08GT60 MCU and power it separately. In other words, I would not be able to use the integrated demo board and MCU for this application. Am I right in assuming this? Thanks for your help.

[MMG135]

To be a little more clear regarding my previous post, I should mention that I also used device initialization to set the bus clock to 4 Mhz. However, when actually compiling and running the code in Codewarrior, it shows that the actual bus speed is always around 4.19-4.20 Mhz. More recently it has been running closer to 4.20 Mhz so I decided also to try setting the bus speed definitions in the header files to 4200000. I am not sure if this would alter the delay functions at all but I just wanted to mention it.

[MMG135]

Hi Mac,

That information is very helpful. Would something like this be correct for using a single GPIO pin to interface with the 1-wire device? Also, if I have an external pullup resistor would I need to have a definition at the bottom for a pullup? Am I correct to assume that if I use ONE_WIRE_SET_LOW it will drive the bus low and ONE_WIRE_SET_HIGH will set the GPIO pin as an input and the external 4.7k pullup resistor will cause the bus to be pulled high?

#define ONE_WIRE_PIN                  PTCD_PTCD4
#define ONE_WIRE_DIR                  PTCDD_PTCDD4

//1-Wire pin management
#define ONE_WIRE_SET_LOW                        ONE_WIRE_DIR = 1; ONE_WIRE_PIN = 0;   //output
#define ONE_WIRE_SET_HIGH                       ONE_WIRE_PIN = 0; ONE_WIRE_DIR = 0;   //input
#define ONE_WIRE_SET_STRONG_PU        ONE_WIRE_PIN = 1; ONE_WIRE_DIR = 1;

[MMG135]

Hi Mac,

Thanks for the reply. Would I be able to use that delay you mentioned sequentially. For example, if I am using an 8 Mhz bus and I want a 470 us delay, can I write the following statements, or will there be a significant overhead delay if I run delays sequencially like this:

DELAYUS(128);

DELAYUS(128);

DELAYUS(128);

DELAYUS(86);