3 years, 3 months ago.

DS18b20 with STM32L072CZ

Hi,

I am working on the Lorawan discovery board and a DS18b20 digital temperature sensor. I open in the mbed compiler the DS1820_HelloWorld project and target the B-L072Z-LRWAN1. But it prints nan value when I run it on the STM32 board.

I connected the sensor on GND, 3.3V and D6 connectors pin. But I didn't use the 4.7k resistor.

Do you think not using the resistor is what raising this value ? (I didn't use the resistor because I haven't received the resistor yet)

Hi there, missing resistor probably won't be a problem. I tested that (3,3V no resistor) on my Nucleo board and it works well. Maybe more information will help. What example of DS1820_HelloWorld exactly you use? etc.

posted by Jan Kamidra 03 Apr 2019

I imported this examplehttps://os.mbed.com/users/hudakz/code/DS1820/ on the online mbed compiler. I retest this morning and now it prints :

No DS1820 sensor found!

But it's connected to D6 and I declared the pin in DS1820 probe(D6)

I tried with another sensor thinking mine was bad but prints the same output

posted by elisa scheer 04 Apr 2019

1 Answer

3 years, 3 months ago.

Hi, again I did some tests. Since I do not have same board like you but I have a Nucleo-L152RE and I detect same problem as you described. However when I changed the mbed os2 revision from 165 to 163 the sensor start working correctly but only without the pullup resistor.

On Nucleo-F446RE no problem detected, it looks like L series problem. I read a discussion about STM are slow with GPIO change between input / output mode or something else.

Maybe info from these discussions will help you. https://os.mbed.com/questions/84803/STM-devices-broken-with-upgraded-mbed-os/#answer16247 https://os.mbed.com/forum/component-128-DS1820-community/topic/26713/?page=1#comment-61240

Best regards J.

Hello Elisa and Jan,

STM32L072 chips seem to be much slower than other targets in regard with changing a GPIO from digital output to digital input and reading the input status. It's most likely because there are several layers of software translating the Mbed user friendly commands into hardware accesses. I have recently made an attempt to remove some of them in the latest revision of DS1820 / OneWire library. However, because I do not have access to such boards I was not able to perform any tests yet. Therefore any feedback is welcome. Best regards, Zoltan.

posted by Zoltan Hudak 04 Apr 2019

Hi Jan and Zoltan,

So I tried to switch from revision 165 to 163 but it prints always same output : No DS1820 sensor found!

I re-switched to 165 revision and tested with the latest revision of your library Zoltan and got same output.

Yes I read about that STM32L072 chip are slow and so I tried to tune (increase/decrease) the time that OneWire is waiting for DS1820 to pull up/down the wire as suggested in https://os.mbed.com/questions/83506/Failure-to-read-with-temperature-sensor-/ But I got no results

Kind regards

posted by elisa scheer 05 Apr 2019

Hello Elisa,

Could you please:

  • Open the https://os.mbed.com/users/hudakz/code/DS1820_Hello/ example program in the online compiler. Right-click on the "DS1820" folder and select Update...
  • Navigate to "DS1820/OneWire" folder and open the "OneWire.cpp" file for editing.
  • Search for the uint8_t OneWire::read_bit(void) method and un-comment the line

   //printf("t = %d\r\n", t);
  • Recompile the project and then run it on your STM32L072 target board.
  • Let me know the printouts.
posted by Zoltan Hudak 05 Apr 2019

Ok so I did steps as you suggested and the program output is :

lastAddr = 0 0 0 0 0 0 0 0
t = 14
t = 156
No addresses.
No DS1820 sensor found!

posted by elisa scheer 05 Apr 2019

When I reset several times I got printouts :

--Starting--
lastAddr = 0 0 0 0 0 0 0 0
t = 14
t = 14
No addresses.
No DS1820 sensor found!

--Starting--
lastAddr = 0 0 0 0 0 0 0 0
t = 14
t = 155
No addresses.
No DS1820 sensor found!

posted by elisa scheer 05 Apr 2019

I'm not very optimistic but let's try something like:

uint8_t OneWire::read_bit(void)
{
    //const int SAMPLE_POINT = 10;
    uint8_t r;
    //int     t;

    OUTPUT();
    WRITE(0);
    //timer.start();
    INPUT();
    //t = timer.read_us();
    //if (t < SAMPLE_POINT)
    //    WAIT_US(SAMPLE_POINT - t);
    r = READ();
    //timer.stop();
    //timer.reset();
    WAIT_US(55);
    //printf("t = %d\r\n", t);
    return r;
}

If it doesn't help then I'm afraid I have no more tips for now. But let me know how it worked. Thanks. Zoltan.

posted by Zoltan Hudak 05 Apr 2019

Thanks for your help, anyway it didn't work. I'll tell if by luck it works :)

Best regards

posted by elisa scheer 05 Apr 2019

Hi Zoltan and Elisa, I have some news from my investigation… ofc it was tested on my Nucleo-L152RE

For me the problem was not with speed of the GPIO pin toggling from Output to Input but with the Timer. I will show...

Zoltan's code from another qvestion

/*https://os.mbed.com/forum/component-128-DS1820-community/topic/26713/?page=1#comment-61240*/

    line.output();
    timer.start();
    line.input();
    printf("delay1 = %dus\r\n", timer.read_us());
    timer.reset();
    line.read();
    printf("delay2 = %dus\r\n", timer.read_us());

The output values from this are 16us and 12us. But when I tried to test timer alone

timer test

    timer.start();
    printf("delay1 = %dus\r\n", timer.read_us());
    timer.reset();
	timer.stop();

The output value from this is always 12us. After this measurement I comment the code about the timer in the read_bit method and now working for me.

OneWire::read_bit

	uint8_t OneWire::read_bit(void)
	{
		const int SAMPLE_POINT = 10;
		uint8_t r;
		//int     t;

		OUTPUT();
		WRITE(0);
		//timer.start();
		INPUT();
		//t = timer.read_us();
		//if (t < SAMPLE_POINT)
			WAIT_US(SAMPLE_POINT); //- t);
		r = READ();
		//timer.stop();
		//timer.reset();
		WAIT_US(55);
		//printf("t = %d\r\n", t);
		return r;
	}

Maybe would be better cut off this timer from this method and make a calibration method and call it in the constructor of the OneWire library before all others settings and output of this method use later for correction of the read_bit method. It is not tested it is only an idea, something like that...

delay caibration

	int timer_err, toggle_time; //private variables of the OneWire library
	
	void OneWire::timer_calibration(void){
		Timer time;
		DigitalInOut line(PIN);
		timer.start();
		timer_err = timer.read_us();
		line.output();
		timer.reset();
		ine.input();
		toggle_time = timer.read_us() - timer_err;
		timer.reset();
		timer.stop();	
		If (toggle_time > 10){
			printf("OneWire not working on your target!\n");
		}
	}

I do not know if this information help but for me yes.

posted by Jan Kamidra 11 Apr 2019

Hi Jan,

I already tried with commenting the timer as suggested Zoltan but it didn't show results. I think the board I'm using (chip STM32L072CZ) is really really slow and so it seems really difficult to adapt the time between input and output. I really don't know if the sensor is able to work with my board. I read about using the FastIO library instead of DigitalInOut.

posted by elisa scheer 12 Apr 2019

Hi,

but Zoltan let you comment the timer together with WAIT_US(SAMPLE_POINT) line because he thinks about the timer works correctly. Maybe you are right and the problem is really with your boad (DISCO-L072CZ-LRWAN1). However I probably will buy this boad so we will see in the future.

Best regards J.

posted by Jan Kamidra 12 Apr 2019

Yeah sorry, I tested also with letting the WAIT_US(SAMPLE_POINT) and got the same result. Okay Jan, hope you'll get better results with this board, I think I'm gonna change the sensor for another that is not using 1-Wire, or simply use analog sensor.

Kind regards

posted by elisa scheer 12 Apr 2019