This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BOOSTXL-EDUMKII: MSP432P401R Accelerometer issue

Part Number: BOOSTXL-EDUMKII

For reference, I have been trying the demo "boostxl_edumkii_accelerometer_msp432p401r"

With this demo, the LCD orientation is supposed to change based on tilting or movie the boosterpack but in the attached picture no matter how i move it it lcd orientation stays the same and the x y z values stay close to the same values

  • Hi Kristofer,

    You can find the voltage values for different orientations on page 12 in the KXTC9-2050 accelerometer's datasheet. Based on the data displayed in the LCD, this orientation may be Position 4. I'm not sure why the ADC values are smaller than they should be.

    The ADC results are 14-bit numbers, so 2^14-1 equals 16383 for the max ADC value (basically equal to the reference voltage). If I take the result for the Y-position (3223) and divide that by 16383, I get ~0.2 of the max ADC value. According to the comments in the code example, the 2.5V reference is used. So, 20% of 2.5V is ~0.49V. As you can see on page 12, the output voltages should be higher than that.

    I thought maybe a lower supply voltage was used on the BoosterPack which (I'm assuming) would lower the output voltages, but according to the schematic, the accelerometer is supplied by 3.3V. That shouldn't be an issue unless it's not getting the correct supply voltage. You could measure that to make sure.

    Are there any sources of electro-magnetic interference around you? Does it change when you're outside/different room/other location?

    Regards,

    James

  • Hi James, thank you for your reply. Unfortunately I am not near a multimeter to confirm the voltage supplied to the boosterpack. Though there aren't sources of emi near me, I took my board into another area and I didn't notice a change in the values. From the x y z values there should be a significant enough change them when the orientation of the boosterpack is changed, right? No matter if I lay it flat, tilt left or right, up or down, those values aren't changing any. 

  • Also, in the possibility of it being a voltage issue, would it specifically affect the accelerometer or would it impact the entire boosterpack?

  • Kristofer Bailey said:
    Unfortunately I am not near a multimeter to confirm the voltage supplied to the boosterpack. Also, in the possibility of it being a voltage issue, would it specifically affect the accelerometer or would it impact the entire boosterpack?

    A multimeter would help to confirm the supply voltage levels. The BoosterPack gets powered from the LaunchPad. While it's not very clear from the datasheet how the accelerometer's output voltage changes based on different supply voltages, it seems to be a logical assumption that they do. The values you are seeing show two channels higher than the other one which is similar to Position 4 but at lower values overall than the example values in the datasheet. Also, some BoosterPacks may not be compatible with certain LaunchPads. That could prevent the BoosterPack from powering up correctly, but that's not the case here since these are compatible with each other.

    Kristofer Bailey said:
    Though there aren't sources of emi near me, I took my board into another area and I didn't notice a change in the values.

    That's good to hear.

    Kristofer Bailey said:
    From the x y z values there should be a significant enough change them when the orientation of the boosterpack is changed, right? No matter if I lay it flat, tilt left or right, up or down, those values aren't changing any.

    The values should change based on the orientation. Are you in an active debug session in CCS when you see this behavior or is the code just running normally? Have you made any changes to the original example code?

    Unfortunately, I don't have one of these BoosterPacks, so I can't test it on my side. Perhaps you can debug the code to see if the ADC values are getting read. You could also confirm which Mode (00 or 01) the accelerometer is in and verify that the Enable is configured correctly. I hope the device hasn't been damaged from ESD, etc.

    Regards,

    James

  • I have not made any changes to the example code from resource explorer. I have ran the code normally and in debug mode. I can see the MEM registers being populated with values, they do change constantly by about plus or minus 10 but are stuck in that range, there isn't any significant change when moving the boosterpack. To check the mode of the accelerometer, is that just checking the SEL registers for the x y z pins? If this issue is unable to be resolved, is there a way to get it repaired or replaced?

    Thanks

  • Hi Kristofer,

    Thanks for the additional details. I finally got one of these BoosterPacks and was able to test it out. From what I observed, the x- and z-axis data ranged from ~4500 to ~11500. The x-axis data is different surprisingly with a range from ~500 to ~1000. The ranges indicate the min and max points for each axis as rotated.

    Kristofer Bailey said:
    To check the mode of the accelerometer, is that just checking the SEL registers for the x y z pins?

    There should be an Enable pin connected to a GPIO on the MSP432 that enables the accelerometer. Refer to the BoosterPack's schematic to see which pin is used. Then, you can check the PxDIR/PxOUT settings for that pin. It should be enabled because it's outputting data but good to confirm. The x, y, z pins are connected to the ADC inputs to capture the data, not enable the device.

    Kristofer Bailey said:
    If this issue is unable to be resolved, is there a way to get it repaired or replaced?

    You could always replace the accelerometer. If this device has been used and wasn't purchased recently, then I doubt there's a warranty. You could also purchase another BoosterPack.

    Overall, you may want to reach out to Kionix and get their input on what you're seeing since it's not a device we manufacturer. At this point, there doesn't seem to be a hardware or software issue, so the behavior may be unique to how the device is used. Hopefully they can provide better guidance on that.

    Regards,

    James