This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Unable to receive UART response when combined the NUS example with custom service central example

Hi,

I am using a central example to scan the peripheral and connects to it. I get data through notifications in bulk. That works fine. Then in order to add support to FONA808 module, I need to have UART communication which I have established using NUS peripheral example (because that uses UART). Both of the examples work fine when I use them separately.

Now when I have combined NUS code (without use of peripheral) inside the central example, I first got into problem of NO_MEMORY(err_code=0x04) issue because I was adding 2 services (Custom & NUS). I just can live without custom service on central so I just commented that out and now I don't have that issue. I am just having NUS(1) service in my code (although I also don't need it).

However, the problem in this combined code is that:

NUS service is added successfully, UART is initiated successfully, pins assignment is same as in working NUS example, data bits are transmitted serially through the following code:

for(int i=0;i<strlen(AT_cmd);i++)		
{
    while(app_uart_put(AT_cmd[i]) != NRF_SUCCESS);
}

Since this code does not halt inside the while loop, so (I am assuming that)  the data bits are being transferred successfully (please correct me if I am wrong, do I need to see that on oscilloscope?).

But after this, I am expecting response from FONA808 which I never receive and I am stuck in loop waiting for the response forever.

Just to mention again that FONA808 works fine with NUS-standalone code (when not mixed with central code), so I am sure FONA808 module is working fine and the Tx/Rx pins are the same in the combined code.

Can anyone think of possible reasons for this problem? I will be obliged if someone can give me a hint to debug why the serial communication not working well in my situation.

Thanks

Parents
  • I just want to add that I get the following on my log:

    0> RAM START ADDR 0x200025E0 should be adjusted to 0x20002418
    0> RAM SIZE should be adjusted to 0xDBE8 
    0> sd_ble_enable: RAM START at 0x200025E0
    

    Currently the RAM start address is set at 0x200025E0.

    If I set the RAM Start address to be 0x20002418 (Meaning I am keeping less RAM for SD), then I get

    0> sd_ble_enable: RAM START at 0x20002418
    0> sd_ble_enable: app_ram_base should be adjusted to 0x200025E0
    0> ram size should be adjusted to 0xDA20 
    0> softdevice_enable ERROR code = 0x4
    

    Error code 0x04 means, I don't have sufficient MEMORY for SD. So, I think setting the RAM starting point to 0x200025E0 keeps sufficient RAM for SD, but in that scenario I don't understand why I get the 1st message of reducing the RAM start address to 0x20002418???

    Can there be some conflicting memory usage going inside the app?

    I am using CENTRAL_LINK_COUNT==1 & PERIPHERAL_LINK_COUNT==1. While I am using one service only, as mentioned above.

  • I don't think the above mentioned RAM usage messages have anything to do with UART problem. Because I have just checked that my other program (which is working fine and does not use central code) also gives the same messages on top of the log:

     0> RAM START ADDR 0x200025E0 should be adjusted to 0x20002418
     0> RAM SIZE should be adjusted to 0xDBE8
     0> sd_ble_enable: RAM START at 0x200025E0

    But still works fine. Meaning UART operation has nothing to do with these messages. The problem is somewhere else.

Reply
  • I don't think the above mentioned RAM usage messages have anything to do with UART problem. Because I have just checked that my other program (which is working fine and does not use central code) also gives the same messages on top of the log:

     0> RAM START ADDR 0x200025E0 should be adjusted to 0x20002418
     0> RAM SIZE should be adjusted to 0xDBE8
     0> sd_ble_enable: RAM START at 0x200025E0

    But still works fine. Meaning UART operation has nothing to do with these messages. The problem is somewhere else.

Children
No Data
Related