TMAG5170: Active Trigger mode conversion times

Jonathan,

Thanks for reaching out.  Could you provide some details about the duration of the pulse you are using to trigger on ALERT?  I assume you are measuring Falling edge to Falling edge? Is this being measured using an oscilloscope?

Thanks,

Scott

Hi,

The pulse width on the trigger is about 10us. The timings are measured off a logic analyser. I can share a trace tomorrow if it helps.

Jonathan

Screenshot of the logic analyser trace from a single axis 32x oversampling conversion. In this case the alert signal goes low for 9.5us to start the conversion.

To add a bit more info that may help. I used your example C driver as a basis for this project and have ported it to another vendors micro. To initialise things I am calling:

enterConfigurationMode();
enableMagChannels(MAG_CH_EN_BITS_X);
setSampleRate(CONV_AVG_BITS_32X);
setRanges(0x1,0x1,0x1);
alertTriggersConversion();
enterActiveTriggerMode();

Hope this clarifies things.

Jonathan

Jonathan,

Thank you for these details.  Best I can tell, you haven't configured ALERT to signal conversion completion.  This is done using the function alertIndicatesConversionEnable().  I'm not entirely sure where that second ALERT pulse is coming from.  Is it possible you are sending a second trigger?

To be sure you have all the register settings you intend, could you read back registers 0x00 through 0x03?

If by chance you are not actually getting out of CONFIG mode, the higher speed clock is not yet active and so the device does take longer prior to initiating conversions.

Thanks,

Scott

Hi Scott,

Thanks. The hint about not getting out of config mode pointed me in the right direction. enterActiveTriggerMode() wasn't applying its changes due to an issue in your example C library I think. There is protection in most of the configuration functions (e.g. enterActiveMeasureMode())  to prevent them from operating if the DATA_TYPE field in the SYSTEM_CONFIG register is set to any of the 12bit data types. This test in these functions looks like this:

    // To prevent undefined behavior, this function does not perform its operation
    // when the DATA_TYPE field (address: 0x028-6) is not set to Normal Read Mode (000b)
    if ( DATA_TYPE_RESULTS != DATA_TYPE_RESULTS_NormalMode ) return;

DATA_TYPE_RESULTS is set by a macro which I think is incorrectly inverting the DATA_TYPEmask:

#define SYSTEM_CONFIG_DATA_TYPE_MASK                                    ((uint16_t) 0x01C0)
#define DATA_TYPE_RESULTS    ((SYSTEM_CONFIG_stored & ~(SYSTEM_CONFIG_DATA_TYPE_MASK)) >> 6)

This helpfully sets DATA_TYPE_RESULTS to anything in the top 7 bits of the system config register which includes the TRIGGER_MODE field rather than doing what I assume you wanted which was to extract the Datatype field. I presume the intent was actually:

#define DATA_TYPE_RESULTS    ((SYSTEM_CONFIG_stored & SYSTEM_CONFIG_DATA_TYPE_MASK) >> 6)

This bug meant that after calling alertTriggersConversion(), enterActiveTriggerMode() wasn't actually doing anything useful. After applying the fix I now have:

enableMagChannels(MAG_CH_EN_BITS_X);
setSampleRate(CONV_AVG_BITS_16X);
setRanges(0x1,0x1,0x1);
alertTriggersConversion();
alertIndicatesConversionEnable();
enterActiveTriggerMode();

After this the key registers are:

Device Config (0x0): 0x4030
Sensor Config (0x1): 0x55
System Config (0x2): 0x400
Alert Config (0x3): 0x100
Sys status (0xE): 0x300

Which I think are correct. This has improved the performance considerably vs my original table, but there is still a discrepancy vs the datasheet:

Thoughts?

Thanks for your assistance

Jonathan

Hi Scott,

Changing T_RATE to 1 has brought all the timings to within about 12-13us so I think we are there. I may have missed it in the datasheet, but I assumed that the temperature conversion was only happening if T_CH_EN was set in device config.

Thanks

Jonathan