TWI don't work when BLE is running?

[zzzh]

Hi,

I'm using nrf52-pca10040 and sdk-15.3,  I tested an eeprom chip following twi_scanner example, using no block nrf_drv_twi_xfer way, which works well, then I put it in ble_app_uart  example with S112, neither ble nor eeprom can work.

I also tried the scheduler way, looks same.

Any ideas?

[zzzh]

I put it in debug mode and found something.

ERROR 4 [NRF_ERROR_NO_MEM] at

case APP_UART_COMMUNICATION_ERROR:
APP_ERROR_HANDLER(p_event->data.error_communication);
break;

I do use 260 bytes in global ram space as read and write buffer,  if this is the reason, where should I change to afford them?

Another question, I only used NRF_LOG_INFO in eeprom program, and the LOG backtend is RTT, not UART, why UART is complaining?

[Kenneth]

Seems you have included UART somewhere in your project, looks like the error here is:
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/uarte.html#register.ERRORSRC

FRAMING error, typically because you have enabled UART RX, and the pin is floating, e.g. not pulled high. You can pull it high using an external pull-up resistor if it's not in use. 

[zzzh]

Thank you, Kenneth.

FRAMING error make sense, but why it says ERROR 4 [NRF_ERROR_NO_MEM]? is this a bug?

[Kenneth]

I can't see from your code which api return NRF_ERROR_NO_MEM?

It may be because NRF_ERROR_NO_MEM by accident have the same numeric value (4) as FRAMING error:
#define NRF_ERROR_NO_MEM                      (NRF_ERROR_BASE_NUM + 4)  ///< No Memory for operation

Kenneth

[zzzh]

It's from uart_event_handle, which is the EVT_HANDLER in APP_UART_FIFO_INIT.

It would pass this issue if I put serial cable on, to make it easier, I commented uart_init and printf to make it easier, though there's another issue..

[zzzh]

To describe the next issue, I'll introduce how I do it first.

An eeprom test program usually write something then read it out to verify it's working correctly, so is my code.

The eeprom chip I'm using only support write/read in 1 page once, so, to write/read data larger than one or more page size (128 bytes in this case), have to do it in multiple parts, when there's no BLE, that's easy:

1. divide the task to multiple parts

2. when the first part is executing, waiting for the interrupt to tell you it's finished, I put a signal in interrupt code called eep_busy, so when eep_busy is 0, stop waiting and do next part

3. in interrupt code, I also do some printing to show the result, if it's a read, there can be a lot of printing, to make it simple, I set eep_busy to 0 after after printing for the part is done, 

When there's BLE, put printing in interrupt looks bad, so have to do it in scheduler way, that is, put the printing part in scheduler to run in main loop.

The next issue is, it's always waitting for the eep_busy to continue, which is in main loop, while my test code is before main loop. so it stuck before the main loop run. ( I tried to clear eep_busy in interrupt, but it will stuck at waitting for it at last ( don't know why ), and in this way, print the data in time is impossible)

So, how to arrange them to run in scheduler way?

[zzzh]

I realized that a write cycle would need 5ms, that's why clear eep_busy in interrupt would not work, the printing must take more than 5ms, that's why clear eep_busy after printing works well.