Issues with running FOTA and cJSON

RE: Issues with running FOTA and cJSON

Simonr — Thu, 24 Apr 2025 10:37:55 GMT

Hi again

So, the fact that converting the number to strings makes it work it seems to be because a function somewhere expects string(s) and not numbers, and I think it might be this one from the download_client() https://docs.nordicsemi.com/bundle/nrf-apis-latest/page/group_fota_download_ga613aa199d71f84a9531ea42c56776a1b.html#ga613aa199d71f84a9531ea42c56776a1b

So I'm guessing the download_client tried pulling one or more of your number values when a string was expected causing this issue.

Best regards,

Simon

RE: Issues with running FOTA and cJSON

simon belanger — Tue, 22 Apr 2025 13:08:13 GMT

Thanks for the migration guides, I will make sure I did not forget important steps.

[quote userid="75734" url="~/f/nordic-q-a/120773/issues-with-running-fota-and-cjson/532308"]How exactly are you linking this to the cJSON being the issue? Does the error only occur if you've done cJSON operations, or could it be something else like the Wi-Fi being active and thus you're not able to do a new connection?[/quote]

I am not entirely sure that cJSON is the cause, but I observed that the fota error only occurs when I use the method cJSON_AddNumberToObject() from the cJSON library, as mentionned in my last post. This led me to think that I was doing something wrong with that library. If I do not use this function from cJSON, I get no issues with FOTA. As a workaround, I formatted all my number values to strings so I could use cJSON_AddStringToObject and the FOTA works fine.

Best regards,

Simon

RE: Issues with running FOTA and cJSON

Simonr — Tue, 22 Apr 2025 10:14:20 GMT

I can't find anything specific related to JSON when moving from NCS v2.7.0 to 2.9.0, but there are a few migration steps you should be wary of when moving over. First off, the steps in "migration guide for NCS v2.8.0" has a lot of steps on how to move from 2.7.0 to 2.8.0. You should also go through the "Migrating from multi-image builds to sysbuild" to make sure you've included all necessary steps. Additionally, the error that seems to return is a "No such file or directory" error from what I assume is the fota_dl_handler() function apparently due to not being able to connect to the client. How exactly are you linking this to the cJSON being the issue? Does the error only occur if you've done cJSON operations, or could it be something else like the Wi-Fi being active and thus you're not able to do a new connection?

Best regards,

Simon

RE: Issues with running FOTA and cJSON

simon belanger — Thu, 17 Apr 2025 20:38:02 GMT

As a supplement, here are my latest findings.

It seems like the issue can be traced back to cJSON numbers. I can reproduce the issue by creating a cJSON object and adding a single numeral field using cJSON_AddNumberToObject(), then printing this cJSON as a string using cJSON_Print and then freeing everything. If I were to create a string field using cJSON_AddStringToObject(), the bug would not occur.

void device_publish_status(void) {
	char *json_payload = NULL;
	cJSON *response = NULL;

	if ((response = cJSON_CreateObject()) == NULL) {
		goto end;
	}
	if (cJSON_AddNumberToObject(response, "battery_voltage_mv", 42) == NULL) {
		goto end;
	}
	
	if ((json_payload = cJSON_Print(response)) == NULL) {
		LOG_ERR("Failed to format response to JSON.");
		goto end;
	}
	
	cJSON_FreeString(json_payload);
	LOG_INF("String has been freed");
end:
    cJSON_Delete(response);
	LOG_INF("Object has been freed");
	return;
}

So there seems to be an issue with cJSON_Number fields from my perspective that cause issues with memory which prevents the download client to perform OTA successfully. I did not include the OTA code but it is very similar to Cellular: HTTP application update.

I should also mention that I am using Zephyr's allocators (k_malloc and k_free) on system heap. This is done by running cJSON_Init() from cjson_os.h at the beginning of the main application, before doing anything else. I am also freeing the string using cJSON_FreeString() in order to free memory for the output string using the same allocator I used to allocate it.