FXLS8471 Reset Interrupt

[MyDirtIsRed]

Hello helpful forum dwellers and SEO bots,

Our embedded system uses the FXLS8471 and I am trying to write code to initialize the chip (as well as others).  There's this statement in the datasheet, section 10.2.4:

"FXLS8471Q will indicate completion of the reset sequence by toggling the INT1 pin from logic high to low to high over a 500 ns period. If the INT1 pin was already low prior to the reset event, it will only go high, and not toggle."

In my code, I drive the reset line high, and then my assumption was that I would see the signal toggle on INT1, but I never see this behavior.  Unfortunately, I can't seem to find enough information in the datasheet to confirm whether or not reset needs to be pulsed and for what duration.  Does anyone out there know the proper amount of time to hold the chip in reset, and does anyone else rely on the INT1 toggling behavior?

Slainte,

Jake

[MyDirtIsRed]

Hello Tomas,

Sorry for taking so long to reply, I had another project that had grabbed my attention between then and now.  Your steps indeed worked like a charm, thank you very much.

I'm now running into something strange.  In this embedded system, there's an initialization routine where I do a write of the various configuration registers.  Among them are CTRL_REG2, CTRL_REG3, and CTRL_REG5.  The idea was that these registers will really never change.  Let's call this routine the 'initialization function'.  The other registers that require configuration, CTRL_REG1 and CTRL_REG4, are saved for a later function, as depending on mode, we may want to put the chip in standby or change the interrupt behavior.  Let's call this routine the 'enable function'.  If I call the enable function immediately after calling the initialization function, the chip behaves as I expect, i.e. I see the interrupts fire when I move my PCB.  However, if I call the initialization function, go off and do other things, and then call the enable function some number of seconds later, the chip doesn't seem to respond.  Unfortunately, the designers of this system did not give me a lot to work with as far as a debug interface, so I can't exactly tell what's happening, other than the interrupts are definitely not firing, even though I can tell with what little debug info I have (i.e., a system backlight and a scope on the chip select line), that the functions are indeed being called.  Note that the only functions that I'm turning on currently are free-fall and portrait/landscape, and the device is sitting idle during the configuration, so I don't think there's an unprocessed interrupt internal to the chip (although maybe that's a cheap thing to do whenever calling the 'enable' function, i.e. clear any status registers?).

Does any friendly internet denizen have any ideas here what could be happening?

Slainte,

Jake

[MyDirtIsRed]

Hello,

Ok, quick update:  I indeed do a read to clear the various status registers when calling the aforementioned 'enable function', and that seems to do the trick.

Thanks again,

Jake

[TomasVaverka · Accepted solution]

Hello Jake,

Unfortunately it seems a detailed timing diagram for the reset sequence does not exist.

I would recommend using the following sequence:

• Set up interrupt on rising edge trigger from INT1
• Drive RST Low
• Wait 2ms
• Drive RST High
• Wait 2ms
• Drive RST Low
• On interrupt trigger - part reset is complete
• Continue with initialization via SPI or I2C depending on the connection of the SA0 pin (SA0 = floating the part is in SPI mode, if SA0 = GND or VDDIO the part is in I2C mode).

Best regards,

Tomas