Hi,
So i have built a custom A-star 328PB 8MHz board with the pololu bootloader.
Everything is working perfectly but I’m having difficulties
getting a motion sensor exmaple .ino code which i believe was built around the Arduino DUE work with the Arduino UNO bootloader which i believe the pololu bootloader was built upon.
The manufacturer said that it should work with the UNO without any issues
but it definitely doesn’t seem to be the case.
I have never used the DUE board before and i’m not sure if the wire.h function for the
i2c are compatible between the DUE and the UNO but when
i run the code on the original pololu A-star m328PB with some logic level converter
to feed the MC34X9 the 3.3v,
the message i get on the serial monitor is
same message.
I have tried the SPI mode and it worked but however not the way i’d expect like the ordinary printings on the serial monitor.
in SPI mode, everything seems to be floating, as if wires are unconnected
or something.
the moment i hit reset, it prints out the reading of the accelerometer
and then the printing doesn’t continue… it’s like halted
until i touch one of the wires and then it prints some other lines
then stops. it’s basically like having a floating wire somewhere…
I’m probably going to have to make some big modification.
I got in touch with the manufacturer again and he gave me
a .c code to figure things out. he also said that the demo code was created in 2020
and wasn’t meant for the Arduino UNO thus any unusual or inaccurate results
should be expected lol yet, when i first contact them, they said that it should work with
the Arduino UNO, without any issues.
It does sound like you might have a loose wire or breadboard rail.
Do you need those external pull-ups on the I2C lines? I would have thought that level shifter board would already have pull-ups on it. Maybe the accelerometer board has them as well. Do you have an oscope or logic analyzer that you can use to look at the 5V I2C signals and the 3.3V ones?
The A-Star in your pictures looks like a 5 V, 16 MHz version (item #3160). Is that what it is and have you modified the hardware or bootloader on it? Have you successfully used it to communicate with any other I2C devices, or have you communicated with the MC34X9 board with any other controller?
I have 2 x 328PB 8mhz A-star boards and 4 x 328PB 16mhz boards
so far i’ve used the two 8mhz boards and i get the same error.
I also have an mpu6050 acc/gyro and proximity sensor vcnl4040 that i use with my boards and they work fine.
Hi Kevin,
I have used my 328PB boards with other i2c devices and they work fine.
right now i have no other controllers except the pololu 328PB
At first i have tried it without the 4.7k pull-up resistors. same problem
I believe the way they’ve implemented the i2c wire.begin
isn’t compatible with the Arduino UNO or it’s deprecated.
I’ll figure it out and do the necessary modifications.
I didn’t see any obvious issues in your wiring, and nothing stood out to me as problematic in the library code either, but let us know if you find something. Otherwise, I agree with Adam’s suggestion to look at things with an oscilloscope so you can figure out more about what’s happening.
Hey Kevin, I think i’ve found the problem…
perhaps you can double look at it and help me out here.
So i have decided to give this motion sensor another shot
and actually looked into the real datasheet, today. datasheet
I paid attention to all the addresses defined in the .h file MC34X9.h
in the demo example.
notice at line 109, there’s #define MC34X9_REG_PROD (0x18)
This is the same register address that in .cpp file MC34X9.cpp
at line 71 is being “i2c read” to check for the motion sensor connectivity.
/* Check I2C connection */
uint8_t id = readRegister8(MC34X9_REG_PROD);
if (id != MC34X9_CHIP_ID)
{
/* No MC34X9 detected ... return false */
mcube_printf("No MC34X9 detected!");
mcube_printf("Chip ID: ");
mcube_printf_number(id);
return false;
}
but guess what ?? in the datasheet, there is no such register that has the address 0x18, It doesn’t exist.
So the error i’m getting should make sense.
I found a newer version of the datasheet on the manufacturer’s site, which says that 0x18 is the “Chip id” register in section 12.1 (page 41), so it’s probably fine for the library to read it.
