Interfacing to the new HE280 accelerometer...

[mhackney]

I ramped up to 10.5V with the same results.

[dc42]

What connection does the HE280 PCB use as the ground between the accelerometer and the electronics? Do you have a secure wire between that ground connection and the attiny ground?

How is the accelerometer, which I expect uses 3.3V I2C signalling, interfaced to the 5V main electronics?

My guess is that 5V should be enough to get it working.

[mhackney]

David, thank you! As I worked through your questions, I started formulating a response to provide more information:

The HE280BCB has an 8 pin connector, I listed it's pinouts in this thread's first post. Basically, the interface to the PCB has a 12VDC input that is shared by the hot end, fans, and powers everything on board. The accelerometer itself is connected to pins 5 (SCL), 6 (SDA) and 8 (the interrupt signaling an accelerometer trigger) that feed directly to the RAMBo controller's I2C port and an input pin (for the interrupt).

So, where I am to interface now...

I have a naked PCB to test. I use the same 8 pin connector to plug into it as is provided on the printer. I have my power supply - an adjustable convertor - that ...

And right there I discovered the problem. I was not powering the Arduino Micro from the same power supply that I'm powering the PCB. No common ground between the Arduino and Accelerometer as Eric mentioned in a previous post. When I hooked things up on my breadboard yesterday, I first plugged the Arduino into USB so I could verify that my code was running and I was getting output to the serial monitor. I was so I proceeded to plug in the PCB and neglected to also connect the external power to the Arduino. I just did that, and I am now seeing the accelerometer in my I2C scanner code:

Scanning...
I2C device found at address 0x19 !
done

And a couple of comments to address your comments/questions:

Yes, the on board accelerometer does use 3.3V I2C signaling and has on-board pull-up resistors to 5V. The chip is powered by an on board 3.3VDC regulator (there are both 3.3V and 5V regulators on board the PCB).

I'm temporarily using an Arduino Micro since it allows me to interface via I2C AND use USB to output to the serial monitor so I can debug. The ATTinys share the same pins for USB and I2C so you can't use both at the same time.

Now that I can see the device, I have all the code written to configure it and catch the interrupt when it triggers. Hopefully things will progress quickly at this point!

[morgandc]

I bet that felt good! Thank you!

[mhackney]

Yes, an 0x19 never looked so good!

[Eric]

I'm glad you spotted the problem! We might have needed pictures again to spot it from my side.

And if you want another fun sub-project, did you notice there's a temperature sensor on that accelerometer chip? I could see someone with an enclosed printer using it to monitor enclosure temperature.

Yes, the on board accelerometer does use 3.3V I2C signaling and has on-board pull-up resistors to 5V. The chip is powered by an on board 3.3VDC regulator (there are both 3.3V and 5V regulators on board the PCB).

https://github.com/seemecnc/Machine_Ele ... CB_v5d.PDF
Also there are level-shifting mosfets on SDL, SCL, and the interrupt line. The purpose of the 5V regulator is to provide the 5V level for communications. Not used for anything else. So even though it's a 3.3V device, it's set up to use 5V signals safely.

[mhackney]

Another update...

I have my program running and it is configuring the accelerometer using the sam basic configuration code that SeeMeCNC implemented in their Repetier fork. It is pretty straight forward and similar to the other 2 accelerometers I've worked with - configuring sensitivity, axes of interest (Z in this case), enabling an interrupt to let the program know a trigger event occurred, etc. Simple stuff.

I have the HE280's interrupt line (pin 7 on the connector, the blue wire) connected to talk to the Arduino Micro on pin 7 (which can be setup as an interrupt handler in Arduino). And that's where things go odd. I watch the accelerometer configuration for errors and that all succeeds nicely. But, I'm not able to detect the trigger. I've tried reading the pin 7 state directly, I've implemented an interrupt handler configured on interrupt CHANGE, HIGH, LOW, RISING, FALLING. I do reset the accelerometer after it triggers the way SeeMeCNC does in their code.

This accelerometer works almost identically to another that I have working. I've tested all my connections and I've gone through the Repetier code to see if I missed something but so far I'm coming up empty.

[dc42]

Which accelerometer chip does the HE280 use?

[U.S. Water Rockets]

I've done enough with I2C to feel comfortable that I can help you get this working. I'll admit to having way too much experience with I2C, and troubleshooting. I use a barometric sensor from the same family as the senor on your breakout board for my rocket altimeter design, so I have I2C working in the software I wrote. I think I can figure out the issue.

First off, you have a scanning program and I believe you said it finds some devices and not the accelerometer.

I need to know what the devices you can see are, and what the device you cannot see is.

I'm also confused because you said you had some external accelerometer, but then I get the impression you're working using the HE280 board directly. Which board would you like to focus on? Do they have the same accelerometer device?

I also need the name of the scanner program you're using to scan the devices.

I hope to get this going because I'm really interested in seeing more adoption of 32-bit CPUs for deltas, and this hot end probe would be a great motivation for people.

[mhackney]

Hey David, I sent you all that in an email last week, did you get it? If not, I can resend. I have 2 email addresses for you and I don't know if they are both active!

The chip is the IIs2DH: http://www.st.com/en/mems-and-sensors/iis2dh.html
It's a basic accelerometer with a temperature sensor too.

Last year, I used an MMA8452Q accelerometer http://www.nxp.com/files/sensors/doc/da ... A8451Q.pdf
and had that working with the ATTiny85 processor. The probe worked but was not reliable enough. In retrospect seeing how hard the HE280 hits to trigger, I was probably way too conservative with my sensitivity settings. I was attempting to probe with about the same force as I used for FSR probing and got too many false triggers. This crisp "poke" that SeeMeCNC does would likely eliminate that.

But I digress! The goal here is to work with the HE280 accelerometer so I can interface it to a Duet or other standard controller without requiring firmware support for it.

[mhackney]

@ US Water Rockets - the good news is, with the new PCB that SeeMeCNC sent me (got it yesterday) I am now seeing the accelerometer on I2C with no problem - see my post on the previous page. I was excited about that, I think the common ground issue was the root of the problem along with a perhaps not clean 12VDC supply blowing up Arduinos left and right! But that's behind me now.

Let me clarify, last year I started experimenting with an accelerometer probe of my own design. I mention it my previous post here. I got that working fine but the issue was I had too many false triggers so I shelved the project. I now believe that I was not probing with enough Umph to get a good signal without false triggers.

But now, I am trying to interface to the HE280's accelerometer solely so it can be used with other controllers and firmware like my favorite, Duet, without requiring custom firmware changes like SeeMeCNC has done with their Repetier fork. The idea was to use a low cost processor (I'm using an Arduino Micro at this point) as an intermediate to talk with the accelerometer and offer a simple binary on/off interface to the controller - so it looks for all intents like a simple mechanical endstop switch. Exactly for the reason you stated!

So I can see the device. The next step is to configure it though it's registers. SeeMeCNC provided the code for that in their Repetier fork. I'm using it. The last piece of the puzzle is to get the trigger signal, which is an interrupt available on pin 7 of the 8 ping HE280 connector. That's where I'm having problems now. I am at least confident that my initialization code (from SeeMeCNC) is completing successfully as I report all errors and I'm not seeing any problems.

I don't think it's relevant now that I have it working but the scanner is i2c scanner by Nick Gammon http://www.gammon.com.au/forum/?id=10896

[U.S. Water Rockets]

@ US Water Rockets - the good news is, with the new PCB that SeeMeCNC sent me (got it yesterday) I am now seeing the accelerometer on I2C with no problem - see my post on the previous page. I was excited about that, I think the common ground issue was the root of the problem along with a perhaps not clean 12VDC supply blowing up Arduinos left and right! But that's behind me now.

I think I was composing my post when you posted your update, because I could swear I read every message in the thread looking to see I was not asking redundant questions.

Here's what you should do for the interrupt issue. You need to set the interrupt to work on some convenient edge and with the HE280 interrupt out signal wire disconnected, you should be able to trigger the interrupt by injecting your own edge into the interrupt input of the Arduino. If you can get the Arduino to see the manual interrupts you make (I'd just use a jumper wire and touch the interrupt in pin to Vcc or GND to simulate interrupts) then the Arduino code is set up correctly.

If you don't see interrupts when you inject them manually, then your Arduino code is not configured properly, or the interrupt pin is not connected properly. Usually, an interrupt input is configured in what is called a "wired OR" configuration (also known as "Open Collector"), so there should be a pull-up resistor on the interrupt input. You can usually enable an internal pull-up on Atmel CPUs, so I'd check that this is done or there's one on the PCB.

If you do see interrupts when you inject them manually, then you should be looking at the output of the interrupt pin of the HE280 board with a multimeter to see if it is doing anything. Unfortunately, the state of the interrupt pin is under software control, so the config code you run from SeeMeCNC could be setting it to go low or go high on interrupt and I don't know what state you should be looking for.

Come to think of it, if the HE280 relies on a software controlled pull-up resistor on the Rambo, then you must have the same resistor enabled on your interrupt input pin. I looked for HE280 schematics, bit didn't find any. If you have them, you can check. If there's no pull-up on the accelerometer INT pin, then that could be the issue.

[mhackney]

OK, I'm thinking along the same lines then because I have already done exactly the test you describe. I configured the interrupt service routine to trigger LOW. Then I used a jumper to GND and Vcc. Connected to GND, I get a continual stream of interrupt service calls, connected to Vcc I get none. So that tells me the Arduino code is doing the right thing.

When I enable the internal pulp, I don't see the interrupt service get called with any mode (trigger low, high, rising, falling)

I used my little digital oscilloscope connected to the HE280 pin 7 used for the interrupt and attached to PS_ON on the RAMBo. I have looked and searched through the Repetier code and I can't find where that pin is setup to be used by the accelerometer probe so I can't tell if they used pinMode pullup or not.

I PM'd you asking you to email me so I can send you schematics, code, etc. I tried to send to your email on file and it bounced saying your account is over quota. But I have the schematics, data sheet for the accelerometer and my sketch.

[U.S. Water Rockets]

I PM'd you asking you to email me so I can send you schematics, code, etc. I tried to send to your email on file and it bounced saying your account is over quota. But I have the schematics, data sheet for the accelerometer and my sketch.

My inbox should be clear. You should be able to send the files now. Thanks for pointing this out because I would have not noticed until something critical bounced. LOL.

[mhackney]

Yeah, I'm not seeing anything on that connector pin 7 from the HE280. It must be that the accelerometer is either misconfigured or the interrupt is not getting cleared (although I have code to do that).

[U.S. Water Rockets]

Yeah, I'm not seeing anything on that connector pin 7 from the HE280. It must be that the accelerometer is either misconfigured or the interrupt is not getting cleared (although I have code to do that).

I got the files.

It would appear that on the HE280 board, resistor R10 (1K) is pulling the INT pin (7) high with a 1K resistor, and the INT1 signal of the accelerometer is used to turn on FET Q3 to pull the INT signal low when the interrupt fires. This appears to be simply a 3.3V to 5V level shift circuit. The same FETs are used to shift the I2C signals from 3.3V to 5V.

A simple test you can perform to test the circuit would be to insert code to toggle the Accelerometer's H_LACTIVE bit (Bit 1) of CTRL_REG6 (25H) and see if the INT output of the HE280 (Terminal 7) toggles. If I understand the datasheet correctly, the H_LACTIVE bit sets the active polarity of the interrupt outputs. By toggling this bit, we should be forcing the INT1 pin of the accelerometer to change from active low to active high and back again... making it wiggle high and low in the process. This should show up as interrupts in the Arduino.

If this test shows the interrupts working, then you almost certainly have a problem with the initialization code for the accelerometer. The circuit is good, but somehow the accelerometer is not configured to provide interrupts or is not sensing the threshold needed to trigger them.

[mhackney]

Ok, I am toggling CTRL_REG6 H_LACTIVE bit with a 100ms delay. I definitely see the signal changing high and low on my oscilloscope.

So the interrupts are working. The initialization code is literally copy/paste from the Repetier firmware (accelerometer_init() ).

[mhackney]

BTW, SeeMeCNC initialize CTRL_REG6 to 0b00000000, so H_LACTIVE = 0 so the interrupt is active high.

[U.S. Water Rockets]

BTW, SeeMeCNC initialize CTRL_REG6 to 0b00000000, so H_LACTIVE = 0 so the interrupt is active high.

I think the way the FET is configured, the actual signal on terminal 7 is the inverse of the INT1 signal.

[mhackney]

Yes but I should still see the signal on the scope when I tap the accelerometer "smartly". But I don't.

[mhackney]

I'm taking the direct approach and reading pin 7 directly rather than using the interrupt handler. I'm not seeing any change on the pin at all.

[U.S. Water Rockets]

Yes but I should still see the signal on the scope when I tap the accelerometer "smartly". But I don't.

Does the INIT code disable the interrupts, configure them, then enable them? Sometimes this causes spurious interrupts to be triggered.

I prefer to do all interrupt configuration with the interrupts disabled, then for good measure I clear the interrupt bit just before enabling them. If this is not possible, then I clear the interrupt bit just before the main loop. If there's a pending interrupt when you enable them, it often does not trigger an interrupt, so the pending bit will block new ones from happening.

[U.S. Water Rockets]

I'm taking the direct approach and reading pin 7 directly rather than using the interrupt handler. I'm not seeing any change on the pin at all.

I'm going out on a limb and suggest that there's code after the INIT code that does something to the registers in the accelerometer and it's not obvious to you there's more code in there somewhere.

[mhackney]

No. you can take a look at the source I sent you. The init simply ploughs through the set of registers and sets them. It doesn't clear spurious interrupts at the end. In repetier the clearing (enabling the interrupt) is done when it's time to probe. Since I'm testing I do it in my main loop.

[mhackney]

I think you might be right. I've searched and perused Repetier and nothing jumps out. But I will try your suggestion to enable at the end of init.