nRF5340 DK: about sample 'MQTT publisher'

Hi Support team,

I'm using nRF5340 DK and an ublox SARA-r4 modem to try MQTT. My code is on the net-core and the modem works well.

By porting the sample code of 'MQTT publisher', I can publish some MQTT messages, but there are some strange behaviors, Could you help give some hints?

1. When I use 'test.mosquitto.org' as the broker, only can send the QoS-0 message successfully. For the QoS-1 message, can not receive PUBACK from the broker, for the QoS-2 message, can not receive PUBREC from the broker. But when I try with other MQTT tools, the broker can handle QoS-1 and 2 messages well.

2. When I use 'broker.hivemq.com' as the broker, both Qos-0 and Qos-1 can work well, and can publish and receive successfully. But when I published the Qos-2 message, the system crashed:

Crashed at code:

 

void mqtt_evt_handler(struct mqtt_client *const client, const struct mqtt_evt *evt)
{
	int err;

	switch (evt->type) {
		case MQTT_EVT_CONNACK:
			if (evt->result != 0) {
				break;
			}

			g_connected = true;

			break;
		case MQTT_EVT_DISCONNECT:
			g_connected = false;
			clear_fds();

			break;
		case MQTT_EVT_PUBACK:
			if (evt->result != 0) {
				break;
			}

			break;
		case MQTT_EVT_PUBREC:
			if (evt->result != 0) {
				break;
			}

			LOG_INF("PUBREC packet id: %u", evt->param.pubrec.message_id);
			const struct mqtt_pubrel_param rel_param = {
				.message_id = evt->param.pubrec.message_id
			};

			LOG_ERR("Before mqtt_publish_qos2_release()");     -------------------------Crashed at here
			err = mqtt_publish_qos2_release(client, &rel_param);
			LOG_ERR("After mqtt_publish_qos2_release(), err = %d", err);
			if (err != 0) {
				LOG_ERR("Failed to send MQTT PUBREL: %d", err);
			}
			break;
		case MQTT_EVT_PUBCOMP:
			if (evt->result != 0) {
				break;
			}

			break;
		case MQTT_EVT_PINGRESP:
			LOG_INF("PINGRESP packet");
			break;
		default:
			break;
	}
}

The trace when crashed:

[00:00:38.046,295] <inf> mqtttest:     step3---mqtt_publish QOS2 OK, rc is 0
[00:00:38.396,240] <inf> mqtttest: do zsock_poll() 2s, ret = 1
[00:00:38.396,362] <inf> mqtttest: -----[MQTT_EVT_PUBREC] PUBREC packet id: 18845
[00:00:38.396,362] <err> mqtttest: Before mqtt_publish_qos2_release()
[00:00:38.396,575] <err> os: ***** USAGE FAULT *****
[00:00:38.396,606] <err> os:   Stack overflow (context area not valid)
[00:00:38.396,636] <err> os: r0/a1:  0x0101e288  r1/a2:  0x09000000  r2/a3:  0xa9635234
[00:00:38.396,636] <err> os: r3/a4:  0x327366d0 r12/ip:  0xafb84f4e r14/lr:  0x00000080
[00:00:38.396,667] <err> os:  xpsr:  0x00000000
[00:00:38.396,697] <err> os: Faulting instruction address (r15/pc): 0x00000000
[00:00:38.396,728] <err> os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
[00:00:38.396,759] <err> os: Current thread: 0x21002930 (unknown)
[00:00:38.903,320] <err> fatal_error: Resetting systemm
 step3---mqtt_publish QOS2 OK, rc is 0

I just sent small messages with a 45-byte payload. and the APP_MQTT_BUFFER_SIZE is 128 bytes.

Could you help give some hints? Thank you very much.

Best regards,
Yanpeng Wu

Parents
  • The logs are quite informative in your case showing that it is the stack overflow that is causing this fault

    [00:00:38.396,606] <err> os:   Stack overflow (context area not valid)

    You need to figure out the context of the thread that is causing this. Right now it says Current thread: Unkown.
    You can change that by enabling CONFIG_THREAD_NAME in your prj.conf. And when you recompile your project and test again, you will see the name of the thread that caused this. You can then increase the stack size of this thread to have little more breathing space in RAM.

Reply
  • The logs are quite informative in your case showing that it is the stack overflow that is causing this fault

    [00:00:38.396,606] <err> os:   Stack overflow (context area not valid)

    You need to figure out the context of the thread that is causing this. Right now it says Current thread: Unkown.
    You can change that by enabling CONFIG_THREAD_NAME in your prj.conf. And when you recompile your project and test again, you will see the name of the thread that caused this. You can then increase the stack size of this thread to have little more breathing space in RAM.

Children
Related