cancel
Showing results for 
Search instead for 
Did you mean: 

MAX31850K (1-Wire) on STM32G030 issue

SBurg.3
Associate II

Hi guys,

I am struggling for a few days with the MAX31850K (Cold-Junction Compensated, 1-Wire Thermocouple-to-Digital Converters) so I was hoping that some of you might have experienced the same issue.

The chip is soldered on my custom PCB (I am not using a development board/kit) and it is controlled by STM32G030 MCU.

The current results are following:

- Readout of device 64-bit serial number works fine and as expected (it starts with 0x3B.... and this byte exactly tells the device type)

- Every data that I am getting from the device is always correct as I always check the CRC

- The hardware address which is the part of the configuration register within the scratchpad is also ok and the value as expected

The issue is the following: The temperature that I am getting back is always zero, but not only that, there is no error bit set (please check the datasheet page 13, table 2). So, even though I disconnect the probe, at least I shall have the open-circuit bit set, but this never happens. So, the temperature data (first 4 bytes of the scratchpad) are always 0, but the rest of the data is always correct and the CRC is also correct.

So, when you have a second look, you shall see that what I am actually reading out (each time that I request a temperature conversion and read scratchpad) is the default (reset value) of the scratchpad.

Considering the text above, I concluded that the communication with the chip is definitely working ok, so I do not suspect any issues in the 1-wire library, especially because I am using it for years with DS18B20 with no issues at all. I also concluded that initialization, MATCH ROM and SEARCH ROM commands are also working flawlessly and that all data that I receive has a valid CRC so I am really receiving what the device has sent me.

Why in temperature data of the scratchpad there are no error flags set whenever you deliberately create one, I do not know. On the other hand, why always reading all zeroes is also very strange.

Additionally, I have 3 types of K probes, they all work when connected to a multimeter, but nevertheless, even without a probe, the chip is misbehaving.

I tries to google for solution, but unfortunately didn't find anything to help.

I am open for suggestions and ideas. Any idea, how much crazy may sound, could actually help.

P.S.I forgot to mention that MAX31850 is working in external power mode. It is not in parasite power mode.

Cheers!

1 ACCEPTED SOLUTION

Accepted Solutions

Thanks for showing the code.

I noticed a diff between the match ROM operation in ow_convert_temp() and max31850_read_temp().

For ow_convert_temp() you don't send the 64-bit ROM code after the MATCH_ROM command. So are you sure that the MAX31850 is actually converting anything ?

Also from the datasheet p.22 table 6 it seems that Maxim is resetting the device just before reading the scratchpad,is it something you do too ?

Best regards.

View solution in original post

6 REPLIES 6
Kraal
Senior III

Hi,

Please provide some source code.

The scratchpad has the value 0 upon power-on. How do you start the conversion ?

Best regards.

Hi,

Here are some code snippets.

So, as we said, the initialization and "enumeration" request works and this part I will not paste here. After that I am doing the following:

void max31850_update( void )
{
    bool_t  bret;
    uint8_t i;
 
    ow_reset_search_state( &max31850_hdl.ow_hdl );
 
    bret                   = ow_reset( &max31850_hdl.ow_hdl );
    max31850_hdl.no_of_dev = ow_list_all_devices( &max31850_hdl.ow_hdl );
 
    if (( FALSE != bret ) && ( 0 != max31850_hdl.no_of_dev ))
    {
        bret = ow_convert_temp( &max31850_hdl.ow_hdl );
    }
 
    /*FIXME: Remove this wait, debug only */
    bsp_wait ( 1, BSP_TIME_SEC );
 
    if ( FALSE != bret )
    {
        for ( i = 0; i < max31850_hdl.no_of_dev; i++ )
        {
            max31850_hdl.last_temperature[i] = max31850_read_temp( i );
        }
    }
 
    for ( i = max31850_hdl.no_of_dev; i < OW_MAX_DEVICES; i++ )
    {
        max31850_hdl.last_temperature[i] = MAX31850_SENSOR_ERROR;
    }
}

This function max31850_update() is called each 1s from the main loop. The important functions which are called inside are as follows:

bool_t ow_convert_temp( One_Wire_Hdl_t ow )
{
    bool_t  ret = FALSE;
 
    ret = ow_reset( ow );
 
    if ( FALSE != ret )
    {
        ow_write_byte( ow, OW_CMD_MATCH_ROM );
        ow_write_byte( ow, OW_CMD_CONVERT_TEMP );
    }
 
    return ret;
}

and

static int16_t max31850_read_temp( uint8_t dev_idx )
{
    int16_t temperature = MAX31850_SENSOR_ERROR;
    uint8_t i;
    uint8_t crc = 0;
    uint8_t data[MAX31850_DATA_LEN] = {0};
    bool_t  bret;
 
    bret = ow_match_rom( &max31850_hdl.ow_hdl, dev_idx );
    ow_write_byte( &max31850_hdl.ow_hdl, OW_CMD_READ_SCHRATCHPAD );
 
    for ( i = 0; i < MAX31850_DATA_LEN; i++ )
    {
        data[i] = ow_read_byte( &max31850_hdl.ow_hdl );
    }
 
    crc = ow_crc8( data, 8 );
 
    if ( crc == data[8] )
    {
        temperature = data[0] | ( data[1] << 8 );
    }
 
    return temperature;
}

Additional info:

/* 1-Wire basic commands */
#define OW_CMD_SEARCH_ROM       (0xF0)   /* Multiple devices on the bus */
#define OW_CMD_READ_ROM         (0x33)   /* Single device on the bus    */
#define OW_CMD_SKIP_ROM         (0xCC)
#define OW_CMD_MATCH_ROM        (0x55)
#define OW_CMD_CONVERT_TEMP     (0x44)
#define OW_CMD_READ_SCHRATCHPAD (0xBE)

Thx!

Uwe Bonnes
Principal III

Can you exclude faked chips?

Well, I've ordered them from Mouser, but besides that I don't think so...

Thanks for showing the code.

I noticed a diff between the match ROM operation in ow_convert_temp() and max31850_read_temp().

For ow_convert_temp() you don't send the 64-bit ROM code after the MATCH_ROM command. So are you sure that the MAX31850 is actually converting anything ?

Also from the datasheet p.22 table 6 it seems that Maxim is resetting the device just before reading the scratchpad,is it something you do too ?

Best regards.

Hi Kraal,

yes, this was exactly what caused my issue. I was doing it wrong. I’ve exchanged that part now and furthermore replaced the 1 second wait with a new function which checks if the conversion is complete and now it works flawlessly. On the other hand, I have to see why my original DS18B20 code is working for years now. Maybe this part is different between the chips. I will have to cross-check the datasheets more carefully.

Thank you very much for your help! 🙂

Cheers!