Sending I2S data via BLE using queue

RE: Sending I2S data via BLE using queue

Kazi Afroza Sultana — Tue, 09 Aug 2022 08:00:51 GMT

Hello,

You are welcome. Yes, You can open new case.

Thanks.

Best Regards,

Kazi Afroza Sultana

RE: Sending I2S data via BLE using queue

Moritz_S — Thu, 28 Jul 2022 12:59:22 GMT

Hi Kazi,

thank you for the reply and your offer about looking at my project. I have solved the problem which is stated above. The problem was

NRF_QUEUE_DEF(uint8_t, m_queue, 3072, NRF_QUEUE_MODE_OVERFLOW);

It seems the buffer was full very often and appending partially new data, but not all of them (i.e. dropping one part of the data, while keeping another part) led to corrupted data. Changing it to NRF_QUEUE_MODE_NO_OVERFLOW improved the program a lot. Finally, I realized that

#define I2S_DATA_BLOCK_WORDS    256

also has an influence on how fast the buffer gets filled up. In between I was using I2S_DATA_BLOCK_WORDS 1024, which led to the buffer being full all the time. Currently, I'm at 64, but I'm still experimenting which setting is the best.

In the meantime I'm facing a new issue. Now my data handler is not called as often as it should be. This leads to ending up with significantly less samples as I'm expecting. But I guess I will open another thread regarding this after my holiday and link the question here. I will also close this thread then!

Thanks a lot for your support!

RE: Sending I2S data via BLE using queue

Kazi Afroza Sultana — Fri, 15 Jul 2022 08:49:06 GMT

Hello Moritz,

Yes, You can send your full project so that we can look at.

Since it is summer vacation, it may take a bit time to reply. I will be in vacation for next 2 week. Sorry for this inconvenience.

Thanks.

Best Regards,

Kazi Afroza Sultana

RE: Sending I2S data via BLE using queue

Moritz_S — Wed, 06 Jul 2022 09:16:17 GMT

Hi, thank you for your response.

1. this is solved. I used nrf_drv_i2s_start() similarly to the i2s example, but since i do continuous i2s transfer (without stopping the i2s at the end of each loop), I cannot call nrf_drv_i2s_start() at the beginning of each loop (which I did initially). this problem is solved now.

2. also solved now.

3. mp_block_to check is declared as

static uint32_t const * volatile mp_block_to_check = NULL;

in your i2s example. I used it in exactly the same way as in the example.

4. Thank you, I will keep the activity in the data handler as low as possible.

There is no error related to mp_block_to_check or the data_handler. This was a general question: Imagine I have a loop that iterates over an array of data and while I'm doing that, the i2s interrupt calls the data_handler() which is writing to that array. In that case, the data in the array would be overwritten by the data_handler() even if my loop is still iterating over the array?

In fact my code is executed without errors now. Now, I'm facing the problem that the data I'm expecting is not received correctly. Could be a hardware issue or caused by the data_handler overwriting the data in mp_block_to_check. Hence, my question above. If you want, I can share my project, so you get a better understanding?

Regards

Moritz

RE: Sending I2S data via BLE using queue

Kazi Afroza Sultana — Tue, 05 Jul 2022 13:35:21 GMT

Hello,

1. Within the endless loop in my main function, i2s_start() will be called in every iteration, which could already be enough reason to cause the application to crash.

Have you looked at the I2S example in the SDK? Could you please tell us how your start_i2s() function works. It may be something similar to the nrf_drv_is2_start () used in the main loop of that i2s example. What does the return of this function, anything other than NRF_SUCCESS ?

2. nrf_queue_read will return NRF_ERROR_NOT_FOUND the first time it is called, since there is no data available yet. This needs to be handled.

As you said there is no data so nrf_queue_read() function can return an error. We do not have this function in I2S example, so this is something you have to handle yourself.

3. in my data_handler() I access the volatile pointer mp_block_to_check without assigning any value to it. I missed 'mp_block_to_check = p_released->p_rx_buffer;', like it is also done in the i2s example of the SDK.

what is this pointer mp_block_to_check and what is the use of it? We do not have something in I2S example.

4. This is rather a question to you Kazi Afroza Sultana : If I understood correctly, the data_handler is called by the i2s driver when new data is available. So, if I have a loop in the data_handler (like in the one I have above), blocking the data_handler, could this cause trouble the next time the i2s driver calls the data handler? I assumed, yes, and removed any unnecessary code from the data handler.

Inside the data handler, when you are blocking new interrupts, you should spend as little time as possible inside the handler. The factors impact here are the size of buffers and the time it would take it to fill up an trigger a new interrupt.

And, another question: when the data_handler writes new data to mp_block_to_check, it overwrites all the data in the variable, even if I'm still processing parts of that data, correct?

Could you please tell a bit details about this error?

Thanks.

Best Regards,

Kazi Afroza Sultana

RE: Sending I2S data via BLE using queue

Moritz_S — Sat, 25 Jun 2022 12:20:39 GMT

Hi,

thanks for the link. I wasn't aware of this article. However, I'm using the the Debug build configuration from the beginning. After reading the article, I also defined the DEBUG flag in the project options (in the common build configuration -> Preprocessor -> Preprocessor Definitions). However, this did not result in any error being printed to the debug console of SES. Also my NRF_LOG_INFO and NRF_LOG_DEBUG were not printed (at least most of them). Even if this is not the topic of this post, I would like to understand why (NRF_LOG_BACKEND_RTT_ENABLED is set to 1 in sdk_config.h)?

Back to programming: There were multiple errors in the code I posted above. I will highlight the main ones for anybody else who will read this post.

1. Within the endless loop in my main function, i2s_start() will be called in every iteration, which could already be enough reason to cause the application to crash.

2. nrf_queue_read will return NRF_ERROR_NOT_FOUND the first time it is called, since there is no data available yet. This needs to be handled.

And, another question: when the data_handler writes new data to mp_block_to_check, it overwrites all the data in the variable, even if I'm still processing parts of that data, correct?

Many questions, I hope I have expressed myself clear enough. If not, let me know 🙂

RE: Sending I2S data via BLE using queue

Kazi Afroza Sultana — Tue, 21 Jun 2022 08:26:31 GMT

Hello,

You an look at this blog post (+) An introduction to error handling in nRF5 projects - Blogs - Nordic Blog - Nordic DevZone (nordicsemi.com) . It is a bit old but still relevant for debugging on segger.

You said that you application causes the application to run into an error while all 4 LEDs on your nRf52 DK are on. So, I guess APP_ERROR_CHECK() has been called with an error code. You should make sure you do a debug build (most SES example projects lets you select ''Debug'' from the build target from drop down menue. Then if you use logging, the log should state which error code was detected in which file at which line. From that point you know, were you should look further. If you do not use logging you can put a breakpoint in the error handler and check with a debugger.

Thanks.

Best Regars,

Kazi Afroza Sultana

RE: Sending I2S data via BLE using queue

Moritz_S — Thu, 16 Jun 2022 06:46:11 GMT

Hi,

I found the option to Build -> Show Build Log in Segger emStudio. I'm posting the content of the log below. Is that what you were asking for? Did you also see my update below? Could you provide any hints how to solve this?

Building 'ble_app_template_pca10040_s132' from solution 'ble_app_template_pca10040_s132' in configuration 'Debug'
1> Assembling 'thumb_crt0.s'
2> Compiling 'nrf_log_backend_rtt.c'
1> Compiling 'nrf_log_backend_serial.c'
1> Compiling 'nrf_log_backend_uart.c'
2> Compiling 'nrf_log_default_backends.c'
2> Compiling 'nrf_log_frontend.c'
1> Compiling 'nrf_log_str_formatter.c'
1> Compiling 'app_button.c'
2> Compiling 'app_error.c'
1> Compiling 'app_error_handler_gcc.c'
2> Compiling 'app_error_weak.c'
1> Compiling 'app_scheduler.c'
1> Compiling 'app_timer2.c'
1> Compiling 'app_util_platform.c'
2> Compiling 'crc16.c'
1> Compiling 'drv_rtc.c'
1> Compiling 'fds.c'
2> Compiling 'hardfault_implementation.c'
1> Compiling 'nrf_assert.c'
2> Compiling 'nrf_atfifo.c'
2> Compiling 'nrf_atflags.c'
2> Compiling 'nrf_atomic.c'
2> Compiling 'nrf_balloc.c'
1> Compiling 'nrf_fprintf.c'
2> Compiling 'nrf_fprintf_format.c'
2> Compiling 'nrf_fstorage.c'
2> Compiling 'nrf_fstorage_sd.c'
1> Compiling 'nrf_memobj.c'
1> Compiling 'nrf_pwr_mgmt.c'
1> Compiling 'nrf_ringbuf.c'
1> Compiling 'nrf_section_iter.c'
2> Compiling 'nrf_sortlist.c'
1> Compiling 'nrf_strerror.c'
2> Compiling 'sensorsim.c'
2> Compiling 'nrf_queue.c'
2> Assembling 'ses_startup_nrf52.s'
2> Assembling 'ses_startup_nrf_common.s'
1> Compiling 'system_nrf52.c'
2> Compiling 'boards.c'
1> Compiling 'nrf_drv_clock.c'
2> Compiling 'nrf_drv_uart.c'
2> Compiling 'nrfx_atomic.c'
1> Compiling 'nrfx_clock.c'
2> Compiling 'nrfx_gpiote.c'
1> Compiling 'nrfx_prs.c'
1> Compiling 'nrfx_uart.c'
1> Compiling 'nrfx_uarte.c'
1> Compiling 'nrfx_i2s.c'
2> Compiling 'nrfx_twi.c'
1> Compiling 'nrf_drv_twi.c'
2> Compiling 'bsp.c'
2> Compiling 'bsp_btn_ble.c'
1> Compiling 'main.c'
1> /home/engineer/nRF-Dev/nRF5_SDK_17.1.0_ddde560/examples/ble_peripheral/surag_sense/main.c: In function ‘notification_timeout_handler’:
1> /home/engineer/nRF-Dev/nRF5_SDK_17.1.0_ddde560/examples/ble_peripheral/surag_sense/main.c:266:45: warning: passing argument 2 of ‘ble_aas_value_update’ from incompatible pointer type [-Wincompatible-pointer-types]
1> In file included from /home/engineer/nRF-Dev/nRF5_SDK_17.1.0_ddde560/examples/ble_peripheral/surag_sense/main.c:94:
1> ./ble_aas.h:99:60: note: expected ‘uint8_t *’ {aka ‘unsigned char *’} but argument is of type ‘uint8_t (*)[244]’ {aka ‘unsigned char (*)[244]’}
1> /home/engineer/nRF-Dev/nRF5_SDK_17.1.0_ddde560/examples/ble_peripheral/surag_sense/main.c: In function ‘main’:
1> /home/engineer/nRF-Dev/nRF5_SDK_17.1.0_ddde560/examples/ble_peripheral/surag_sense/main.c:1067:53: warning: passing argument 2 of ‘ble_aas_value_update’ from incompatible pointer type [-Wincompatible-pointer-types]
1> In file included from /home/engineer/nRF-Dev/nRF5_SDK_17.1.0_ddde560/examples/ble_peripheral/surag_sense/main.c:94:
1> ./ble_aas.h:99:60: note: expected ‘uint8_t *’ {aka ‘unsigned char *’} but argument is of type ‘uint8_t (*)[244]’ {aka ‘unsigned char (*)[244]’}
1> Compiling 'ble_aas.c'
1> /home/engineer/nRF-Dev/nRF5_SDK_17.1.0_ddde560/examples/ble_peripheral/surag_sense/pca10040/s132/ses/ble_aas.c: In function ‘on_write’:
1> /home/engineer/nRF-Dev/nRF5_SDK_17.1.0_ddde560/examples/ble_peripheral/surag_sense/pca10040/s132/ses/ble_aas.c:134:43: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
1> Compiling 'utils.c'
2> Compiling 'SEGGER_RTT.c'
1> Compiling 'SEGGER_RTT_Syscalls_SES.c'
2> Compiling 'SEGGER_RTT_printf.c'
1> Compiling 'auth_status_tracker.c'
1> Compiling 'ble_advdata.c'
2> Compiling 'ble_advertising.c'
2> Compiling 'ble_conn_params.c'
1> Compiling 'ble_conn_state.c'
2> Compiling 'ble_srv_common.c'
2> Compiling 'gatt_cache_manager.c'
2> Compiling 'gatts_cache_manager.c'
2> Compiling 'id_manager.c'
1> Compiling 'nrf_ble_gatt.c'
1> Compiling 'nrf_ble_qwr.c'
1> Compiling 'peer_data_storage.c'
1> Compiling 'peer_database.c'
2> Compiling 'peer_id.c'
2> Compiling 'peer_manager.c'
2> Compiling 'peer_manager_handler.c'
1> Compiling 'pm_buffer.c'
1> Compiling 'security_dispatcher.c'
1> Compiling 'security_manager.c'
2> Compiling 'utf.c'
1> Compiling 'nrf_sdh.c'
1> Compiling 'nrf_sdh_ble.c'
2> Compiling 'nrf_sdh_soc.c'
1> Generating linker script 'ble_app_template_pca10040_s132.ld'
1> Linking ble_app_template_pca10040_s132.elf
Build complete

RE: Sending I2S data via BLE using queue

Moritz_S — Mon, 13 Jun 2022 09:07:41 GMT

Hi Kazi, thank you for your reply. I'm quite new to Segger emStudio and programming the nRF - is there a tutorial on how to debug into the preprocessor symbols and where can I access the proprocessor logs? I didn't find any information about that on the internet.

For clarification: the nRF is advertising and I can connect to it. The problem starts when I enable notifications and the code, thereby, enters the if-clause in line 46 in my main function (i2s_transfer becomes true).

RE: Sending I2S data via BLE using queue

Kazi Afroza Sultana — Fri, 10 Jun 2022 12:19:35 GMT

Hello,

Could you please debug into the preprocessor symbols and check the log to see where the error is? You can send the log to us.

Thanks.

Best Regards,

Kazi Afroza Sultana

RE: Sending I2S data via BLE using queue

Kazi Afroza Sultana — Fri, 10 Jun 2022 08:03:54 GMT

Hello,

I have been looking at your case. I will get back to you later.

Thanks.

Best Regards,

Kazi Afroza Sultana