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

    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.

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

Children
Related
Terms of service