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

    Hi Steve, 

    Could you please clarify that you can receive UART data normally on PC if you test with the single link central_uart and peripheral_uart ? 
    As far I can see there isn't any modification with regard the way UART data is printed out. 
    It's first printed by using uart_tx() in ble_data_received() function. If that failed the data will be buffered into fifo_uart_tx_data fifo data using k_fifo_put()

    And then after that when UART_TX_DONE event occurred  in uart_cb() the data is pulled out from fifo and sent out again via UART. 

    I would suggest to test if you can print out something in UART using uart_tx() maybe in main() ? 

  • 0

    If I load the standard uart_c app (single channel) on an nRF52832 DK it works just fine.

    Thank you for the pointers. That should get me enough to dig down into the code and find where it's going astray. But in the meantime, is there anything I would have been likely to miss, either in configuring nRF Connect and VS, or in the project configuration? Something relating to memory allocation would be suspicious.

  • 0

    I now have a very basic problem with the build. nRF Connect 1.9.1, VS extensions. I struggled with this for a while, don't remember how I got around it, but now it's back. Every time I attempt to build via ctrl-F5, I get two bars at the bottom right of the window:

    Set up and build for CMake project before debugging.

    Bad CMake executable: "". Check to make sure it is installed or the val...

    How do I get past these? I have been extremely frustrated in fighting the tools rather than getting work done for the past two months, ever since I tried to move over to nRF Connect from the nRF5 tools.

  • 0 in reply to user68828

    Hi Steve, 

    I'm sorry that the toolchain didn't work smoothly for you. I have to admit that it's quite more difficult to get started with nRF Connect SDK compare to nRF5SDK. 

    Could you let me know how you installed your NRF Connect toolchain ? Have you used the ToolChain Manager app inside nRFConnect for Desktop ? 

    Please take a screenshot when you receive the error. 

    Also I would suggest to try reinstall nRFConnect SDK v1.9.1 to see if it fixed the issue. Or you can try v1.9.0 it could be more stable. 

    Instead of pressing Ctrl+F5 please click this button instead: 

    Please have a look at this getting started guide if you haven't: https://www.youtube.com/playlist?list=PLx_tBuQ_KSqEt7NK-H7Lu78lT2OijwIMl 

  • 0 in reply to Hung Bui

    I installed everything using the Toolchain Manager, so I expect it to just work.

    Here's a screenshot of the error per your request, maybe it will help troubleshooting:

    Using the <Action><Build><Flash> buttons appears to work just fine. Now I can finally get back to debugging why the application itself fails, per my original inquiry above at the top. Must be some sort of memory allocation error etc. I see that the communication buffers are dynamically allocated. In my 4+ decades of experience, I have found that to be a bad idea when testing for worst-case robustness, although the worst case in my environment shouldn't stress it. Even connecting one or two Peripherals yields the same garbled comm string.

Related
Terms of service