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

[simon1516]

Hi Karl,

Karl Ylvisaker said:

You can see the different power consumption scenarios here.

Thanks for this. So it make sense, setting CPU in sleep mode. I will try it :-)

_____________________________________________________________

My timers are working now, I get it! :-) In my case I call two times "nrfx_twim_xfer" in one read procedure. Because of that, I have declared two timers now. I had to split my read function in two parts (because a timer can just call one function after expiration).

First timer: Repeatet, because I would like to send data in an special time intervall.

Second timer: NOT repeatet; If First timer expired, second timer start´s - because of TWIM needs this time for processing well.

In my case, first timer 1000ms,second timer 10ms. I try to reduce this the next days, we´ll see how much works.

_____________________________________________________________

Karl Ylvisaker said:

Taking a quick look through your project I have the following questions:
- what is the b_Battery_Pin define for?
- all your "regX" variables should have proper names. I.e READ_XXX, or CTRL_XXX. You could also have a separate header file that defines all the possible commands for the sensor, which makes them easy to invoke. This increases readability and reduces that chance of mistyping a command / reading the wrong register.
- your "my_timer_id" timer is set to be in REPEATED mode, I do not know if this is intentional? As I understood it you would just like to start the timer in between each transfer, to ensure that enough time passes for the device to be ready for the next transfer, was it not so? With the current REPEATED timer, triggering read_sensor_data you still rely on nrf_delay_ms in between your transfers.

- b_Battery_Pin was just for testing - setting a Pin high from the nrf52833 to high. Our custom board includes a battery management chip - this Pin high shall activate/enable the IC on the board.

- Yes, this is a good point. I have to do that. But making code better to read, doesn´t make fun :-) Please give me a few days for that.

- You´re right. But in each transfer I start a timer. But I need a second timer, to start the transfer. Because of that, I implemented two timers for this.

_____________________________________________________________

I try to implement the idle_state_handler the next days for better battery life. I haven´t done it yet, but I will give you a feedback here soon.

Thank you and kind regards

Simon

[Karl Ylvisaker]

Hello Simon,

simon1516 said:

Thanks for this. So it make sense, setting CPU in sleep mode. I will try it :-)

Great, I am happy to hear that you found the reference helpful! :) 

simon1516 said:

My timers are working now, I get it! :-) In my case I call two times "nrfx_twim_xfer" in one read procedure. Because of that, I have declared two timers now. I had to split my read function in two parts (because a timer can just call one function after expiration).

Its working, great!
I am not sure I have completely understood the usage of the TWIM transfers here then.
After initialization of the sensor, what else than reading the sensor data do you do?

Regarding that last part, have you looked at the possibility to use the _TXRX DESC type? It sets up two transfers, one write and one read. Alternatively, if you are always doing the same read/write operation periodically, you could use the NRFX_TWIM_FLAG_REPEATED_XFER flag for the nrfx_twim_xfer. This way, you can queue a lot of these transfers to happen periodically.

simon1516 said:

- b_Battery_Pin was just for testing - setting a Pin high from the nrf52833 to high. Our custom board includes a battery management chip - this Pin high shall activate/enable the IC on the board.

That sounds great, thank you for clarifying this.

simon1516 said:

- Yes, this is a good point. I have to do that. But making code better to read, doesn´t make fun :-) Please give me a few days for that.

He-he yes, I totally get what you are saying here!
I am happy to hear that you might be taking this suggestion to heart :)

simon1516 said:

- You´re right. But in each transfer I start a timer. But I need a second timer, to start the transfer. Because of that, I implemented two timers for this.

I am not sure that I see the need for a second timer here, as I have understood your setup.
But, if it is working as intended and you are happy with the results then do not worry at all about my understanding of it.

simon1516 said:

I try to implement the idle_state_handler the next days for better battery life. I haven´t done it yet, but I will give you a feedback here soon.

You already have the idle_state_handler implemented in your project - it came with the example you started out from. Just search for idle_state_handler in your main.c and you will see!
All you need to do is call it, for example in the main loop.

Looking forward to hearing your thoughts on using the nrfx_twim_xfer flags I mentioned above!

Best regards,
Karl 

[simon1516]

Hi Karl,

Karl Ylvisaker said:

After initialization of the sensor, what else than reading the sensor data do you do?

Nothing. I just want to collect the sensor data and transmitt them by BLE. Nothing else.

Karl Ylvisaker said:

Regarding that last part, have you looked at the possibility to use the _TXRX DESC type? It sets up two transfers, one write and one read. Alternatively, if you are always doing the same read/write operation periodically, you could use the NRFX_TWIM_FLAG_REPEATED_XFER flag for the nrfx_twim_xfer. This way, you can queue a lot of these transfers to happen periodically.

Is it okay notice this for later? I´m happy that the main things are working now. I´m sure that both things are making sense :-)

Karl Ylvisaker said:

You already have the idle_state_handler implemented in your project - it came with the example you started out from. Just search for idle_state_handler in your main.c and you will see!

I just added the call "idle_state_handle()" in my main loop. I´m excited to see the impact to the current consumptation. I wasn´t able to measure this yet.

Unfortunaly I have another problem with my connection: If I rebuild/repower the Dev. board I can see the application in nRF connect as BLE device - as it should be. But if I wait a short time, sometimes 20s, sometings 30s, the device can´t be found furthermore. The same if I connect to the device and then disconnect - I can´t found the device furthermore.

I think this is because of the TWIM transfer - so many transfers (every 10 or 20ms) to read from the sensor, print over uart and send ober BLE...is the application able to advertise, allthough the CPU has to do such many tasks? I seems not. So my question here: Is there a variable I can use to indicate if the TWIM shall work or not?

If variable (BLE device connected)

then TWIM transfer

endif

Then the CPU can take it´s time for advertising because there are no other tasks to do.

Thanks for helping me with all my problems!

Kind regards

Simon

[Karl Ylvisaker]

Hello Simon,

simon1516 said:

Is it okay notice this for later? I´m happy that the main things are working now. I´m sure that both things are making sense :-)

Absolutely, you can jot this down for later, as a possible optimization of your application. It is great to hear that you are happy with how things are working currently!
In short, you might optimize this application by using the REPEATED_XFER flag with the nrfx_twim_xfer. This will make it so that a given transfer happens every so often.
You may then set it up so that your peripheral does not transmit the value if there has not been a significant change ( I do not know exactly what you are measuring and / or how fast it will fluctuate ) but you may do this by setting slave latency in your connection parameters. This can also save you a lot of power.

simon1516 said:

I just added the call "idle_state_handle()" in my main loop. I´m excited to see the impact to the current consumptation. I wasn´t able to measure this yet.

Great, I look forward to hearing the results!

simon1516 said:

Unfortunaly I have another problem with my connection: If I rebuild/repower the Dev. board I can see the application in nRF connect as BLE device - as it should be. But if I wait a short time, sometimes 20s, sometings 30s, the device can´t be found furthermore. The same if I connect to the device and then disconnect - I can´t found the device furthermore.

Hm, this sounds like the device is not advertising anymore.
What is your advertising parameters? Have you set a timeout for the advertisement?

simon1516 said:

I think this is because of the TWIM transfer - so many transfers (every 10 or 20ms) to read from the sensor, print over uart and send ober BLE...is the application able to advertise, allthough the CPU has to do such many tasks? I seems not. So my question here: Is there a variable I can use to indicate if the TWIM shall work or not?

Yes, you do not need to worry that the CPU will not be able to fulfill the SoftDevice requirements. As mentioned earlier, the SoftDevice takes priority over any application layer task, which means that when the SoftDevice needs the CPU for time-critical tasks it will take it, no matter what the application is doing.
So, it is actually the other way around which you will need to think about - how will your application behave if interrupted during a certain operation - this is important to take into account when developing the application.
You can create a variable to stop reading / trying to send the TWI transfers when you are in a connection or not - this is probably wise, since there is no use in collecting the sensor data if you can not send it to anyone ( if you are not buffering it ).
So, you can add such a variable to the ble_evt_handler in the CONNECTED and DISCONNECTED events, for instance.

simon1516 said:

Thanks for helping me with all my problems!

It is no problem at all, Simon!

Best regards,
Karl 

[simon1516]

Hi Karl,

here I am again :-)

The last days I optimized the application (finding the best timing/timer parameters, making the code better to read, delete all "nrf_delay" functions from code, ...) and I think we have a good running solution now.

Karl Ylvisaker said:

So, you can add such a variable to the ble_evt_handler in the CONNECTED and DISCONNECTED events, for instance.

I exactly done it like this. So, now the TWIM prodecure starts with BLE event connected and stops with BLE event disconnected. Thats fine.

I have another question and hope you can help me with that, too. We would like to monitor battery state. We use a single cell, connected to VDDH with an input range of the battery of 2,5V - 4,2V.

- First I would like make sure, that this is possible without any external hardware. VDDH is divided by 5 by default, so I think there is a voltage divider already there (it is called as "VDDHDIV5", https://infocenter.nordicsemi.com/pdf/nRF52833_PS_v1.3.pdf p. 359). Could you confirm this?

- I have already build the SAADC example. For ADC input channel i used VDD and VDDH for testing the result. In case of VDD (1,8V), I get an output of about decimal 500. In case of VDDH (battery, 4,05V in this test) I get an output of about decimal 1150. This makes sense, because 4,05/1150 is approximately the same like 1,8/500. So I´m measuring good values :-) My question here: In example I just can see, that default setting for SAADC are used (for nrf_drv_saadc_init). How can I see the values for resolution, oversample and so on?)

- and last question: In case of battery voltage is less than 2,5V (adjustable), than the battery should not be used furthermore because of security reasons. The Chip should power down than. In case of the battery is charged enough, the application should be working again. The chip should be waking up automatically, allthough the chip isn´t powered to this time. Is this possible? 

Best regards

Simon

[Karl Ylvisaker]

Hello Simon,

simon1516 said:

The last days I optimized the application (finding the best timing/timer parameters, making the code better to read, delete all "nrf_delay" functions from code, ...) and I think we have a good running solution now.

I am happy to hear that you now have a good solution running! :) 

simon1516 said:

I exactly done it like this. So, now the TWIM prodecure starts with BLE event connected and stops with BLE event disconnected. Thats fine.

This is a good way of handling it, very well.

simon1516 said:

I have another question and hope you can help me with that, too.

If you have more questions that diverge from your original ticket, I would ask that you create a separate ticket for that. If you would like for me to help you specifically - for example if the question is somehow related to a previous ticket, or requires insight into a project that I already know -  then you may tag me in the new ticket, or ask for me to handle it specifically. I can not guarantee that I will be assigned to it, but it will be a lot more probable.
The reason why I ask you to create a new ticket for new questions is to keep the forum tidy, and easy to navigate for other users.

With that said, I will finish answering the questions you asked in your previous comment:

simon1516 said:

First I would like make sure, that this is possible without any external hardware. VDDH is divided by 5 by default, so I think there is a voltage divider already there (it is called as "VDDHDIV5", https://infocenter.nordicsemi.com/pdf/nRF52833_PS_v1.3.pdf p. 359). Could you confirm this?

Yes, I can confirm that the SAADC may measure the VDDH pin without external hardware. The voltage is here divided by 5, since the potential input to the VDDH might exceed the nRF52833's absolute maximum electrical ratings. 
You can read more about this in the nRF52833 SAADC documentation.

simon1516 said:

For ADC input channel i used VDD and VDDH for testing the result. In case of VDD (1,8V), I get an output of about decimal 500. In case of VDDH (battery, 4,05V in this test) I get an output of about decimal 1150. This makes sense, because 4,05/1150 is approximately the same like 1,8/500. So I´m measuring good values :-)

I can not say anything about these values you are seeing, since I do not know how you have configured you channels, etc.

simon1516 said:

My question here: In example I just can see, that default setting for SAADC are used (for nrf_drv_saadc_init). How can I see the values for resolution, oversample and so on?)

These default values are defined in the sdk_config file. You may jump to these values quickly in Segger Embeded Studios by right clicking them, and selecting "go to definition" at the top, this will take you directly to their definition in the sdk_config.
Please note that channel configuration matters just as much as SAADC configuration, and you will have to have an acquisition time of >= 10 ms for the VDDH channel, as per the SAADC documentation.

simon1516 said:

In case of battery voltage is less than 2,5V (adjustable), than the battery should not be used furthermore because of security reasons.

Do you here mean safety reasons?
Dead Li-Po cells is a safety hazard, if they are allowed to deeply discharge. I suspect that this is what you meant, but I emphasize this regardless, due to its importance.

simon1516 said:

In case of the battery is charged enough, the application should be working again. The chip should be waking up automatically, allthough the chip isn´t powered to this time. Is this possible? 

The SAADC will give you good ballpark estimates of the remaining battery, but it is not pinpoint accurate. If you require high accuracy readings of the state of charge / health of the battery, I would suggest looking into adding a Low Power fuel gauge IC to your project.
That being said, the SAADC gives good enough readings for most use-cases of battery readings ( but this also depends on what else your device will be doing at the time ).

Without external circuitry there is not way for the chip to wake up automatically when it is above a certain charge level - if it is to do these measurements itself, it will also have to wake up to discover that it has gone below its limits.
So, in short; No, if the nRF is doing its own battery voltage readings - and is using those readings to determine if it has within the operating levels - it is no way for it to avoid waking up to check the level when it is outside those limits.
You may however set this limit higher than its absolute limit, so that you may know when you are approaching it, and act accordingly.
I recommend reading this ticket, for more information about noise during SAADC measuring.

Best regards,
Karl

[simon1516]

Hi Karl,

Karl Ylvisaker said:

The reason why I ask you to create a new ticket for new questions is to keep the forum tidy, and easy to navigate for other users.

Yes, you´re right. So because of my Questions are answered well we can close this thread.

I say thank you for your great support regarding our nrf52833 product development.

[Karl Ylvisaker]

Hello Simon,

simon1516 said:

Yes, you´re right. So because of my Questions are answered well we can close this thread.

Great, please do not hesitate to open a new ticket if you should encounter any issues or questions in the future!

simon1516 said:

I say thank you for your great support regarding our nrf52833 product development.

I am glad to hear you say that Simon, thank you!
It is no problem at all, I am happy to help.

Good luck with your development!

Best regards,
Karl