nrf_mesh_serial_tx returns NRF_ERROR_NO_MEM

RE: nrf_mesh_serial_tx returns NRF_ERROR_NO_MEM

tesc — Tue, 03 Dec 2019 17:05:45 GMT

Hi,

Build code is B0, that corresponds to Bx0 (where x is 0), i.e. revision 1. I realize that the mapping is not obvious, you need to look into the ordering information section of the product specification for it to fully make sense.

In any case I am happy to hear you have found a new board where everything seems to be working. Feel free to open a new thread (or revive this one) when (if) you find some time and decide to look into it again.

Regards,
Terje

RE: nrf_mesh_serial_tx returns NRF_ERROR_NO_MEM

Mathias — Tue, 03 Dec 2019 15:20:49 GMT

Year seems to be 2016 and week number 26. The chip markings indicate N52832 QFAAB0 1606AA. I understand this means Packet Variant QFAA as indicated here https://infocenter.nordicsemi.com/topic/comp_matrix_nrf52832/COMP/nrf52832/ic_revision_overview.html?cp=4_2_2_0, but I'm not sure what is the Build Code.

The main issue seems to be the serial communication. But I'll assess if the problem remains when performing UART without any BLE or BLE mesh radio communication going on as well. I'll get back to it once I find some time :)

RE: nrf_mesh_serial_tx returns NRF_ERROR_NO_MEM

tesc — Tue, 03 Dec 2019 15:06:57 GMT

Hi,

I am sorry for the delayed answer from my side.

The version and production date of the board should be printed on the programmer MCU, e.g.:

PCA10040
V1.0.0
2016.32

There, line number three is year (2016) and week number (32).

I am a little puzzled that you get both of those issues on the old board, as I do not see an immediate connection between the two... Chip markings of the nRF52832 will reveal chip revision, it may be that if it is an engineering revision it requires errata workarounds that are not present in the latest SDKs.

Regards,
Terje

RE: nrf_mesh_serial_tx returns NRF_ERROR_NO_MEM

Mathias — Wed, 27 Nov 2019 12:15:16 GMT

I found the problem... It seems the serial communication capabilities of my DK are broken. I tested the communication on another DK and everything is working fine there, with serial communication occuring as it should and no NRF_ERROR_NO_MEM codes being returned.

Not sure why the serial communication of my DK suddenly failed. I think its ~ 2 years old.

RE: nrf_mesh_serial_tx returns NRF_ERROR_NO_MEM

Mathias — Wed, 27 Nov 2019 10:59:51 GMT

Hmm, it seems something stranger is going on.. Serial communication is not printed on any reader or when using the Interactive Python Application Controller Interface Python script. I even tried to just test the loopback, by calling d[0].send(cmd.Echo("hello world")), but it also times out.

I do call nrf_mesh_serial_init(serial_interface_cb) upon initialization of the provisioner and it does return NRF_SUCCESS. I am also sure that I'm using the correct COM port to read out serial. So not sure what's still missing...

RE: nrf_mesh_serial_tx returns NRF_ERROR_NO_MEM

Mathias — Tue, 26 Nov 2019 17:33:35 GMT

I tried increasing the buffer size, but the problem remained the same. What essentially happens is that its initially working fine, but then NRF_ERROR_NO_MEM starts getting returned and it doesn't go back from that until I reset the board...

RE: nrf_mesh_serial_tx returns NRF_ERROR_NO_MEM

Mathias — Tue, 26 Nov 2019 16:53:44 GMT

Hi,

Thanks for the comprehensive answer!

With retry mechanism, do you mean repeating the method until it doesn't return NRF_ERROR_NO_MEM anymore but instead returns NRF_SUCCESS, meaning it succeeded? Because I tried putting it in a while - loop but it kept returning NRF_ERROR_NO_MEM, blocking the application entirely...

The client model's publication timer on the provisioner is set on 10 seconds, which means that every 10 seconds it sends a GET message to all nodes, hoping to receive STATUS messages back from them. Right now, I reduced the network to only one node, meaning it will only get one STATUS message back or thus meaning it will only call nrf_mesh_serial_tx once every ~ 10 seconds.

I'll see if increasing the tx buffer size helps, but as you say, that could possibly not help at all.

Kind regards,

Mathias

RE: nrf_mesh_serial_tx returns NRF_ERROR_NO_MEM

tesc — Tue, 26 Nov 2019 13:17:29 GMT

Hi,

According to nrf_mesh_serial_tx() documentation, NRF_ERROR_NO_MEM means "The serial TX queue was full, and the packet couldn't be scheduled for transmission."

It does not have to do with available flash space. Rather, it has to do with the amount of RAM to use for buffers used for storing outgoing serial messages. Serial buffer TX queue size is hard coded in serial_bearer.c to be two times the maximum possible packet size:

#define TX_BUFFER_SIZE (2 * ALIGN_VAL(sizeof(serial_packet_t) + sizeof(packet_buffer_packet_t), WORD_SIZE))

You can either increase the tx buffer size (at the expense of using more RAM), or implement a retry mechanism.

Note that if over time you queue transmissions faster than they get sent, then increasing the buffer size will not work. This is because the number of elements in the queue will then steadily rise until you reach queue capacity.

Regards,
Terje