Anyone have issues getting a SparkFun VCNL4040 working with an Arduino GIGA R1 Wifi?
I2C scanner correctly finds the sensor address (0x60) on Wire or Wire2 given which it is connected to at the time. (Note that GIGA has a chip that conflicts at 0x60 on Wire1).
Same sensor works great with other Arduino.
When using the begin test:
if (proximitySensor.begin(Wire) == false)
this always reports a fail.
When simply starting:
proximitySensor.begin(Wire);
The Proximity values are always zero, although the Ambient sensor does report values.
Anyone have any ideas??
Thanks!
Wasted another day on this…
Tried connecting the sensor through a MUX board, same result.
used isConnected() and confirmed true
used GetID() and confirmed ID = 390
getProximity() all zeros.
HELP!!!
The i2c address of VCNL4040 is FIXED/hardware defined at 0x60
Connecting through a mux should work in theory, ensure you can communicate with the mux/other i2c sensors properly (main thing is to check which Wire bus you’ve chosen); you’ll also need to set a virtual i2c address for the VCNL
You’ll also want to disable all but one set of i2c pull-up resistors for the given i2c bus (there’s usually a set on a mux and on the proximity sensor, I’d disable the one on the proximity sensor by severing the jumper pad traces on the rear side of the board labeled i2c
)
It working with other boards means it’s something in your config that’s amiss :-/
Thanks Russel,
As posted above, adding the MUX did not solve the issue and Yes, all other i2c are working properly.
Also, as stated, have tried multiple Wire bus’s, all show same performance.
Virtual? I have changed the address of buttons, I thought the address of the sensor was fixed? Same process?
Why disable pull up resistors? It is the only device on the wire (other Qwiics are on a different Wire#)(yes, have tried swapping them around). I currently have the sensor on a 6" lead, but final configuration would like the sensor to be about 2 feet from the GIGA.
Config? - Literally taking the same code that works on the UNO (where it works great), swapping the sensor from the UNO to the GIGA and .begin fails. Please advise what in the config needs to be changed from UNO to GIGA. Note - using the Sparkfun demos to try to get it to work (Proximity, etc.).
Thanks for responding, been beating at this for way too long! TR
Our mux allows you to set addresses somewhat arbitrarily
I said to disable pull-ups if using the mux, as most come with an active set (+ sensor = 2 sets)
Config would consist of wiring, code, devices…the whole gamut. Point being it’s something wrong with how it is being used if it works with another MCU
Is the Gia R1 required?
Just a thought… the VCNL4040 maybe needs more time to deliver the right information.
It does not seem to use clock stretch (normally applied when a sensor needs more time). The GIGA is much faster than other Arduino’s and that could impact.
Maybe try this for debug
In the file : SparkFun_VCNL4040_Arduino_Library.cpp
In the command : readCommand(uint8_t commandCode)
around line 364, before calling _i2cPort->requestFrom((uint8_t)VCNL4040_ADDR, (uint8_t)2);
add : delay(200);
The 200mS delay is just an amount to force a delay.. no cleaver thoughts here. If it works now you can try an lower delay. Who knows….
As alternative you can also try to reduce the Wire-speed
Ahh, of the MUX, yes. I am skeptical that the 0x60 chip on the GIGA might be the interference, even though on different wires. Was hoping there was a way to set the address of the sensor. Tried the MUX, performance the same.
I have broken the config to the basic bare bones in troubleshooting. One UNO with one i2c lead running the Sparkfun Proximity code vs the GIGA with one lead running the Proximity code.
Yes, would really like having this run on the GIGA and not have to use an UNO and communicate one sensor’s output to the GIGA.
Paul, this is interesting…Thinking back to using the sensor on the UNO, I noticed if the code requested Proximity values too quickly, the sensor would freeze.
Wire speed is at minimum (100K).
I will look into this and report back!
Report:
I was so hopeful this would work!! I even bumped it to a full delay of 1000 and .begin still fails.
I assume you can still try to set lower speeds e.g. 25000, but I would try the delay first.
From what I read, 100K is the minimum…?
I don’t have the GIGA R1.. but you can always give a try. The 100K is default. The sensor can handle starting from 10K (according to the datasheet)..
I am a little hesitant to try, when I set the wire to 400K, the USB port failed…
New UPDATE:
Still cannot get .begin to start successfully.
Went back to the simple initialize without test:
proximitySensor.begin(Wire2);
to make sure device would still acknowledge even when testing .begin=false
And it does. Decided to try:
proximitySensor.powerOnProximity();
and even though .begin is still returning false, it appears full functionality is working (only seconds of testing and run time). I assume when .begin is successful, the library activates .powerOnProximity but without it, a manual turn on seems to work.
So I am guessing paulvha is on the right track with this being some kind of communication error in the confirmation at starting.
TS-Russell - are you able to reproduce any of this? Assuming you have access to a GIGA…
I don’t have an R1 either :-/
Altering the speed in code to unworkable/invalid values should be fine, it’ll just not work and then you can adjust from there…you won’t damage anything (to be clear, change the wire/i2c speed not the connection’s baud rate/serial rate…weird that you had usb disconnect)
Yep, paulvha is usually on the right track, ha! 
I just had a look at the GIGA source code. It looks i2C is only supporting 100K, 400K and 1Mhz.
Looking the .begin(). It will only fail if isconnected() or getID() fails else it will return true. Some Serial.println() might tell you which fails…
See waaaay above Paul, both come back good!
isConnected() confirms true
GetID() confirmed ID = 390
I have been beating on this for days.
Time for Sparkfun to buy a GIGA and do some development?? 
I had seen that… BUT still you get a fail on begin().
SO which one of the two is causing that ? try to find out with serial.Println
I suspect a timing issue…
Maybe Wire.begin() needs more time to settle and as such maybe do a delay at start of begin().??
The Isconnected() only does a write of address and then checks it gets an ACK from the sensor. I have seen that approach fail on another processor.(it needed a dummy write). But why when you try it later from the sketch it works. Don’t know ???
Putting delays into the startup is actually one of the first things I tried, will mess around with it more.
I started looking at the CPP more, and found that my hunch was right and the Proximity is turned on after successful .begin. Manually turning it on works, so potentially the only thing failing is the .begin confirmation and everything else is working well enough…?
Given that, maybe the whole issue is getting the .begin test to pass. Otherwise (pending more testing), it appears to be working.
Also, there’s a few .begin tests in the CPP. Maybe more of them need a delay in order to give the chip time to get the ducks in a row to pass the requirements for .begin test? Will try later and report back. Or maybe Sparkfun has enough info here to solve this??
