• State Not Answered
  • Replies 38 replies
  • Subscribers 70 subscribers
  • Views 3072 views
  • Users 0 members are here
Attachments (9) Download All
Nordic Case Info
  • Case ID: 321282
Options

esb, shockburst, running on nrf5340dk's

mej7000

I have 3 nrf boards connected. 2x nrf52832 and 1x nrf5340.

esb_tx is running on nrf52832(682782977)
esb_rx is running on nrf52832(682497942) & nrf5340(1050025410)

west build -b nrf5340dk_nrf5340_cpunet -p builds correctly and flashes without error

PS C:\nrf\esb_prx> west flash -d build_1
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner nrfjprog
There are multiple boards connected.
1. 1050025410
2. 682782977
Please select one with desired serial number (1-2): 1
-- runners.nrfjprog: Flashing file: build_1\zephyr\zephyr.hex
[ #################### ] 2.055s | Erase file - Done erasing
[ #################### ] 0.243s | Program file - Done programming
[ #################### ] 0.243s | Verify file - Done verifying
Applying pin reset.
-- runners.nrfjprog: Board with serial number 1050025410 flashed successfully.

esb_rx is working on the nrf52, but not on the nrf53.

... To be through, I powered down esb_tx_nrf52832(682782977) and flashed another nrf5340dk(1050077823) and programmed it to be esb_tx:

PS C:\nrf\esb_ptx> west flash -d build_1
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner nrfjprog
There are multiple boards connected.
1. 1050025410
2. 1050077823
3. 682497942
Please select one with desired serial number (1-3): 2
-- runners.nrfjprog: Flashing file: build_1\zephyr\zephyr.hex
[ #################### ] 2.044s | Erase file - Done erasing
[ #################### ] 0.235s | Program file - Done programming
[ #################### ] 0.236s | Verify file - Done verifying
Applying pin reset.
-- runners.nrfjprog: Board with serial number 1050077823 flashed successfully.

Although 1050077823 (nrf5340-esb_tx) flashed correctly. Blinky continues to run (as it already had) on nrf5340-esb_tx, which probably makes sense, but I'm not getting any kind of esb response from either (nrf52832 or nrf5340) esb-rx.

There is something I am not understanding about how to flash to nrf5340_CPUNET? Maybe it's flashing correctly, but esb needs to be called from CPUAPP to start it working?? I'm close, but missing something...

Ultimately the goal is to have a network of nrf5340's in a Star configuration. I see that there is shared memory between CPUAPP and CPUNET. I assume somehow it's used to pass data from CPUAPP to CPUNET for transmission/reception. I don't exactly understand how that works either, but I figure the first step is to get the esb Sample to work on nrf5340dk's without modification. But, if there are additional samples that target this use case I would be interested in reviewing those too.

The final configuration goal is to have the center of the star network also be running BLE-UART (so the central esb in the Star Network will relay the esb data from the nodes to a BLE app). I am assuming that there is no problem running both esb and BLE at the same time.

esb_prx_ptx.zip

Parents Reply Children
  • 0 in reply to mej7000

    Hi Michael

    It looks to me like you are trying to build the ptx sample for the netcore? 
    Your west build command targets nrf5340dk_nrf5340_cpunet, and the warning you get indicate that you are trying to build an appcore sample for the netcore, since the CONFIG_BOARD_ENABLE_CPUNET config will only work on the appcore. 

    Also, I am confused by your folder structure. If you cloned the github repo, where is the ptx folder? 
    I would recommend building the example out of the box without making any changes, before trying to adapt it to your own project. 

    Best regards
    Torbjørn

  • 0 in reply to ovrebekk

    Thanks. Out of the box was my intention, but I redid it again just to be sure.

    1. Out of the box, esp_tx SDK example
    2. build_5340 targets cpunet, (only option, image attached). I assume there is a 5340 HW reason it has to run on cpunet
    3. build for both 5340 and 52832
    4. esb_rx running on an additional 52832. 
    5. esb_tx build_53832 works (esb_tx receiving/led flashing on nrf52832)
    6. esb_tx build_5340 does not work (flashed successfully, but no esb_tx activity is received on esb_rx.
    7. firmware previously flashed to nrf5340 cpuapp continues to operate normally (blinky or whatever previously flashed to cpuapp)
    8. "where is the ptx folder?" This is still the esp_tx sample from the SDK. Folder structure is unmodified from the SDK (attached) 

    esb_ptx_5340-2.zip

  • 0 in reply to mej7000

    Hi Michael

    My bad, I misunderstood and thought you were trying to build the MPSL timeslot sample. 

    mej7000 said:
    build_5340 targets cpunet, (only option, image attached). I assume there is a 5340 HW reason it has to run on cpunet

    The radio is only accessible from the network core. The idea of the 5340 is to have the wireless stack run from the network core, while the application core handles the application logic itself, as well as interfacing with sensors and doing more compute intensive tasks. 

    As such the ESB protocol can only be built for the network core, since it accesses the radio peripheral directly. 

    Thanks for sharing your code. I downloaded it and built it for NCS v2.5.1, and I don't seem to have any problems running it. 

    I flashed an nRF5340DK with the empty app core image first, and then with your code built for the netcore. On the PRX side I use an nRF52840DK. I can see the LED's toggle as expected, and can also see on the UART log that the TX_SUCCESS callback is triggered on the PTX side. 

    Do you see any log output from your 5340DK? 

    Which version of the DK do you have? 

    Best regards
    Torbjørn

  • 0 in reply to ovrebekk

    Thanks! Problem solved-ish... As soon as I flashed "empty app core" to the cpuapp everything started working! I'm a little confused as I thought I had already tried flashing "empty app core"...

    When 5340prx and/or 52832prx are flashing normally, resetting ptx causes both 5340prx and/or 52832prx to pause (so they are all programmed and communicating correctly)

    The weird thing I notice now is that after a few minutes (5340prx and 52832prx) will stop flashing. While ptx on the 5340ptx continues to work/flash as expected.

    Serial output "Packet received" string is also terminated on prx when the leds stop flashing.

    Pressing reset on either (5340prx or 52832prx) will bring both (5340prx and 52832prx) back to flashing normally.

    When (5340prx and 52832prx) stop flashing normally, pressing reset on 5340ptx does not cause (5340prx and/or 52832prx) to start flashing again.

    The (5340prx and 52832prx) behavior is constant and repeatable. However when I had 52832ptx and 53832prx they flashed synchronously for days uninterrupted.

    Further testing:  The problem seems to be when the two prx are too close (~30cm) to each other.  Separating prx by a few meters solves the problem. That would be a problem as the final wearable products could easily be left close to each other on a desk or table, etc... 

    So one problem solved, but another discovered...

    1. Is there any solution to this "multiple prx in proximity" problem?
    2. If I were to be able to use shockburst for this or something else, right now all the shockburst logic is running on cpunet. Are there any samples or instructions on how to interact with shockburst from cpuapp? Is it all transparent or are there additional things I need to know?
    3. On my nrf5340dk I now have shockburst running on cpunet. How do I flash that back to "factory settings cpunet" for developing "non-shockbust" applications?
  • 0 in reply to mej7000

    Hi Michael

    mej7000 said:
    I'm a little confused as I thought I had already tried flashing "empty app core"...

    It is easy to lose track of what is programmed where. I would strongly recommend enabling UART logging for both cores separately, and make sure to include some kind of welcome message at the start of main (not all the standard samples do this). 

    mej7000 said:
    Is there any solution to this "multiple prx in proximity" problem?

    Am I correct in assuming you are sending the same message to both PRX's on the same address, while also using ACK? 

    This is not recommended as you will get conflicts between the ACK messages sent from the two PRX's, and in some cases you can get weird issues where an ACK packet is interpreted as a normal packet. 

    The fix is to either disable ACK when sending a packet to multiple receivers, or to use different pipes for the two PRX's and send one packet to each of them. 

    mej7000 said:
    If I were to be able to use shockburst for this or something else, right now all the shockburst logic is running on cpunet. Are there any samples or instructions on how to interact with shockburst from cpuapp? Is it all transparent or are there additional things I need to know?

    This is one of the things I am trying to show in the example I linked to earlier:
    https://github.com/too1/ncs-esb-ble-mpsl-demo

    The main purpose of this sample is to show how to run ESB and BLE in parallel using timeslots, but it also shows how the communication can be established between the nRF5340 appcore and netcore in order to control the ESB communication from the appcore. 

    mej7000 said:
    On my nrf5340dk I now have shockburst running on cpunet. How do I flash that back to "factory settings cpunet" for developing "non-shockbust" applications?

    There are many way to do this:

    a) The simple way is just to perform a mass erase of your device, which will remove any application from the netcore:

    nrfjprog -e

    b) You could always disable the netcore in the appcore project, in order to prevent it from running:

    CONFIG_BOARD_ENABLE_CPUNET=n

    c) Finally there is an empty_net_core sample in the SDK, similar to the empty_app_core project, that you can flash in the netcore if you want. That said option a) or b) are simpler in my opinion. 

    Best regards
    Torbjørn

Related