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,

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

[Karl Ylvisaker]

Hello Simon,

simon1516 said:

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

No problem at all, I am happy to hear that you now are able to read the correct sensor data! :) 

simon1516 said:

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

Great! This makes debugging a lot easier, when you get the error pinpointed.

simon1516 said:

I didn´t understand this error completely, but I found an old thread, where the same error was issued by a timing/timout reason

Now that you know which function that returned the error, and what error is generated then you can take a look in the API Reference for the function to find out what caused it.
For your example, it is the nrfx_twim_xfer function returned with NRF_ERROR_BUSY. Looking at the API Reference, we see that this error is returned when "The driver is not ready for a new transfer.", so indeed there seems to be a timing issue. Perhaps a new transfer is being queued at line 820 before the previous one is finished.

simon1516 said:

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 :-)

I am glad to hear that you were able to read and write the registers now!
However, I think we should be able to reduce that delay quite a bit - 50 ms is a lot of time to waste every time you are making a single byte transfer over TWIM.
Firstly, perhaps you could try to reduce the necessary delay - or add another condition that would ensure that the previous transfer is finished?
For example, the flag you are currently clearing in the event handler, perhaps that instead should start a timer that expires after a certain time, which allows the next transfer to proceed?
This will free up the CPU to do other tasks ( or sleep ) for the transfer wait period.

simon1516 said:

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?

simon1516 said:

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.

Where does the application stop after three minutes, is it a particular place in the code?
Or, is it another error being generated?
The logs dropped means the logger modules buffer is full. Are you using deferred logging? And if so, when are you processing these logs? If not, what is the size of your loggers buffer?

simon1516 said:

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?

What do you mean when you say "didnt work"?
Please see my above recommendation to avoid the nrf_delay call. In general, adding NOP cycles ( like nrf_delay ) is not a good practice to meet timing requirements. A much better solution would be a standalone timer, or basing it on some other event entirely.

simon1516 said:

Thank you Karl for great support!

Thank you for the kind words, I am happy to help!

Best regards,
Karl

[simon1516]

Hi Karl,

Karl Ylvisaker said:

For example, the flag you are currently clearing in the event handler, perhaps that instead should start a timer that expires after a certain time, which allows the next transfer to proceed?
This will free up the CPU to do other tasks ( or sleep ) for the transfer wait period.

Could you guide me how to use such a timer? I defined "#define TWIM_transmission_time APP_TIMER_TICKS(10) " to get a timer with 10ms delay time. So now, I would like to use this timer in my "twim_handler". Nothing should happen, if the timer isn´t expired. The timer should restart, if it is expired and an twim event was done. Could you give me a small Syntax for this?

I have already included "app_timer.h", so I think it would make sense to use this.

Karl Ylvisaker said:

Are you using deferred logging?

Could you tell me, how to get this Information?

Karl Ylvisaker said:

What do you mean when you say "didnt work"?

Here I think I have to debug again (because debugging is working now :-) ). I will try this and give you a short Feedback the next days!

Thanks in advance

Simon

[Karl Ylvisaker]

Hello again Simon,

simon1516 said:

Could you guide me how to use such a timer? I defined "#define TWIM_transmission_time APP_TIMER_TICKS(10) " to get a timer with 10ms delay time. So now, I would like to use this timer in my "twim_handler". Nothing should happen, if the timer isn´t expired. The timer should restart, if it is expired and an twim event was done. Could you give me a small Syntax for this?

I have already included "app_timer.h", so I think it would make sense to use this.

Yes, it would be easiest to use the app_timer to create and manage the timer.
However, could you first try to see what the required delay is, by using nrf_delay?
It might be that your TWI slave requires some delay between transfer.

It is slightly more work to implement the solution without wasted CPU cycles. Could you detail for me what transfers you will make - how frequent are they, and how many bytes are in each transfer?
If you are only doing pairs of two and two bytes ( R/W commands ) then you could perhaps solve this by using the DESC_TXTX and DESC_TXRX, for example. It would mean a lot less work to use the already implemented features of the TWIM driver, so lets look at that first if possible, or depending on your specification we might use the NRFX_TWIM_FLAG_HOLD_XFER feature instead.

simon1516 said:

Could you tell me, how to get this Information?

Yes, please check your sdk_config file, to see if the NRF_LOG_DEFERRED is defined as 1 or 0, and if it is 1, what is then the size of NRF_LOG_BUFSIZE? 

simon1516 said:

Here I think I have to debug again (because debugging is working now :-) ). I will try this and give you a short Feedback the next days!

Great, that sounds like a good plan - I look forward to hearing your findings!

Best regards,
Karl

[simon1516]

Hi Karl,

here I am again with new findings.

_______________________________________________________

Karl Ylvisaker said:

However, could you first try to see what the required delay is, by using nrf_delay?
It might be that your TWI slave requires some delay between transfer.

It seems so. I measured a few write/read procedures with different timing parameters. The result:

I have to implement at least the following:

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

 nrf_delay_us(500);

BEFORE and AFTER my read process a delay of 500us. If I reduce the number of us more, the read process didn´t work correctly (I checked this with printing the values by uart and I could see that the transmission didn´t work with lower timing). Could you maybe give me a syntax for replacing this with app_timer ?

___________________________________________________________

Karl Ylvisaker said:

Could you detail for me what transfers you will make - how frequent are they, and how many bytes are in each transfer?

- I would like to read 14 bytes each transfer (https://invensense.tdk.com/wp-content/uploads/2016/06/DS-000189-ICM-20948-v1.3.pdf chapteer 7.1, register "2D" to "3A"). Accelerometer-Value X, Y, Z (each 2 bytes), Gyroscope-Value X, Y, Z (each 2 bytes) and Temperatur-Value (2 bytes). So in sum 14 bytes.

- I would like to read the 14 bytes every 10ms. This frequency should be changeable.

____________________________________________________________

Karl Ylvisaker said:

Yes, please check your sdk_config file, to see if the NRF_LOG_DEFERRED is defined as 1 or 0, and if it is 1, what is then the size of NRF_LOG_BUFSIZE? 

NRF_LOG_DEFERRED is "1" and NRF_LOG_BUFSIZE is "1024".

Do I have the option to deactivate this log-deferring? I am not really sure if I need it.

_______________________________________________________________

Karl Ylvisaker said:

Where does the application stop after three minutes, is it a particular place in the code?

In debug terminal I just can see the message "Logs dropped ()" as described above. There is no line number printed out to see where the error happened. Here a screenshot from the error:

Thank you for helping us with our product development :-)

Kind regards

Simon