-
-
Notifications
You must be signed in to change notification settings - Fork 16
Nano 33 BLE Sense - Wire1 not fully initializing the hardware (Pull up and enable devices) #51
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
Comments
Quick update: the Arduino_HS300x.h sketch for temperature and Humidity appears to be working now, So thought I would try: /* LPS22HB - Read Pressure Imperial Which uses the library: Arduino_LPS22HB This sketch works on MBED version, but hangs on Zephyr in the call:
Would suggest that the loop have some form of timeout. But that is beyond this issue. Wondering about if is issue about not being able to set strong drive on the enable pin, like was used on MBED or if maybe some communication speed issue. Will try to investigate a bit more tomorrow. |
Quick update on the Read Pressure example mentioned above. It again is an issue with the Sensor enable pin not being turned on... With the current build, with all of the merges, I was able to get the pressure and temp returned by adding:
In Setup of the sketch Need to figure out who should be doing this. There is some stuff in the device tree that looks like someone is supposed to do it.
@facchinm - not sure is there some optional mechanism to load this at startup. I do see in the same directory kconfig.defconfig:
Which may be a hint? |
@KurtE Looking at the .cpp file I noticed this for Mbed:
looks like it trying to make it thread safe??? Just guessing here. EDIT: Out of curiosity I tried the sparkfun BMI270 library using wire1 and guess what - that seemed to work:
of course i had to add in
and tell it to use wire1 instead of wire. |
As a experiment I tried the reefwing and another lps22 lib that failed the same way. However, I downloaded the Adafruint LPS2x library and that seemed to work.
So question is do we spend time on fixing the libs at this point or hold off for a bit - later is my preference at this point |
Yep - I played with maybe trying to define: CONFIG_SENSOR
So my reading of this is, there is some partial definitions for at least one of the sensors, defined probably within zephyr (LSM9DS1), Comes back to the earlier question: What is Arduinos goals for this? |
For drivers that have an implementation based on Arduino APIs (like the LSM9DS1) the goal is to use our library. Differently, libraries based on HW functionality (like H7_Video / PDM) are going to be reimplemented as wrappers over the zephyr drivers |
Eventually patching the libraries if they contain mbed-isms, of course 🙂 |
Just for the record I did manage to get the LPS22HB library by commenting out oneshot and putting it into continuous mode. Probably needs a setdata rate function - issue may be using an interrupt in threads. ie.
|
I have been playing more with this. Assuming PR ever gets pulled in to MBED. go round and round with getting the PR comments in a form they will accept... In the overlay file I added:
Actually, just the pin-enable-gpios line then in our main.cpp, I added code to find that pin and initialize it. Currently like:
This is based on an issue/discussion up on the zephyr github project: It appears like the pin is initialized but not sure about the drive part yet. I am pretty sure it should be calling through the gpio_nrfx.c file
Will experiment more tomorrow. But let me know what you think... |
Resolves: arduino#51 There is an IO pin on the NANO that that when turned on, enables most of the sensors on the BLE sense which are on SPI1. The MBED version, enables this pin as part of the main(). Which I am trying to emulate. There is code already in, that if you use at least one of the zephyr device drivers, will eanble this pin. However that does not help when you are using external libraries or the like. So I added details about this pin in our overlay file, in the zephyr,user section. I then added code to main.cpp, that is only included if your are building using an NRFX board. Currently the nano and one of the nicla boards. Could also specically only do this on the NANO, but probably does not matter as, the code tries to find that property and only if it is found, does it turn on the pin. Note: The MBED version turn on this pin with high drive. Which I emulated using the information, mentioned in the zephyr discussion. zephyrproject-rtos/zephyr#78710 In one of my sketches I verified that the pin pads configuration looks the same as mbed setup. With these changes I am able to access most of the sensors. Most of the testing has been done by @mjs513, with some by myself as well.
this morning did manage to get the BMI270, BMM150 and LPS22HB all working at the same time. Since the ArduinoBMI270_BMI150 is not compatibile and no matter what how I hacked at it couldn't get it working. @facchinm = should I write the issue up in that library? For the BMM150 I used a hacked up version of the DFrobot BMI150 library. Even with that I ran into several issues where the nano would just loose the Serial port:
For the BMI270 used the Sparkfun library with no changes. For the LPS22 used the Arduino version but had to add So in the end did manage to get data from all 3 sensors so would say @KurtE's changes work to enable the sensors. NOTE: If I run the sketches individually I have no problem with loosing serial port include the BMM150 sketch where I could use it unmodified. |
Describe the bug
The sensors on this board, require an IO pin to be set high to enable the Pull up resistors on the Wire1 SCL/SDA pins, in addition, some if not
all of the sensors require another pin to be set high in order to enable those sensors.
With the MBED code base the initVariant does this with the code:
In the zephyr setup, I know some of this is being handled:
In the file: zephyr\boards\nano_33_ble\arduino_nano_33_ble-common.dtsi, it has:
Where: <&gpio0 22 GPIO_ACTIVE_HIGH> is the same as mbed PIN_ENABLE_SENSORS_3V3 and
<&gpio1 0 GPIO_ACTIVE_HIGH> - is the same as mbed PIN_ENABLE_I2C_PULLUP
I believe that the Pull up resistor IO pin as well as the USER/Power led is initialized in the function board_init,
which is contained in the file board.c which is in the same directory as the .dtsi mentioned above:
However I do not see anywhere that initializes the enable pin.
Note: my pr #50 adds the extra IO pins to the pin table to match MBED including:
To confirm some of this, I modified the ReadSensorsImperial (for temp and ...) to print out the state of the processors IO ports
at startup and was trying some code to see if I can get zephyr into same state:
When I run this on MBED I see:
From the processor manual which I downloaded from:
https://docs-be.nordicsemi.com/bundle/ps_nrf52840/attach/nRF52840_PS_v1.11.pdf?_LANG=enus
Pull up resistor: P1:0 - PIN_CNF[0] = 3
Page 349 - 3 -> DIR=OUTPUT, INPUT=Disconnect bit(0) of OUT is 1 so HIGH
Enable Pin: P0:22 PIN_CNF[22] = 0x771 Not 100% with bits here
but DIR=0x1 or OUTPUT
DRIVE= 0x70 - H0D1 - High drive High drive '0', disconnect '1' (normally used for wired-and connections)
SENSE = 0x700? - only two bits 11 LOW?, but only two bits... I think not connected...
Now if I run it with my Zephyr setup (with PR code mentioned), I see output of:
With this we see: P1:0 is PIN_CNF = 3 which is correct low bit set so HIGH...
However, the Enable pin P0:22 CNF=2 which is default INPUT but INPUT disconnected.
I tried some hacks to set the ENABLE to output, however my hack to try to set the CFG failed so far.
With out the code to set the enable high:
The Sensor would fail to initialize, and we loop forever.
With the code to enable it, it says the sensor was initialized, but then the board crashes. From Serial1 output I see:
So far two questions:
a) Who is supposed to initialize this pin.
b) How in zephyr do you set the CFG - Drive field of the CNF registers? As per the comment in the MBED init code:
// Set high drive pin to properly power the bmi150
Next up try to see where it is actually faulting.
The text was updated successfully, but these errors were encountered: