undefined reference twi error

[simon1516]

Hi,

I hope you can help me. I get an error while compiling. I merge "twi sensor" example from sdk to the "ble app uart" example from sdk. So I customize the sdk_config to enable twi. In addition to that, I add all missing nRF_Drivers to make it work. While compiling, I get the following output:

1> "C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.50/gcc/arm-none-eabi/bin/as" --traditional-format -I../../../config -I../../../../../../components -I../../../../../../components/ble/ble_advertising -I../../../../../../components/ble/ble_dtm -I../../../../../../components/ble/ble_link_ctx_manager -I../../../../../../components/ble/ble_racp -I../../../../../../components/ble/ble_services/ble_ancs_c -I../../../../../../components/ble/ble_services/ble_ans_c -I../../../../../../components/ble/ble_services/ble_bas -I../../../../../../components/ble/ble_services/ble_bas_c -I../../../../../../components/ble/ble_services/ble_cscs -I../../../../../../components/ble/ble_services/ble_cts_c -I../../../../../../components/ble/ble_services/ble_dfu -I../../../../../../components/ble/ble_services/ble_dis -I../../../../../../components/ble/ble_services/ble_gls -I../../../../../../components/ble/ble_services/ble_hids -I../../../../../../components/ble/ble_services/ble_hrs -I../../../../../../components/ble/ble_services/ble_hrs_c -I../../../../../../components/ble/ble_services/ble_hts -I../../../../../../components/ble/ble_services/ble_ias -I../../../../../../components/ble/ble_services/ble_ias_c -I../../../../../../components/ble/ble_services/ble_lbs -I../../../../../../components/ble/ble_services/ble_lbs_c -I../../../../../../components/ble/ble_services/ble_lls -I../../../../../../components/ble/ble_services/ble_nus -I../../../../../../components/ble/ble_services/ble_nus_c -I../../../../../../components/ble/ble_services/ble_rscs -I../../../../../../components/ble/ble_services/ble_rscs_c -I../../../../../../components/ble/ble_services/ble_tps -I../../../../../../components/ble/common -I../../../../../../components/ble/nrf_ble_gatt -I../../../../../../components/ble/nrf_ble_qwr -I../../../../../../components/ble/peer_manager -I../../../../../../components/boards -I../../../../../../components/libraries/atomic -I../../../../../../components/libraries/atomic_fifo -I../../../../../../components/libraries/atomic_flags -I../../../../../../components/libraries/balloc -I../../../../../../components/libraries/bootloader/ble_dfu -I../../../../../../components/libraries/bsp -I../../../../../../components/libraries/button -I../../../../../../components/libraries/cli -I../../../../../../components/libraries/crc16 -I../../../../../../components/libraries/crc32 -I../../../../../../components/libraries/crypto -I../../../../../../components/libraries/csense -I../../../../../../components/libraries/csense_drv -I../../../../../../components/libraries/delay -I../../../../../../components/libraries/ecc -I../../../../../../components/libraries/experimental_section_vars -I../../../../../../components/libraries/experimental_task_manager -I../../../../../../components/libraries/fds -I../../../../../../components/libraries/fifo -I../../../../../../components/libraries/fstorage -I../../../../../../components/libraries/gfx -I../../../../../../components/libraries/gpiote -I../../../../../../components/libraries/hardfault -I../../../../../../components/libraries/hci -I../../../../../../components/libraries/led_softblink -I../../../../../../components/libraries/log -I../../../../../../components/libraries/log/src -I../../../../../../components/libraries/low_power_pwm -I../../../../../../components/libraries/mem_manager -I../../../../../../components/libraries/memobj -I../../../../../../components/libraries/mpu -I../../../../../../components/libraries/mutex -I../../../../../../components/libraries/pwm -I../../../../../../components/libraries/pwr_mgmt -I../../../../../../components/libraries/queue -I../../../../../../components/libraries/ringbuf -I../../../../../../components/libraries/scheduler -I../../../../../../components/libraries/sdcard -I../../../../../../components/libraries/slip -I../../../../../../components/libraries/sortlist -I../../../../../../components/libraries/spi_mngr -I../../../../../../components/libraries/stack_guard -I../../../../../../components/libraries/strerror -I../../../../../../components/libraries/svc -I../../../../../../components/libraries/timer -I../../../../../../components/libraries/twi_mngr -I../../../../../../components/libraries/twi_sensor -I../../../../../../components/libraries/uart -I../../../../../../components/libraries/usbd -I../../../../../../components/libraries/usbd/class/audio -I../../../../../../components/libraries/usbd/class/cdc -I../../../../../../components/libraries/usbd/class/cdc/acm -I../../../../../../components/libraries/usbd/class/hid -I../../../../../../components/libraries/usbd/class/hid/generic -I../../../../../../components/libraries/usbd/class/hid/kbd -I../../../../../../components/libraries/usbd/class/hid/mouse -I../../../../../../components/libraries/usbd/class/msc -I../../../../../../components/libraries/util -I../../../../../../components/nfc/ndef/conn_hand_parser -I../../../../../../components/nfc/ndef/conn_hand_parser/ac_rec_parser -I../../../../../../components/nfc/ndef/conn_hand_parser/ble_oob_advdata_parser -I../../../../../../components/nfc/ndef/conn_hand_parser/le_oob_rec_parser -I../../../../../../components/nfc/ndef/connection_handover/ac_rec -I../../../../../../components/nfc/ndef/connection_handover/ble_oob_advdata -I../../../../../../components/nfc/ndef/connection_handover/ble_pair_lib -I../../../../../../components/nfc/ndef/connection_handover/ble_pair_msg -I../../../../../../components/nfc/ndef/connection_handover/common -I../../../../../../components/nfc/ndef/connection_handover/ep_oob_rec -I../../../../../../components/nfc/ndef/connection_handover/hs_rec -I../../../../../../components/nfc/ndef/connection_handover/le_oob_rec -I../../../../../../components/nfc/ndef/generic/message -I../../../../../../components/nfc/ndef/generic/record -I../../../../../../components/nfc/ndef/launchapp -I../../../../../../components/nfc/ndef/parser/message -I../../../../../../components/nfc/ndef/parser/record -I../../../../../../components/nfc/ndef/text -I../../../../../../components/nfc/ndef/uri -I../../../../../../components/nfc/platform -I../../../../../../components/nfc/t2t_lib -I../../../../../../components/nfc/t2t_parser -I../../../../../../components/nfc/t4t_lib -I../../../../../../components/nfc/t4t_parser/apdu -I../../../../../../components/nfc/t4t_parser/cc_file -I../../../../../../components/nfc/t4t_parser/hl_detection_procedure -I../../../../../../components/nfc/t4t_parser/tlv -I../../../../../../components/softdevice/common -I../../../../../../components/softdevice/s140/headers -I../../../../../../components/softdevice/s140/headers/nrf52 -I../../../../../../components/toolchain/cmsis/include -I../../../../../../external/fprintf -I../../../../../../external/segger_rtt -I../../../../../../external/utf_converter -I../../../../../../integration/nrfx -I../../../../../../integration/nrfx/legacy -I../../../../../../modules/nrfx -I../../../../../../modules/nrfx/drivers/include -I../../../../../../modules/nrfx/hal -I../../../../../../modules/nrfx/mdk -I../config -mcpu=cortex-m4 -mlittle-endian -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mthumb "C:/Users/hp/Desktop/Firmware Entwicklung/nRF5SDK160098a08e2.zip/examples/ble_peripheral/ble_app_uart/pca10100/s140/ses/Output/ble_app_uart_pca10100_s140 Debug/Obj/main.asm" -o "Output/ble_app_uart_pca10100_s140 Debug/Obj/main.o"
1> rm "C:/Users/hp/Desktop/Firmware Entwicklung/nRF5SDK160098a08e2.zip/examples/ble_peripheral/ble_app_uart/pca10100/s140/ses/Output/ble_app_uart_pca10100_s140 Debug/Obj/main.asm"
1> Output/ble_app_uart_pca10100_s140 Debug/Obj/main.o (28.06.2020 20:58:16) is newer than Output/Debug/Exe/ble_app_uart_pca10100_s140.elf (28.06.2020 20:57:32).
1> Linking ble_app_uart_pca10100_s140.elf
1> "C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.50/gcc/arm-none-eabi/bin/ld" -X --omagic -eReset_Handler --defsym=__vfprintf=__vfprintf_long --defsym=__vfscanf=__vfscanf_long -EL --gc-sections "-TC:/Users/hp/Desktop/Firmware Entwicklung/nRF5SDK160098a08e2.zip/examples/ble_peripheral/ble_app_uart/pca10100/s140/ses/Output/ble_app_uart_pca10100_s140 Debug/Obj/ble_app_uart_pca10100_s140.ld" -Map Output/Debug/Exe/ble_app_uart_pca10100_s140.map -u_vectors -o Output/Debug/Exe/ble_app_uart_pca10100_s140.elf --emit-relocs --start-group "@C:/Users/hp/Desktop/Firmware Entwicklung/nRF5SDK160098a08e2.zip/examples/ble_peripheral/ble_app_uart/pca10100/s140/ses/Output/ble_app_uart_pca10100_s140 Debug/Obj/ble_app_uart_pca10100_s140.ind" --end-group
1> C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.50/gcc/arm-none-eabi/bin/ld: Output/ble_app_uart_pca10100_s140 Debug/Obj/nrf_drv_twi.o: in function `nrf_drv_twi_init':
1> C:\Users\hp\Desktop\Firmware Entwicklung\nRF5SDK160098a08e2.zip\integration\nrfx\legacy/nrf_drv_twi.c:186: undefined reference to `nrfx_twi_init'
1> C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.50/gcc/arm-none-eabi/bin/ld: Output/ble_app_uart_pca10100_s140 Debug/Obj/main.o: in function `nrf_drv_twi_enable':
1> C:\Users\hp\Desktop\Firmware Entwicklung\nRF5SDK160098a08e2.zip\examples\ble_peripheral\ble_app_uart\pca10100\s140\ses/../../../../../../integration/nrfx/legacy/nrf_drv_twi.h:513: undefined reference to `nrfx_twim_enable'
1> C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.50/gcc/arm-none-eabi/bin/ld: Output/ble_app_uart_pca10100_s140 Debug/Obj/main.o: in function `nrf_drv_twi_tx':
1> C:\Users\hp\Desktop\Firmware Entwicklung\nRF5SDK160098a08e2.zip\examples\ble_peripheral\ble_app_uart\pca10100\s140\ses/../../../../../../integration/nrfx/legacy/nrf_drv_twi.h:544: undefined reference to `nrfx_twim_tx'
Build failed

But I don´t know what I´m making wrong.

Could you help me with that?

Thanks in advance

[Karl Ylvisaker]

Hello,

Which SDK are you using?
If you are using the newer versions in which nrf_drv_* is legacy, you will notice that they are forwarding macros to the new nrfx_ drivers.
Therefore, you will need to also add the nrfx_ drivers to your project for the TWI functionality to work. Namely, it seems you are missing nrfx_twim.c. You can see from the error codes that the problem is nrf_drv_twi_* making calls to undefined "nrfx_twim_*" functions.
I would also recommend you that you work directly with the nrfx_ drivers, instead of using the legacy layers - this will decrease future work in which you will have to port your code to the nrfx_ drivers, since nrf_drv is already legacy.

For future reference, it would be beneficial if you were specific when saying that you have added "all missing nRF_drivers to make it work" - which drivers have you added, and which changes have you made to sdk_config?

Please let me know if this does not resolve your problem, or if anything regarding the nrfx_* vs. nrf_drv_* drivers should be unclear.

Best regards,
Karl

[simon1516]

Hi,

I´m using SDK 16.

Karl Ylvisaker said:

Namely, it seems you are missing nrfx_twim.c.

I don´t think so. I added it in the folder "nRF_Drivers as shown in screenshot attached.

I have added the twi drivers in the BLE Uart example, to make TWI work (the same drivers are used in TWI Sensor example of SDK):

- nrfx_twim.c

- nrf_drv_twi.c

In addition to that, I customized sdk_config. In general I enabled all TWI options. Nothing special I think. I attached the sdk_config if it would help you for analyzing.

53234.sdk_config.h

Another thing is, that the application is compiling well in "release" build configuration, but not in "debug" configuration. But when I compile in "release", the BLE application doesn´t work.

Because of nrfx_twim.c is already in my driver folder the problem exists furthermore. Is there something else I could try? Thanks in advance.

Simon

[Karl Ylvisaker]

Hello Simon,

I am terribly sorry for the long delay in answering - I have been out of office for some time now, and this ticket had the "verified answer" status, which made it slip through the cracks.
Do you still require help with this issue?

simon1516 said:

I think I can reach the sensor correctly, because if I change the sensor I2C adress the application doesn´t work - so I think I2C connection works fine and the sensor is reachable.

This is not a definitive way to confirm whether your TWI communication is succeeding or not.
If you take a look at the TWI Scanner example you can see how you may detect the device's address, and thus ensure you are reaching the sensor correctly. I.e if you flash your device with the unmodified example, it should detect your sensor and write its device address to the log. 

simon1516 said:

I´m not sure, when to use "m_xfer_done = false;" In the first lines it is included, in the second lines not.

m_xfer_done should be set true during the callback for the NRFX_TWIM_EVT_DONE event. This will ensure that the previous write / read has finished before proceeding to the next. If I remember correctly the initial value of this is false, but it would indeed be better practice to set it to false before any TWI operation is initiated.

simon1516 said:

Then I read 1 byte of this register.

The register 0 is a "test-register" from the sensor (ICM20948), and the standard value stored in this register is "0xEA". So i should read this value.

But if I watch the value from "m_sample", there I can see different values in it...I update this variable twice a second...sometimes I can see the correct value "0xEA". But not always.  Something I´m making wrong...

It seems weird that you can only see the correct value "sometimes" - what are you seeing when the value is incorrect? Is there any errors generated when this happens?

simon1516 said:

In general, for I2C communiction I need to write to a register, before I can read it. Is that correct?

Yes, in TWI communication the master must initiate the read, by writing to the slave that it would like to read out the contents of a specific register.

Again, my apologies for the late reply.

Looking forward to resolving this issue together!

Best regards,
Karl

[simon1516]

Hi Karl, thank you for your reply :-)

Karl Ylvisaker said:

I am terribly sorry for the long delay in answering - I have been out of office for some time now, and this ticket had the "verified answer" status, which made it slip through the cracks.
Do you still require help with this issue?

No problem, and yes, I would need a little bit help.

----------------------------------------------------------------

Karl Ylvisaker said:

This is not a definitive way to confirm whether your TWI communication is succeeding or not.
If you take a look at the TWI Scanner example you can see how you may detect the device's address, and thus ensure you are reaching the sensor correctly. I.e if you flash your device with the unmodified example, it should detect your sensor and write its device address to the log. 

Done. I can reach the sensor with the example.

Karl Ylvisaker said:

It seems weird that you can only see the correct value "sometimes" - what are you seeing when the value is incorrect? Is there any errors generated when this happens?

I have analyzed this many times now - And what I can see is: It seems that the register I read increment every "read process". So I can read the correct value exactly every 64 times.Every 64 times, because the register map (user bank 0 has 64 registers; https://invensense.tdk.com/wp-content/uploads/2016/06/DS-000189-ICM-20948-v1.3.pdf chapter 7.1). And also the other values are repeating every 64 times...I would like to show you my actual function for reading from the sensor - no worry, just a few lines of code :-)

The code is really simple:

1. chose the correct register (write)

2. read one byte from the sensor (read)

static void read_sensor_data()
{

        /* register "0" chose */
    uint8_t reg5 = {0x00};
    nrfx_twim_xfer_desc_t test = NRFX_TWIM_XFER_DESC_TX(ICM20948_ADDR, &reg5, sizeof(reg5));

    m_xfer_done = false;
    nrfx_twim_xfer_desc_t lm75b_reading = NRFX_TWIM_XFER_DESC_RX(ICM20948_ADDR, &m_sample, sizeof(m_sample));

    /* Read */
  ret_code_t err_code = nrfx_twim_xfer(&m_twim, &lm75b_reading, NULL);
   APP_ERROR_CHECK(err_code);



}

I think in this code is the fault, but I don´t know what I´m doing wrong. My aim is it, to read the same register every time.

It would be great, if you can help me with that.

Kind regards

Simon

[Karl Ylvisaker]

Hello Simon,

simon1516 said:

thank you for your reply :-)

No problem at all, I am happy to help! :)

simon1516 said:

Done. I can reach the sensor with the example.

Great, then we know the connection is working, and that the sensor is replying as expected.

simon1516 said:

I have analyzed this many times now - And what I can see is: It seems that the register I read increment every "read process". So I can read the correct value exactly every 64 times.Every 64 times, because the register map (user bank 0 has 64 registers; https://invensense.tdk.com/wp-content/uploads/2016/06/DS-000189-ICM-20948-v1.3.pdf chapter 7.1).

Could you confirm for me what frequency you are using for your TWIM? - Judging by your main.c you shared some time ago, what is the value of your NRFX_TWIM_DEFAULT_CONFIG define in the sdk_config?

simon1516 said:

The code is really simple:

1. chose the correct register (write)

2. read one byte from the sensor (read)

I am not sure I have understood you correctly, but you do nothing with your initial nrfx_twim_xfer_desc_t test struct here - you are not transferring it. with the code you share here.
You will need to call nrfx_twim_xfer; the NRFX_TWIM_XFER_DESC_TX only creates a TX description structure.
Especially, please see Section 6.3: Single-Byte Read Sequence in the datasheet you linked.
Usually, you can think of even addresses as write-to addresses, and odd addresses as read-from addresses. wince the LSB of the 8-bit address determines the R/W bit.
What does your log output when you run your program, btw?

I highly recommend reading a this summary of the TWI protocol, to gain a better understanding of how the protocol is built.

Looking forward to resolving this issue together!

Best regards,
Karl

[simon1516]

Hi Karl,

I hope you are fine.

Karl Ylvisaker said:

Could you confirm for me what frequency you are using for your TWIM? - Judging by your main.c you shared some time ago, what is the value of your NRFX_TWIM_DEFAULT_CONFIG define in the sdk_config?

It was configured to 400k. I changed this to 100k but it doesn´t take affect. The result was the same.

Karl Ylvisaker said:

I am not sure I have understood you correctly, but you do nothing with your initial nrfx_twim_xfer_desc_t test struct here - you are not transferring it. with the code you share here.
You will need to call nrfx_twim_xfer; the NRFX_TWIM_XFER_DESC_TX only creates a TX description structure.

The problem is, if I add the line "err_code = nrfx_twim_xfer(&m_twim, &test, NULL);" directly behind the TX description structure the application aborts. In debug terminal I get the following messages:

Karl Ylvisaker said:

Especially, please see Section 6.3: Single-Byte Read Sequence in the datasheet you linked.
Usually, you can think of even addresses as write-to addresses, and odd addresses as read-from addresses. wince the LSB of the 8-bit address determines the R/W bit.
What does your log output when you run your program, btw?

Yes, I tried to follow the insctructions from the manual:

But in general: My understandness is, that if I call "nrfx_twim_xfer" after a "NRFX_TWIM_XFER_DESC_TX" then this "write procedure" works automatically (Start Signal, I2C Adress etc), isn´t that right?

In addition to that, I attached my actual source code. I have just copied you example from above. The only change is, adding my sensor (ICM20948) to it instead of LM75b.

ble_app_uart_with_twim v0.2.zip

Thanks for help!

Simon

[Karl Ylvisaker]

Hello Simon,

simon1516 said:

I hope you are fine.

I am fine, and I hope you are too. Thank you for asking!

simon1516 said:

It was configured to 400k. I changed this to 100k but it doesn´t take affect. The result was the same.

From the datasheet it seems 400k is the appropriate frequency, so please revert to 400k.

simon1516 said:

The problem is, if I add the line "err_code = nrfx_twim_xfer(&m_twim, &test, NULL);" directly behind the TX description structure the application aborts. In debug terminal I get the following messages:

You will need to call _xfer if you intend to do the write. The debug terminal in the included picture is empty.
Could you make sure that you have DEBUG defined in your preprocessor settings? The included picture illustrates how you could go about doing this.
This will allow you to see the specific error that triggered APP_ERROR_CHECK.
Please make sure DEBUG is defined as shown, and then add _xfer again, and see what error is being generated.
 

simon1516 said:

But in general: My understandness is, that if I call "nrfx_twim_xfer" after a "NRFX_TWIM_XFER_DESC_TX" then this "write procedure" works automatically (Start Signal, I2C Adress etc), isn´t that right?

I am not sure I have understood what you mean here correctly, but if you are asking if the XFER_DESC_TX readies a single TWIM_TX with the information you provide it ( address, p_data, and length ) then yes, that is the case.

simon1516 said:

In addition to that, I attached my actual source code. I have just copied you example from above. The only change is, adding my sensor (ICM20948) to it instead of LM75b.

Thank you. I think we will be able to get to the bottom of it when we see what error is being generated by the _XFER function. If not, I will take a look at the project and see if I am able to replicate this behavior on my end.

Looking forward to resolving this issue together!

Best regards,
Karl

[simon1516]

Hi Karl,

Karl Ylvisaker said:

Could you make sure that you have DEBUG defined in your preprocessor settings? The included picture illustrates how you could go about doing this.

I added "DEBUG" in first line because it wasn´t there. Unfortunaly, I didn´t get messages in the debug terminal. If I press "build an debug" I went to the same error, but without any help in the debug window...

Could there be a problem, using nrf52833 instead of nrf52840?

I set active build confifuration to "debug" instead of "release", but this doesn´t take affect. Is there something other I could try?

Karl Ylvisaker said:

I am not sure I have understood what you mean here correctly, but if you are asking if the XFER_DESC_TX readies a single TWIM_TX with the information you provide it ( address, p_data, and length ) then yes, that is the case.

Could there be a problem with my TWIM address? ICM20948 has 0x69 by default. So I assume that the TWIM functions RX and TX automatically set the LSB for Read/Write. Is that correct?

Kind regards

Simon

[Karl Ylvisaker]

Hello Simon,

simon1516 said:

I added "DEBUG" in first line because it wasn´t there. Unfortunaly, I didn´t get messages in the debug terminal. If I press "build an debug" I went to the same error, but without any help in the debug window...

Good. When debug is defined you may proceed with debugging the code as you did earlier - enter debug mode, and see which function that leads to the APP_ERROR_FAULT_HANDLER function that you ended up in earlier. The difference now will be that the specific reason for ending up in the fault handler will be visible, so for instance it will say NRFX_ERROR_INTERNAL if an unexpected transition occurred on the bus during the transmission, for example. This will make it much easier to pinpoint the source of the error.

There will however be nothing in the debug terminal still - this is because the "Debug terminal" in Segger Embedded Studios really is an RTT terminal for the JLink to output logs. If your application does not use the RTT backend for its logging module, then nothing will show up in the debug terminal.

simon1516 said:

Could there be a problem, using nrf52833 instead of nrf52840?

There should not be a problem with this if you have changed the project configuration to match the nRF52833 DK instead of the nRF52840 DK.
Which changes did you make in this regards to the project I provided you earlier?

simon1516 said:

I set active build confifuration to "debug" instead of "release", but this doesn´t take affect. Is there something other I could try?

Since you defined DEBUG in the "common" configuration, it will be present for both DEBUG and RELEASE mode, so that should be all right.

simon1516 said:

Could there be a problem with my TWIM address? ICM20948 has 0x69 by default. So I assume that the TWIM functions RX and TX automatically set the LSB for Read/Write. Is that correct?

I suppose it could be. Did you get the address header file from the manufacturer directly, or did you transcribe / implement it yourself? I am just asking to make sure.
You are correct that the TWIM _DESC_TX and _DESC_RX macros sets the R/W bit for you. In this sense, you could read TX as "write" and RX as "read".

Best regards,
Karl

[simon1516]

Hi Karl,

Karl Ylvisaker said:

Good. When debug is defined you may proceed with debugging the code as you did earlier - enter debug mode, and see which function that leads to the APP_ERROR_FAULT_HANDLER function that you ended up in earlier. The difference now will be that the specific reason for ending up in the fault handler will be visible, so for instance it will say NRFX_ERROR_INTERNAL if an unexpected transition occurred on the bus during the transmission, for example. This will make it much easier to pinpoint the source of the error.

I need a little bit more help with that. I debugged again and I saw the following information:

I can see that the app_error_handler is called, and which parameters (err_code, line_number, file_name) are used for the call. But furthermore I can´t see a reason for my fault. Could you please tell me how to going on here? :-)

Karl Ylvisaker said:

There should not be a problem with this if you have changed the project configuration to match the nRF52833 DK instead of the nRF52840 DK.
Which changes did you make in this regards to the project I provided you earlier?

1.: Set Preprocessor definitions as shown in Screenshotn above - just change to the correct board and chip.

2.: Adjust the RAM and Flash sizes in Linker Options

The values for this I copied from an solution from this post:

https://devzone.nordicsemi.com/f/nordic-q-a/56802/change-softdevice-nrf52833

In general I use this values for making a project working for nrf52833, because in SDK there are many projects not available for PCA10100.

Karl Ylvisaker said:

I suppose it could be. Did you get the address header file from the manufacturer directly, or did you transcribe / implement it yourself? I am just asking to make sure.

I use the standard I2C adress from manufacturer for this sensor. There is a Pin, which can be used for configuring the I2C address - setting high for 0x69, low for 0x68. I use the 0x68. This is also the address which is found by "TWI Scanner Example".

Thanks in advance for your help!

Regards

Simon

[Karl Ylvisaker]

Hello Simon,

Sorry for my late reply.

simon1516 said:

I need a little bit more help with that. I debugged again and I saw the following information:

From this, it seems that your debug terminal is empty. Are you using UART or RTT backend for your logger?
If you are using UART logging, then you will need to make sure that NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED is set to 1 in your sdk_config file, and then you will need to take a look in your serial monitor to see the exact error.
If you are using RTT logging, then you will need to make sure that NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED is set to 0, to see the error in the debug terminal.

simon1516 said:

I use the standard I2C adress from manufacturer for this sensor. There is a Pin, which can be used for configuring the I2C address - setting high for 0x69, low for 0x68. I use the 0x68. This is also the address which is found by "TWI Scanner Example".

Good - then it seems there is nothing wrong with the hardware setup and addressing, at least.
So, I think we will need to dive into the error that is generated as mentioned above.

Looking forward to resolving this issue together!

Best regards,
Karl

[simon1516]

Hi Karl,

Thanks for Reply. I can now read the correct sensor data!!! :-)

______________________________________________

Karl Ylvisaker said:

If you are using RTT logging, then you will need to make sure that NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED is set to 0, to see the error in the debug terminal.

Now, I am able to see error Messages in the debug terminal! I got the following error:

<info> app_timer: RTC: initialized.
<error> app: ERROR 17 [NRF_ERROR_BUSY] at C:\Users\hp\Desktop\Firmware Entwicklung\nRF5SDK160098a08e2.zip\examples\ble_peripheral\ble_app_uart_with_twim v0.2\main.c:820
PC at: 0x00031395
<error> app: End of error report

Line 820 in main.c Shows the following:

   err_code = nrfx_twim_xfer(&m_twim, &lm75b_reading, NULL);
   APP_ERROR_CHECK(err_code);

______________________________________________

I didn´t understand this error completely, but I found an old thread, where the same error was issued by a timing/timout reason (https://devzone.nordicsemi.com/f/nordic-q-a/28483/twi---nrf_error_busy-with-nrf52832-and-s132)

Because of this, I added "nrf_delay_ms(50);" before every "err_code = nrfx_twim_xfer". An volia´it work´s. I can write to a Register and read Registers :-)

_____________________________________________

So far so good. But it doesn´t surprised, there are two other questions I would like to ask you.

1.: The general communication to the sensor works now. But after about three minutes, the application stopps with working. No sensor data is sended by the nRF52833. I send a single Byte to uart every 50ms. After three minutes, no more data is sent to uart terminal. Do I have a Chance, to enclouse this error?

2.: A few weeks ago, I deleted every nrf_delay_ms() function from my Code. The reasen: If I powered the board by a LiPo battery, the application didn´t work. Powering by USB works fine. I don´t know why, but deleting all nrf_delay_ms() functions from code fixed this behavior. Now I need this functions again - so what can I do here?

Thank you Karl for great support!

EDIT: To Point 1 - I started a debug session again. After about three minutes the application stopps. In debug terminal I can see a report "Logs dropped" many times.

Do you know, why this is Happening?

Kind regards

Simon