• State Verified Answer
  • Locked Locked
  • Replies 11 replies
  • Subscribers 25 subscribers
  • Views 361 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)

Parents
  • 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.

Reply
  • 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.

Children
No Data
Related
Terms of service