• State Verified Answer
  • Locked Locked
  • Replies 11 replies
  • Subscribers 25 subscribers
  • Views 360 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 288564
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Multi-NUS-Master forwards gibberish from Peripherals

user68828

After several months of attempts, I was finally able to load, build, and flash the code from multi-NUS-master.zip using the VS version of nRF Connect, onto the nRF52840 DevKit. The code appears to run, and it connects to multiple Peripherals via the NUS service. When a peripheral sends data via NUS, the master tries to forward it via the Interface MCU to the USB serial port. However, the data is gibberish. I have looked at the data being received, on the serial TxD line (P0.06) between the nRF52840 and the Interface MCU. It should be pure printable ASCII text, but the first few bytes are 0x00, 0x1D, 0x00, 0x20, 0x03. The over-the-air BLE data is fine, because I can view that with a single-connection version of the uart-c example running on another board. So I am suspecting that somewhere in the multi-NUS-master code a buffer is not being allocated correctly, a pointer is corrupted, etc. I furhter suspect the underlying problem is that I missed configuring something important in the nRF Connect or VS installation. Can anybody give me some pointers? (pun intended)

  • 0 in reply to user68828

    Hi Steve, 


    Do you have any issue if you create a new application from sample ? 


    Note that the MultiNUS sample was from NCS SDK v1.4.1 it may not compatible with the new NCS version. 

  • 0

    I was previously able to build and run that sample, at least I think it was the same source code. It has been a major struggle to get nRF Connect in the newer versions to do ANYTHING useful. I will try it using an earlier version later this afternoon and report back.

    That still begs the question: Why haven't the examples been updated to match the current tools, and why were they written to be so fragile that a simple tool version upgrade breaks them?

  • 0

    Some further diagnostics. I dug into ble_data_received. I can write text into tx -> data, and that text is displayed correctly on the USB serial port, so I have a means of peeking inside now. If I write a string of consecutive characters into that buffer, it displays just as I would expect. Using sprintf to peek at some internal numbers, I find:

    data (ostensibly the data received via BLE) always points to 0x200140AC. This is within RAM, so I have no reason to believe it's not valid.

    pos is an integer that offsets the start position within data of the actual receive data. This continually increments by UART_BUF_SIZE (I've tried setting this constant to several different values, including the default 20).

    tx->len is always UART_BUF_SIZE.

    pos resets to zero as each transmission is received over BLE. If tx->len is 20, pos gets as high as 980. If tx->len is 80, pos gets as high as 1200.

    The actual received data packets run from 24 to 28 bytes long.

    I cannot find where ble_data_received is called from. It is apparently pointed to by a pointer in some struct, presumably used by the BLE receive routine when a packet is received.

    Hints, please?

  • 0 in reply to user68828

    Hi Steve, 

    The example was created by one of our FAEs in his blog as a demonstration on how you can modify the central uart example to support multiple peers. I understand that all of all examples in best case should be up-to-date with the latest SDK but it's a difficult task to keep all the blogs updated after every release of the SDK. 
    The approach here is to use the same SDK version that used by the author to test and study what has been changed to the example. And after that apply similar modification to the example in the SDK version that you  plan to use. 

    Regarding your question ble_data_received() call back is fed to nus_client_init() in nus_client.c 

    And this received callback will be called inside on_received() function in nus_client.c . on_received() is called when there is a notification from one of the peers.

  • 0

    The only place on_received appears (via a global search in the project) is in .map and .lst files, either as a comment to assembler code or as a field of .text.

    I have added code to search all of RAM when a packet is received, looking for a match to a string that I know is in the transmitted data. No match in all of RAM.

    I have also tried compiling using every version of nRF Connect that I have ever installed, running it on three different nRF52840 devkits, and everything else I can think of.

    I fail to understand why such a simple example program fails in such a scrambled way. Where can I download the original source to be sure I haven't mucked something up?

Related
Terms of service