I am using the LIS331HH and the FRDM-K22F board.

I can write to the power register and turn on the LIS331HH, I can also write to the interrupt control register (23h) and read out the value I've written.

For some reason though I cannot read from the INT1_CFG (30) register, INT1_SOURCE(31) register or any of the other interrupt related registers.

It seems though that I can write a value to them.

The STATUS_REG (0x27) also always returns 0.

I wondered if anyone has come accross this issue with this device? How would I go about verifiying the device isn't broken at a hardware level?

I'm not sure if I should post code here, but I need to, please let me know.


How would I go about verifiying the device isn't broken at a hardware level?

You are never able to completely remove the possibility that a device has a hardware fault, no matter how much testing you do (e.g. consider intermittent or subtle faults).

However in the type of situation you describe, you could:

  1. Check that your sensor's power supply voltages, decoupling capacitors, and PCB layout match the requirements explained on its datasheet (especially if you are not using a proven, commercial breakout board for the sensor).

  2. Use an oscilloscope to view the interface signal levels, waveform shape etc. and confirm that there are no problems there. Then...

  3. Use an oscilloscope (or, at this stage, a logic analyser or the protocol decoding functionality built into some oscilloscopes would be better) to capture the command sequences (on whichever interface you are using for that sensor, I2C or SPI) which are sent by your current FRDM-K22F code.

  4. Compare the command sequences sent by your current program, to those shown in the sensor's datasheet. This comparison might require expert assistance, as it may be difficult for you to confirm that your program is definitely sending the correct commands.

  5. Also compare the different command sequences which you mentioned to each other, since you report that accesses to some registers seem to behave as expected, yet others don't.


  1. As above, first check the power, decoupling, PCB layout etc.

  2. As above, use an oscilloscope to confirm that there are no problems with the interface signal waveforms.

  3. Temporarily connect your sensor to a known-working Arduino.

  4. Use one of the existing Arduino libraries for that sensor (e.g. this one from SparkFun which uses the SPI interface) in order to get confidence in your sensor hardware itself.

  5. Assuming your sensor does work with that Arduino code, then use an oscilloscope or logic analyser as mentioned above, to capture the command sequences when using the "working" Arduino and its library.

  6. Compare the "working" Arduino-initiated command sequences, with those which don't "work" in the current FRDM-K22F code, find the differences, and then use standard debugging approaches to fix that code.

Or, if you don't have an oscilloscope or logic analyser, so you cannot collect the actual command sequences being sent on the sensor's interface:

  1. Visually review the command sequences, especially at initialisation, used by other people's existing code (e.g. in that Arduino library which I mentioned).

  2. Compare those sequences to the ones used in the current FRDM-K22F code.

  3. Concentrate your investigation on differences found between those two sets.

    Of course this can only help find problems which are visible in the code, and it assumes that the code written by other people is correct. This is a relatively weak troubleshooting approach compared to looking at what is really happening on the interface, as described in the earlier suggestions in the list.

That's not an exhaustive list of possible troubleshooting approaches, but hopefully they should give some ideas about what could be done in this situation.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.