Hi, Is there a working API example to use over SPI?

[omer-arad]

Or any code samples we can use? We are tying to integrate this sensor but having difficulties.

Thanks!

[RudyFiero]

Have you looked the documentation at https://invensense.tdk.com/products/dk-ch101/ https://invensense.tdk.com/ultrasonic-presence-detection/

I had looked at these sensors more than a year ago. They couldn't do what I wanted so I abandoned the project. I was using their kit. From what I remember, this was a real pain in the ass part to use.

[omer-arad]

Yes, it has no examples or documentation on how to relay the sensor readings via any communication method. I'm looking for a working example I can take a deeper look at.

[sriccardi-invn]

Hi, TDK published official Arduino Driver for Chirp ultrasound Sensor. This is available natively in Arduino IDE in library manager. Regards, Seb

[NaveenKoyyada]

Hi, Iam also working on ch101 for nRF chip, I hardly ported the code and tested but some I2C call is getting failed (error: -5). I tested with esp32 using arduino library, it is also not worked.

Anyone tried with Arduino library, will it work?

[sriccardi-invn]

HI, My name is Sebastien Riccardi, I am Senior director at TDK and my team provided Chirp Sensor Arduino driver. CH101 sensor support only I2C. New ICU family support only SPI. Could you describe which HW you are using with which SW Package and version ? Regards, Sebastien Riccardi

[NaveenKoyyada]

Hi Sebastien, The library version is ch101_gpr_version = "gpr_gpr-101_v47"; SonicLib API/Driver version = 4.2.1

And the sensor part number is EV_MOD_CH101-01-02.

The library was download from https://www.arduinolibraries.info/libraries/c-hx01

Regards, Naveen

[sriccardi-invn]

HI @NaveenKoyyada , Thanks for detail. How you manage voltage compatibility ? EV_MOD_CH101-01-02 support only 1.8v. Most of Arduino Board are only 3.3v. Have you try an example through Arduino IDE? Could you descrive wiring between nrf board and EV_MOD_CH101-01-02 and share sensor init logic analyzer traces? Regards, Seb

[NaveenKoyyada]

Hi @sriccardi-invn , Our HW team designed a level shifter, circuit diagram . Initially I tried with Arduino, but the sensor initialization is getting failed. So moved to interface with nRF which is the main MCU of my project. I will probe and share the images shortly.

regards, Naveen

[sriccardi-invn]

Hi @NaveenKoyyada, the complexity with level shifter is with INT IO because on CH101 this pin is bidirectional and active high. Waiting your logic analyze traces (SDA, SCL, PROG, INT, RST on 1.8v side). Regards, Sebastien

[NaveenKoyyada]

Hi @sriccardi-invn , Thanks for your patience. Is the above level shifter ckt is ok?, the part number of level shifter used for INT is 74AVCH4T245PW-Q10J.

I can only share the digital scope images. please find them below PROG pin at 1.8v Reset pin at 1.8v SCL at 1.8v SDA at 1.8v INT is active high 1.8v After debugging, I can observe that it is failing at Loading RAM

Thanks&Regards, Naveen

[rbuisson-invn]

Hello Naveen,

Could you please check the maximum number of bytes supported in a single I2C write access by your hardware (usually linked to the I2C FIFO depth)? During device programming the library tries to write a huge number of bytes in a single write access, assuming that the HAL will manage/split in multiple transfer depending on max I2C transmit length. If it appears that the transfer length is too big, you will have to modify your HAL to split the write accesses in multiple smaller write segments (of supported length), using I2C restart after each segment, such as: Start | Adress+write bit | segment0 | Restart | segment1 | Restart | segment2 | Stop

Please let us know the status, Regards

[NaveenKoyyada]

Okay I will go through the nRF library to find out this. Meanwhile, I have couple of questions running in my mind from few days.

1. Is there anything like soniclib software version supports particular ch101[suffix] part number?
2. I am currently using SonicLib API/Driver v4.2.1 and ch101_gpr_version is gpr_gpr-101_v47, Is it a working library and sensor part number is EV_MOD_CH101-01-02?
3. I have observed different ram init address and size in ch101_gpr_fw file for soniclib version 4.2.1 and 3.24.0, why there is difference in the firmware and how its related to sensor HW?

Thanks for the support. Let me get back to you once I confirm with the I2C transfer bytes. Regards, Naveen

[rbuisson-invn]

1. The SonicLib supports CH101 and CH102 among other TDK ultrasound sensors
2. Version v4.2.1 is the latest validated version and it comes with gpr v47, so all good.
3. You are correct the I2C address for firmware programming is different than the regular one.

Regards,

[NaveenKoyyada]

Hi @rbuisson-invn , Thanks for the clarification. I just printed how many bytes of transfer call is happening, please see below log For loading RAM, first call is of 3bytes(address is 1byte and 2bytes of data) but still I2C is getting failed.

Regards, Naveen

[rbuisson-invn]

Thanks for checking @NaveenKoyyada ! I checked the library source code, and these values are expected. So far, I don't understand how it could fail, while previous write at same address are correctly responded.

Could you please double check the following basic things:

• you are actually using a CH101 part (for which the ch101_gpr firmware is designed)
• the I2C address that you set for the device in chbsp_i2c_get_info is different than the programming address (0x45)
• as the previous operation is an I2C read, could you please check that the STOP condition is correctly emitted on I2C line.

Do you have any idea of the meaning of the error code "err -5" from the I2C HAL, it does not look like a nRF error code? It might be helpful to get nRF error.

Regards,

[rbuisson-invn]

It seems that some Nordic devices have issues with clock streching (see https://infocenter.nordicsemi.com/index.jsp?topic=%2Ferrata_nRF52832_Rev2%2FERR%2FnRF52832%2FRev2%2Flatest%2Fanomaly_832_149.html&anchor=anomaly_832_149). As CH101 uses clock streching it might be useful to look at I2C signals for the the failing writes).

[NaveenKoyyada]

Hi @rbuisson-invn Please find my reply for your previous message. you are actually using a CH101 part (for which the ch101_gpr firmware is designed) ANS: Yes, I rechecked the ch_init. I selected "ch101_gpr_init" which points to "ch101_gpr_fw_text " in ch101 firmware file. the I2C address that you set for the device in chbsp_i2c_get_info is different than the programming address (0x45) ANS: I didn't define chbsp_i2c_get_info struct. Verified the address 0x45 on each I2C call from library. as the previous operation is an I2C read, could you please check that the STOP condition is correctly emitted on I2C line. ANS: Yes, I checked.

I just debugged the initial I2C failure in loading ram. I observed that the ram parameters in below image if you see the ram init address is 512 and size is 38. When I analyze chdrv_prog_write(), in the first I2C call, the 512 is passed as data and address is 0x05(which further add with 0x80). Maybe is this giving issue for failure? Or I have to consider different API for this I2C call.

For soniclib version 3.24.0, the ram address is 2420 and size is 13. Will both versions work with same sensor?

Regards, Naveen

[NaveenKoyyada]

HI, My name is Sebastien Riccardi, I am Senior director at TDK and my team provided Chirp Sensor Arduino driver. CH101 sensor support only I2C. New ICU family support only SPI. Could you describe which HW you are using with which SW Package and version ? Regards, Sebastien Riccardi

Hi @sriccardi-invn , Did you get any chance to review my reply messages? Regards, @NaveenKoyyada

[NaveenKoyyada]

Hi @rbuisson-invn , Is there any update? Br, Naveen

[sriccardi-invn]

Hi @NaveenKoyyada , Remi is OOO today. He will update you tomorrow. Regards, Seb

[rbuisson-invn]

Hello @NaveenKoyyada ,

Thanks for your answers. Regarding "you are actually using a CH101 part" question, my point was to confirm that the hardware part that you are using is actually a CH101 (and not a CH201 for instance, which could explain the issue).

If you take a look to chdrv_prog_mem_write implementation, you'll see that the first step to write memory is to set the address register: ch_err = chdrv_prog_write(dev_ptr, CH_PROG_REG_ADDR, addr); This call will issue a write to I2C device 0x45, at address 0x05 (i.e. 0x85 with write bit), and 512 (0x200) for the data (LSB first). This is what I actually see in your trace: 0x85, 0x00, 0x02.

For some reason, your HAL detect an error and returns -5.

To progress on this debug, you could do the following:

1. Confirm that your hardware is actually a CH101 and not CH201
2. Check or share the source code of your HAL, to get the meaning of the -5 error code.
3. Share a picture of the above failing I2C access, to see if clock stretching is correctly supported (scl + sda on the same screen).

Thanks, and regards,

[NaveenKoyyada]

HI @rbuisson-invn , Thanks for pointing out, I analyzed I2C fail case the read call is not generating stop. I replaced platform I2C read call, now sensor firmware loading is done. Currently stuck at rtc calibration, I guess.

Thanks&Regards, Naveen

[rbuisson-invn]

Good news, thanks for the update! Interrupt pin direction is changed during the RTC calibration, in order to be driven high by the MCU (during 100ms). If you experience issues with that part of the init, it's usually a good starting point to check the INT signal.

Regards,

[NaveenKoyyada]

HI @rbuisson-invn , I just debugged the code, the actual issue is with sensor lock failure below is the log Is there anything to be handle on platform or it is independent of platform? Meanwhile I am ensuring INT pin level shifter logics on HW before testing the calibration.

Regards, Naveen

[rbuisson-invn]

Hello @NaveenKoyyada,

The frequency lock is managed by the firmware written to the device, only the chbsp_timestamp_ms is used to detect a timeout (and RTC calibration takes place later on). If the freq_lock fails it probably means that the firmware was not successfully written to the device.

Therefore, there is something strange in your log: the timestamp seems to be reset during firmware programming (and some strange characters are printed). Do you know what could have happened? -> The transfer of 2026 bytes of program could have overflowed something in your HAL (make sure your I2C HAL support this big numbers of bytes). -> The MCU could have been interrupted during CH101 firmware programing (make sure no interrupt is enabled during I2C transfer).

Regards,

[NaveenKoyyada]

HI @rbuisson-invn I verified the firmware data and I2C write calls, every call is successful. Further debugging, the I2C memory read is getting failed at following function call dev_ptr->current_fw->calib_funcs->get_locked_state(dev_ptr)) No idea, again why I2C error value -5, log:

Br,

[rbuisson-invn]

Thanks for checking, and your last log does not show the timestamp issue anymore. The failing access is supposed to read 1 byte at address 0x14. This is achieved using chbsp_i2c_mem_read BSP function. Your log says that the device address used for this access is 0x45 which is the Program address. This is incorrect and this access must be done using the device address instead. Is your BSP using ch_get_i2c_address(dev_ptr) to get the I2C address of the device?

[NaveenKoyyada]

I am using this statement "uint8_t address = dev_ptr->i2c_address;" in every I2C function call. You mean 0x29 for device address? Should I declare the address from platform? In info< I mentioned these parameters

Okay I will give a try to get address using ch_get_i2c_address(dev_ptr).

[NaveenKoyyada]

I used ch_get_i2c_address(dev_ptr) to get the address Please have look at below log, in both the cases the addresses are same. I tried this, assigned different address i.e.,0x2d

Since mem_read is failing, the corresponding I2C calls are also failing. I debugged it is not similar issue which a raised previously after I2C read which was not generating stop bit. I only doubt the mem address as you mentioned (please elaborate) and when the device address 0x29 come into picture.

Br

[rbuisson-invn]

Thanks @NaveenKoyyada for sharing the details of your implementation. chbsp_i2c_get_info is not correct:

• info_ptr->address must depend on the io_index input (each CH101 device on the bus must have different addresses), and must be different than 0x45. We usually use: 0x2D, 0x2C, 0x2B, 0x2A for up to 4 sensors.
• info_ptr->bus_num must be 0 (this is used when there are several CH101 on different I2C buses) I dont expect the above changes to be enough to make things work, but you should first fix them.

I notice that chbsp_i2c_mem_read uses both ch_get_i2c_address & dev_ptr->i2c_address, which is not a big issue, as the first does the same than the second. However, it is a better practice to use only ch_get_i2c_address.

Some clarification regarding the I2C addresses used by a CH101 device:

• PROG address 0x45 is used when programming the device (PROG pin == 1). During that first phase, the APP I2C address is programmed in the device (see the "Changing I2C address to X" message"
• APP address is used after the device has been programmed (PROG pin == 0). Default value is 0x29 (if i'm correct) but this value is updated during the first phase to value provided by chbsp_i2c_get_info function. This allow to support several CH101 devices on the same I2C bus (using different I2C addresses)

[rbuisson-invn]

If fixing chbsp_i2c_get_info is not enough to solve the problem, you could:

• check that the PROG pin is correctly set to 0 when executing chdrv_wait_for_lock.
• Verify the failing access (and share the scope capture), you should see an access at I2C address 0x2D, first writing 0x14 (the register address) and reading only one byte.

[NaveenKoyyada]

Thank you for details information and suggestions.

Let me debug and let you know.

[NaveenKoyyada]

HI @rbuisson-invn ,

The mem_read is success for frequency lock, however there is loop running for 10 times and getting failed. Booting nRF Connect SDK d96769faceca [00:00:00.256,896] main_init: GPIO Initialization

|| Scanning I2C_1 bus: |> Found device at address 0x29 [00:00:00.280,639] main_init: ch101_init

[00:00:00.280,670] ch_common: chbsp_i2c_get_info is OK

[00:00:00.280,670] ch101_sensor: ch_init successful

[00:00:00.380,798] ch_driver: chdrv_group_prepare:0

[00:00:00.380,828] ch_driver: chbsp_i2c_init:0

[00:00:00.387,542] ch_driver: Test I2C read: 020A [00:00:00.387,573] ch_driver: Device [0] found on bus [00:00:00.388,153] ch_driver: PROG_STAT: 0x05 [00:00:00.393,585] ch_driver: Loading RAM OK

[00:00:00.624,450] ch_driver: Wrote 2026 bytes in 122047 ms. [00:00:00.624,450] ch_driver: Firmware write OK

[00:00:00.625,274] ch_driver: Changing I2C address to 0x2d [00:00:00.641,448] ch_driver: ch101 sensor detected

[00:00:00.641,479] ch_driver: Sensor count: 1, 261 ms. [00:00:00.641,479] ch_driver: Chirp sensor initialized on I2C addr 1:0x2d [00:00:00.641,510] ch_driver: chdrv_group_wait_for_lock bypass

[00:00:00.641,510] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.642,059] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.642,089] ch_driver: chdrv_read_byte ret_val: 0 [00:00:00.652,160] ch_driver: chdrv_wait_for_lock

[00:00:00.652,160] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.652,740] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.652,740] ch_driver: chdrv_read_byte ret_val: 0 [00:00:00.662,841] ch_driver: chdrv_wait_for_lock

[00:00:00.662,841] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.663,421] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.663,421] ch_driver: chdrv_read_byte ret_val: 0 [00:00:00.673,522] ch_driver: chdrv_wait_for_lock

[00:00:00.673,522] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.674,102] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.674,102] ch_driver: chdrv_read_byte ret_val: 0 [00:00:00.684,204] ch_driver: chdrv_wait_for_lock

[00:00:00.684,234] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.684,783] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.684,783] ch_driver: chdrv_read_byte ret_val: 0 [00:00:00.694,915] ch_driver: chdrv_wait_for_lock

[00:00:00.694,946] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.695,526] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.695,526] ch_driver: chdrv_read_byte ret_val: 0 [00:00:00.705,627] ch_driver: chdrv_wait_for_lock

[00:00:00.705,627] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.706,207] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.706,207] ch_driver: chdrv_read_byte ret_val: 0 [00:00:00.716,308] ch_driver: chdrv_wait_for_lock

[00:00:00.716,339] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.716,888] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.716,888] ch_driver: chdrv_read_byte ret_val: 0 [00:00:00.727,020] ch_driver: chdrv_wait_for_lock

[00:00:00.727,050] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.727,630] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.727,630] ch_driver: chdrv_read_byte ret_val: 0 [00:00:00.737,731] ch_driver: chdrv_wait_for_lock

[00:00:00.737,731] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.738,311] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.738,311] ch_driver: chdrv_read_byte ret_val: 0 [00:00:00.748,413] ch_driver: chdrv_wait_for_lock

[00:00:00.748,413] ch_driver: Sensor 0 initialization timed out or missing [00:00:00.748,443] ch_driver: Frequency lock failed [00:00:00.748,443] ch_driver: RETRY : 1/4

If you see the time taken for mem_read is less than 100ms, even though the loop is continuing untill the condition in the following code satisfies

Please give your comments

Br Naveen

[NaveenKoyyada]

HI @rbuisson-invn ,

Is there any update on this? Why the loop is still continuous even the data read is 0x2?

I still stuck here however I bypassed this step and continues testing remaining code to avoid any blocking.

Br, Naveen

[rbuisson-invn]

Hello @NaveenKoyyada ,

You're correct I expect that the loop would be exited in success after a read of 0x2. I thinks I see the issue

• the value 0x02 is correctly read on the bus BUT not well returned to the caller (here ready_value) chdrv_read_byte(dev_ptr, ready_reg, &ready_value); In previously shared implementation of chbsp_i2c_mem_read you had: So you are passing a pointer to data (&data), which is already a pointer (declared as uint8_t *data as function parameter). As a result the read value is not correctly set to data, as it would be expected. Please fix chbsp_i2c_mem_read with : int ret = i2c_burst_read(i2c_ch,(uint16_t)address,(uint8_t)mem_addr,data,num_bytes);

[NaveenKoyyada]

HI @rbuisson-invn ,

The level shifter is giving some issue, so I paused the development for some time. As of now, the frequency lock is happening. Next is RTC calibration, the mem_read function for 8bytes is giving some bus fault error, this is related platform (even though I mentioned buf size to 1024 in the I2C configuration). ------log starts--------

CH101 Testing SW_version: v1.4 HW_version:EVB

UART service initialized [00:00:00.250,640] VL53L0X: [vl53l0x@29] Missing XSHUT gpio spec Booting nRF Connect SDK d96769faceca [00:00:00.256,927] main_init: GPIO Initialization

[00:00:00.257,324] main_init: ch101_interrupts_init success [00:00:00.257,324] ch_common: chbsp_i2c_get_info is OK

[00:00:00.257,354] ch101_sensor: ch_init successful

[00:00:00.357,482] ch_driver: chdrv_group_prepare:0

[00:00:00.357,513] ch_driver: chbsp_i2c_init:0

[00:00:00.370,544] chbsp_chirp: chbsp_i2c_write 3bytes failed to addr:0x45 err:-5

[00:00:00.870,666] chbsp_chirp: chbsp_i2c_write 2bytes failed to addr:0x45 err:-5

[00:00:01.370,788] chbsp_chirp: chbsp_i2c_write 2bytes failed to addr:0x45 err:-5

[00:00:00.531,524] ch_driver: chdrv_group_prepare:0

[00:00:00.531,555] ch_driver: chbsp_i2c_init:0

[00:00:00.538,299] ch_driver: Test I2C read: 020A [00:00:00.538,330] ch_driver: Device [0] found on bus [00:00:00.538,909] ch_driver: PROG_STAT: 0x05 [00:00:00.544,342] ch_driver: Loading RAM OK

[00:00:00.775,146] ch_driver: Wrote 2026 bytes in 122159 ms. [00:00:00.775,146] ch_driver: Firmware write OK

[00:00:00.775,970] ch_driver: Changing I2C address to 0x2d [00:00:00.792,144] 00:00:00.792,175] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.792,755] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.802,825] ch_driver: chdrv_wait_for_lock:10

[00:00:00.802,825] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.803,405] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.813,507] ch_driver: chdrv_wait_for_lock:21

[00:00:00.813,507] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.814,086] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.824,188] ch_driver: chdrv_wait_for_lock:32

[00:00:00.824,218] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.824,768] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.834,869] ch_driver: chdrv_wait_for_lock:42

[00:00:00.834,899] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.835,449] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.845,550] ch_driver: chdrv_wait_for_lock:53

[00:00:00.845,550] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.846,130] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.856,231] ch_driver: chdrv_wait_for_lock:64

[00:00:00.856,262] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.856,842] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.866,943] ch_driver: chdrv_wait_for_lock:74

[00:00:00.866,973] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.867,523] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.877,624] ch_driver: chdrv_wait_for_lock:85

[00:00:00.877,655] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.878,234] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.888,336] ch_driver: chdrv_wait_for_lock:96

[00:00:00.888,366] chbsp_chirp: chbsp_i2c_mem_read called 1 nbytes addr:2d

[00:00:00.888,916] chbsp_chirp: chbsp_i2c_mem_read 1bytes success to addr:0x2d

[00:00:00.899,017] ch_driver: chdrv_wait_for_lock:107

[00:00:00.899,047] ch_driver: Frequency locked, 368 ms [00:00:00.899,047] ch_driver: RETRY exit

[00:00:00.900,177] ch_driver: Calibrate RTC

[00:00:00.900,177] chbsp_chirp: chbsp_i2c_mem_write called 2 nbytes

[00:00:00.900,604] chbsp_chirp: chbsp_i2c_mem_write 2bytes success to addr:0x2d

[00:00:00.900,634] chbsp_chirp: chbsp_i2c_mem_read called 2 nbytes addr:2d

[00:00:00.901,336] chbsp_chirp: chbsp_i2c_mem_read 2bytes success to addr:0x2d

[00:00:00.901,336] chbsp_chirp: chbsp_i2c_mem_read called 2 nbytes addr:2d

[00:00:00.902,069] chbsp_chirp: chbsp_i2c_mem_read 2bytes success to addr:0x2d

[00:00:00.902,069] chbsp_chirp: chbsp_i2c_mem_read called 8 nbytes addr:2d

[00:00:00.903,350] os: BUS FAULT [00:00:00.903,381] os: Precise data bus error [00:00:00.903,381] os: BFAR Address: 0xf46808c6 [00:00:00.903,381] os: r0/a1: 0x00000000 r1/a2: 0x00000000 r2/a3: 0xf46808c6 [00:00:00.903,411] os: r3/a4: 0x00000000 r12/ip: 0x20000298 r14/lr: 0x0001a1e3 [00:00:00.903,411] os: xpsr: 0x89000000 [00:00:00.903,442] os: Faulting instruction address (r15/pc): 0x00001b12 [00:00:00.903,472] os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0 [00:00:00.903,503] os: Current thread: 0x20003908 (unknown) [00:00:01.356,140] fatal_error: Resetting system�

------log ends------------

Let me fix my hardware and the above error and get back to you. Meanwhile Is there any dependency on platform for RTC calibration apart from mem_read and INT pin set/clr. And also, is this library developed any of the nRF platform? It could help me in expedite the development, because I see the platform I2C issues.

Br, Naveen.

[rbuisson-invn]

Hello Naveen,

RTC calibration is done by the MCU sending a pulse on IT line, waiting 100ms (MCU time) and then sending a second pulse. This lets the device calibrate its clock using this 100ms delay as a reference. So basically, the dependencies are I2C communication, INT pin driving, and the MCU delay. The reference HW (Ultrasonic ToF EVK board) uses a level shifter with a dedicated pin to control the direction, if you're using same kind of level shifter you'll need an additional pin control.

Regards,

[NaveenKoyyada]

Thanks for the information let me check Br Naveen

[rbuisson-invn]

Hello Naveen,

To correct a bit what I said in my previous message: the RTC calibration is performed using a 100ms pulse on the INT1 line (NOT with 2 pulses), as in following picture.

Regards,

[NaveenKoyyada]

Hi @rbuisson-invn , The frequency lock is not happening, the mem_read is getting failed. After repeat testing, the sensor is working till the use of device address 0x45 and when application address 0x29/0x2d is called the sensor is not reachable. log: [00:00:00.518,829] ch_driver: chdrv_group_prepare:0

[00:00:00.518,859] ch_driver: chbsp_i2c_init:0

[00:00:00.525,604] ch_driver: Test I2C read: 020A [00:00:00.525,634] ch_driver: Device [0] found on bus [00:00:00.526,214] ch_driver: PROG_STAT: 0x05 [00:00:00.531,646] ch_driver: Loading RAM OK

[00:00:00.762,451] ch_driver: Wrote 2026 bytes in 122187 ms. [00:00:00.762,451] ch_driver: Firmware write OK

[00:00:00.763,275] ch_driver: Changing I2C address to 0x29 [00:00:00.779,418] ch_driver: ch101 sensor detected

[00:00:00.779,449] ch_driver: Sensor count: 1, 261addr:0x29 mem_addr:0x14

[00:00:00.779,693] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:00.789,794] ch_driver: chdrv_wait_for_lock:10

[00:00:00.789,825] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:00.790,008] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:00.800,109] ch_driver: chdrv_wait_for_lock:21

[00:00:00.800,140] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:00.800,354] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:00.810,424] ch_driver: chdrv_wait_for_lock:31

[00:00:00.810,455] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:00.810,668] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:00.820,739] ch_driver: chdrv_wait_for_lock:41

[00:00:00.820,770] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:00.820,983] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:00.831,054] ch_driver: chdrv_wait_for_lock:52

[00:00:00.831,085] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:00.831,298] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:00.841,369] ch_driver: chdrv_wait_for_lock:62

[00:00:00.841,400] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:00.841,613] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:00.851,715] ch_driver: chdrv_wait_for_lock:72

[00:00:00.851,745] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:00.851,959] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:00.862,030] ch_driver: chdrv_wait_for_lock:83

[00:00:00.862,060] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:00.862,274] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:00.872,375] ch_driver: chdrv_wait_for_lock:93

[00:00:00.872,406] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:00.872,619] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:00.882,690] ch_driver: chdrv_wait_for_lock:103

[00:00:00.882,720] ch_driver: Sensor 0 initialization timed out or missing [00:00:00.882,720] ch_driver: Frequency lock failed [00:00:00.882,720] ch_driver: RETRY : 1/4

[00:00:00.889,526] ch_driver: Test I2C read: 020A [00:00:00.889,526] ch_driver: Device [0] found on bus [00:00:00.890,106] ch_driver: PROG_STAT: 0x05 [00:00:00.895,538] ch_driver: Loading RAM OK

[00:00:01.125,579] ch_driver: Wrote 2026 bytes in 122187 ms. [00:00:01.125,610] ch_driver: Firmware write OK

[00:00:01.126,403] ch_driver: Changing I2C address to 0x29 [00:00:01.142,395] ch_driver: ch101 sensor detected

[00:00:01.142,395] ch_driver: Sensor count: 2, 624 ms. [00:00:01.142,395] ch_driver: Chirp sensor initialized on I2C addr 0:0x29 [00:00:01.142,425] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:01.142,639] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:01.152,709] ch_driver: chdrv_wait_for_lock:10

[00:00:01.152,740] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:01.152,954] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:01.163,024] ch_driver: chdrv_wait_for_lock:21

[00:00:01.163,055] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:01.163,269] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:01.173,370] ch_driver: chdrv_wait_for_lock:31

[00:00:01.173,370] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:01.173,583] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:01.183,685] ch_driver: chdrv_wait_for_lock:41

[00:00:01.183,715] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:01.183,929] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:01.194,030] ch_driver: chdrv_wait_for_lock:52

[00:00:01.194,061] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:01.194,274] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:01.204,345] ch_driver: chdrv_wait_for_lock:62

[00:00:01.204,376] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:01.204,589] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:01.214,660] ch_driver: chdrv_wait_for_lock:72

[00:00:01.214,691] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:01.214,904] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:01.224,975] ch_driver: chdrv_wait_for_lock:82

[00:00:01.225,006] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:01.225,219] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:01.235,290] ch_driver: chdrv_wait_for_lock:93

[00:00:01.235,321] chbsp_chirp: chbsp_i2c_mem_read i2c_addr:0x29 mem_addr:0x14

[00:00:01.235,534] chbsp_chirp: chbsp_i2c_mem_read 1bytes failed from addr:0x14 err:-5

[00:00:01.245,605] ch_driver: chdrv_wait_for_lock:103

[00:00:01.245,635] ch_driver: Sensor 0 initialization timed out or missing [00:00:01.245,635] ch_driver: Frequency lock failed

BSP mem_read function:

Please review and provide suggestion

Br, Naveen

[rbuisson-invn]

Hi @NaveenKoyyada , please try at line 180: msg[0].buf = \®

Regards,

[NaveenKoyyada]

I tried this modification while debugging, it didn't work.

[rbuisson-invn]

i2c_msg.buf is a pointer so you cannot set it to a uint8_t. You must set the address of the uint8_t. Might be other issues, but this is not correct. In the end, the better approach would be to get the I2C traces.

[NaveenKoyyada]

Yes, it's a pointer so address should be passed. I tested i2c burst read, i2c write read and i2c transfer, just in case it would work. The one which was worked earlier is i2c burst read. Unfortunately, I cannot have logic analyzer traces. On digital oscilloscope, I triggered and checked but it was hard to analyze which is continuous stream of data. The level shifter Iam using is single mosfet configuration, Is it not giving issue!