-
Notifications
You must be signed in to change notification settings - Fork 469
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Device doesn't seems to be working properly. #5
Comments
I have this board also, and it has worked well for me. You need to make sure that both VDD and VDDIO are powered, and that you properly configure the chip select (it must be HIGH for I2C IIRC). There are 10K pullups on the board for I2C; just make sure there are no other pullups in the circuit. What micrcontroller are you using>? If you can read the whoami register then you probably have the hardware set up properly. You have to power up the sensor (set sleep bit in 0x6B to 0) and enable bypass mode( set register 0x37 to 0x22) if you want to read the magnetometer. My code (https://github.com/kriswiner/MPU-9250/blob/master/MPU9250BasicAHRS.ino) on GitHub does all this and should work with this breakout board. Kris From: sverdlovsk I have this board: http://www.embeddedmasters.com/PortalProductDetail.aspx?ProdId=552444#.VHidcTHF-os Any suggestions? Thanks. — |
Thank you for fast reply. Pull ups was the first issue: the device didn't ACK, so they are removed.The schematic for this board is at least confusing and no designation on the board itself. VDD pins on one side connector are joined connected to 3.3V. The GND pin goes to ground and SDA and SCL from other side connector are going to my board. For this exercise I'm using STM32F4DISCOVERY. The reason I've mentioned my ability to read WhoAmI and you've noticed that, that my communication is working...
The first function reads all zeros, the second reads packet_count as 0... What else? Bad device? Thank you. |
I assume you also have VDDIO connected to 3V3. I don’t see in this ported code where you are clearing the sleep bit in the 0x6B register. The device is default asleep and must be turned on. If you just write 0x00 to register 0x6b, you should be able to get non-zero accel data. Try this. Kris From: sverdlovsk Thank you for fast reply. Pull ups was the first issue: the device didn't ACK, so they are removed.The schematic for this board is at least confusing and no designation on the board itself. VDD pins on one side connector are joined connected to 3.3V. The GND pin goes to ground and SDA and SCL from other side connector are going to my board. For this exercise I'm using STM32F4DISCOVERY. The reason I've mentioned my ability to read WhoAmI and you've noticed that, that my communication is working... // Accelerometer and gyroscope self test; check calibration wrt factory settings uint8_t data[6] = {0, 0, 0, 0, 0, 0}, val; // Set gyro sample rate to 1 kHz val = 2; for (int ii = 0; ii < 200; ii++) { // get average current values of gyro and acclerometer // Read the six raw data registers into data array for (int ii = 0; ii < 3; ii++) { // Get average of 200 values on each axis and store as average current readings // Configure the accelerometer for self-test ms_delay(25); // Delay 25ms a while to let the device stabilize for (int ii = 0; ii < 200; ii++) { // get average current values of gyro and acclerometer // Read the six raw data registers into data array for (int ii = 0; ii < 3; ii++) { // Get average of 200 values on each axis and store as average self-test readings // Configure the gyro and accelerometer for normal operation ms_delay(25); // Delay 25ms a while to let the device stabilize // Retrieve accelerometer and gyro factory Self-Test Code from USR_Reg if (!mpu9250_rd_reg(MPU9250_SELF_TEST_X_GYRO, sizeof(val), &val, err)) return false; // Retrieve factory self-test value from self-test code reads // Report results as a ratio of (STR - FT)/FT; the change from Factory Trim of the Self-Test Response // Function which accumulates gyro and accelerometer data after device initialization. It calculates the average uint8_t val, data[12]; // data array to hold accelerometer and gyro x, y, z, data // get stable time source // Configure device for bias calculation // Configure MPU9250 gyro and accelerometer for bias calculation // Configure FIFO to capture accelerometer and gyro data for bias calculation // At end of sample accumulation, turn off FIFO sensor read fifo_count = ((uint16_t)data[0] << 8) | data[1]; // read data for averaging // Construct the gyro biases for push to the hardware gyro bias registers, which are reset to zero upon device startup // Push gyro biases to hardware registers val = data[0]; int32_t accel_bias_reg[3] = {0, 0, 0}; // A place to hold the factory accelerometer trim biases uint32_t mask = 1uL; // Define mask for temperature compensation bit 0 of lower byte of accelerometer bias registers // If temperature compensation bit is set, record that fact in mask_bit // Construct total accelerometer bias, including calculated average accelerometer bias from above data[0] = (accel_bias_reg[0] >> 8) & 0xFF; // Apparently this is not working for the acceleration biases in the MPU-9250 if (!mpu9250_wr_reg(MPU9250_XA_OFFSET_H, sizeof(uint16_t), &data[0], err)) return false; The first function reads all zeros, the second reads packet_count as 0... What else? Bad device? Thank you. — |
''' tmp = ptr[0]; bool read_data (uint8_t *buf, i2c_err_e *err) { mpu9250_rd_reg (MPU9250_ACCEL_XOUT_H, 6, buf, err); bool init_mpu9250 (i2c_err_e *err) { if (!mpu9250_wr_reg(MPU9250_PWR_MGMT_1, sizeof(init1_msg), init1_msg, err)) return false; // get stable time source :Auto selects the best available clock source – PLL if ready, // Configure Gyro and Accelerometer // Set sample rate = gyroscope output rate/(1 + SMPLRT_DIV) // Set gyroscope full scale range // Set accelerometer configuration // Set accelerometer sample rate configuration |
When I have such trouble I return to my trusty bus pirate. Then I can just check that I can read registers and that the values make sense. In this case, I would suggest that you verify the status of the PWR_MGMT_1 (0x6B) register to make sure the device is powered up. This should be the only action required to start getting accel data. In fact, I suggest you write a very simple program that does nothing but clear the sleep bit (write 0x00 to register 0x6B) and read accel data. This has to work if you can read the whoami register. If it doesn’t you might have a bad board but this is very unlikely; embedded masters does very high quality work. Kris From: sverdlovsk ''' tmp = ptr[0]; bool read_data (uint8_t *buf, i2c_err_e *err) { mpu9250_rd_reg (MPU9250_ACCEL_XOUT_H, 6, buf, err); bool init_mpu9250 (i2c_err_e *err) { (1<<MPU9250_PWR_MGMT_1_H_RESET), if (!mpu9250_wr_reg(MPU9250_PWR_MGMT_1, sizeof(init1_msg), init1_msg, err)) return false; // get stable time source :Auto selects the best available clock source – PLL if ready, if (!mpu9250_wr_reg(MPU9250_PWR_MGMT_1, sizeof(init2_msg), init2_msg, err)) return false; // Configure Gyro and Accelerometer // Set sample rate = gyroscope output rate/(1 + SMPLRT_DIV) if (!mpu9250_wr_reg(MPU9250_SMPLRT_DIV, sizeof(init4_msg), init4_msg, err)) return false; // Set gyroscope full scale range // Set accelerometer configuration // Set accelerometer sample rate configuration #if 0 // Configure Interrupts and Bypass Enable writeByte(MPU9250_ADDRESS, INT_ENABLE, 0x01); // Enable data ready (bit 0) interrupt return true; — |
This should be sufficient to read accelerometer? val = 0x80; |
I don’t know exactly what your code is doing but if writing 0x00 to PWR_MGMT_1 doesn’t allow accel reads then try another board. From: sverdlovsk This should be sufficient to read accelerometer? val = 0x80; if (!mpu9250_wr_reg(MPU9250_PWR_MGMT_1, sizeof(val), &val, err)) return false; if (!mpu9250_wr_reg(MPU9250_PWR_MGMT_1, sizeof(val), &val, err)) return false; — |
Well, obviously I don't have another piece of hw ready...Here is another clue: it doesn't matter what I'm writing to MPU9250_PWR_MGMT_1 I'm always reading back 1. Also the same behavior is with ACCEL_CONFIG register and GYRO_CONFIG - the data I'm reading back are always 0! May by chip is 👎? |
Sounds like your I2C write is not working properly. If you write 0x00 in PWR_MGMT_1 and you read back 0x40 or anything other than 0x00 either your write doesn’t work or the board/chip is ‘bad’. I think the probability is quite high it is the former. Can you talk to and get data from any other I2C sensor with your hardware? Kris From: sverdlovsk Well, obviously I don't have another piece of hw ready...Here is another clue: it doesn't matter what I'm writing to MPU9250_PWR_MGMT_1 I'm always reading back 1. Also the same behavior is with ACCEL_CONFIG register and GYRO_CONFIG - the data I'm reading back are always 0! May by chip is ? — |
I2C is fine. I'm talking with many other sensors and have a scope as an alternative judge! BTW otherwise how would I got ACKs all the way? |
OK, if I2C is fine why can’t you write to the MPU9250? If you write 0x00 to register 0x6B and you then read 0x00 in register 0x6B are you still getting accel data 0x00 or unchanging? I am having trouble understanding this problem because with my EMSENSR MPU9250 and the thirty other MPU9250 boards I have built if I can read the WHOAMI register and write 0x00 to register 0x6B then I can read the accel/gyro data without doing anything else. So I am a bit perplexed by your trouble and don’t know what else to suggest. Sorry I can’t be of more help. Kris From: sverdlovsk I2C is fine. I'm talking with many other sensors and have a scope as an alternative judge! BTW otherwise how would I got ACKs all the way? — |
If I knew the answer...My bet is that chip itself is not functioning properly. Whatever I'm writing to 0x6B I'm reading not 0 but 1 all the time and you're correct accel data are not 0 but do not change like one time read or something... |
Hello |
Yes, I was getting about that with Madgwick on the STM32F401 Nucleo board. See: https://github.com/kriswiner/MPU-6050/wiki/Affordable-9-DoF-Sensor-Fusion |
interesting :) |
I think you can just compile the code that runs on mbed in the usual way. You might have to make a few adjustments for your Olimex board, but hooking up the sensor to I2C, running the code, and getting serial output are pretty standard. |
Seems that I've solved the issue. My I2C wr/rd do NOT have stop condition - I don't want to release the bus. I just added stop in my wr/rd functions and data are changing now... |
Great! It's always the little things. But how were you able to read other sensors using the same I2C read/write routines??? |
I'm not sure what I am looking at. Are you able to verify that the register contents you write can be read back? |
I'm writing to ACCEL_CFG(0x1C) - 8 and immediately reading the same register back - no change :-( |
Why I can't write to this( and probably any other) register?
|
I just want to make sure; you CAN read the WHOAMI register, right? But you CAN'T write to any register? This is very strange... I am assuming that this function: has been tested and shown to work in other applications. Can you scan for I2C addresses and verify that you can detect the MPU9250. This sounds like a basic I2C address error problem. |
Yes, I'm reading WhoAmI with no trouble. |
Well, at this point I'm finally able to write to the registers. This device does NOT support repeated start condition in write mode &^%$#@! I don't understand why didn't they describe all noncompliance with I2C standard?! Still accelerometer data don't make sense. Will continue this fight tomorrow |
If finally works... |
So was the problem in the end the repeated start not being supported by the MPU9250 ASIC? I don't use this feature of I2C so have never had this problem. |
|
I hope your experience with the LSM9DS1 is more satisfying. Please let me know what I can do to help! |
No matter what I'm really appreciate your help. Hope my pain will save somebody else from suffering with bad documentation. My "noise" test is calculating sqrt(ax_ax + ay_ay + az*az) and see how is this value changing when I'm playing with the accelerometer. Doesn't look very good. Will try to tune configuration. Do you have code for converting temperature from raw hex to C? It is noisy but I can't estimate the value yet. |
You might want to 'play' with the bandwidth and ODR to reduce some of the noise on the accel. I usually use 200 Hz ODR and 41 Hz bandwidth. For the MPU9250 gyro temperature: tempCount = readTempData(); // Read the adc values |
Thanks again. |
I think what you need can be found here, no? |
Are you sue it is the device and not the microcontroller that is causing these troubles? |
Kris, that is exactly why I put this screenshot! Master is clocking, device has to ACK, but it isn't... |
What's different from yesterday when all seemed to be working. Maybe you DO have a bum MPU9250! |
OK,
In the init function compiling condition should be changed... |
Looks like you are only waiting 10 ms for the PLL to get established in this init function, maybe 100 would be better. |
Well, and even if you're correct then why this POS stops ACKing? |
I have this board: http://www.embeddedmasters.com/PortalProductDetail.aspx?ProdId=552444#.VHidcTHF-os
So far I have made attempts to initialize based on my personal understanding of the datasheet. As the result I'm successfully reading WhoAmI register and accelerometr output registers. The issue that AX, AY an AZ do not change at all except after reset...Reading configuration registers back doesn't make sense - all 0.
The second attempt was to use other initialization routines found on the web. Basically the same result.
The third was porting this code. No luck.
Any suggestions?
Thanks.
The text was updated successfully, but these errors were encountered: