• State Verified Answer
  • Replies 6 replies
  • Subscribers 71 subscribers
  • Views 3288 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 111734
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

On Timeslot API, SoftDevice, and locked bytes

leo_91

Best Regards,

I am developing a firmware version for nrf51822 based on Softdevice S130 (old v8.1) and Timeslot API. Currently, I can freely transmit and receive packets while the softdevice is active, running, and actively utilizing the radio interface.

Issue: while sending packets via the Timeslot API, the 25th byte of the packet is never correctly set, it doesn't have a fixed value, and floats within a range of values (e.g. from 0xBB to 0xCC).

Question: Is the 25th byte of a timeslot packet maybe the CRC field?

Details:

The issue happens only when we send a packet via the timeslot API. The packet is configured on the fly on a vector of size (e.g.) 25, and is formatted following BLE standard, so that nRF Master Control Panel and a custom android application can receive and parse the packet successfully. Flags or scan response are not implemented yet, because they are not needed for now. The timeslotted radio is configured to send over advertising channels, with default advertising parameters (default CRCINIT, ADV_ADDRESS, WHITEEN enabled, so that we are practically sending custom advertising packets).

Guesses

  • I ended up in that part of memory where the CRC field is computed/stored, or other fields used by the radio.
  • I'm trying to send more bytes than what I actually am allowed to (even though if I recall correctly, the maximum amount of data that can be stuffed inside a packet is 31 bytes (8-byte header included).

Correct me if I'm mistaken somewhere, and if any of you could help me solve the issue, I would be thankful. Further notes below.

Thanks,

Leo.

Notes:

  1. On further investigation, the issue does not depend on the length of the packet; we can send more bytes, but from the 25th onward never show correctly when received.
  2. The data is written inside the Manufacturer Data field (type code 0xFF), and shows correctly up to the 24th byte.
  3. Could not be related, but while trying to solve this we found another strange thing.

Edit:

Adding screenshots of nRF Master Control Panel (forgot to add it since the beginning). image description

Parents
  • 0

    I agree with you run_ar, thanks. Yet what bugs me is that the floating byte is on the 25th position, not the 32nd, therefore I'm supposedly within the valid packet length.. with "25th" I mean w.r.t. the BLE packet structure, i.e. we send something like

    0x42 0x16 - 0xFF 0xEE 0xDD 0xCC 0xBB 0xAA - 0x03 0x09 0xAC 0xAB - 0x16 0xFF 0x15 0x16 0x17 0x18 0x19 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x30 0x31 0x32

    and the 0x25 byte is floating. I would expect the 0x32 (th) to be floating or undefined, in case of maximum packet size exceeded. Am I right?

    It could be that maybe I'm not accounting for some additional packet length, and hence the 25th is instead the 32nd?

Reply
  • 0

    I agree with you run_ar, thanks. Yet what bugs me is that the floating byte is on the 25th position, not the 32nd, therefore I'm supposedly within the valid packet length.. with "25th" I mean w.r.t. the BLE packet structure, i.e. we send something like

    0x42 0x16 - 0xFF 0xEE 0xDD 0xCC 0xBB 0xAA - 0x03 0x09 0xAC 0xAB - 0x16 0xFF 0x15 0x16 0x17 0x18 0x19 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x30 0x31 0x32

    and the 0x25 byte is floating. I would expect the 0x32 (th) to be floating or undefined, in case of maximum packet size exceeded. Am I right?

    It could be that maybe I'm not accounting for some additional packet length, and hence the 25th is instead the 32nd?

Children
No Data
Related
Terms of service