Open ksidirop-laerdal opened 1 month ago
The group
is the ID of the manager (group), so that's one of these:
https://github.com/NordicSemiconductor/Android-nRF-Connect-Device-Manager/blob/389c60095a11e685ec3023fc33eed205866f87e2/mcumgr-core/src/main/java/io/runtime/mcumgr/McuManager.java#L60-L76
The rc
is a the [TheManagerWithGivenGroupId].ReturnCode
. So, if exception.getGroupCode().rc == 8
(FSManager
), than rc
adheres to 'enum FsManager.ReturnCode', etc.
If the device doesn't support SMP v. 2, the exception.getGroupCode()
returns null
, and you need to use exception.getCode()
, which adverse to https://github.com/NordicSemiconductor/Android-nRF-Connect-Device-Manager/blob/389c60095a11e685ec3023fc33eed205866f87e2/mcumgr-core/src/main/java/io/runtime/mcumgr/McuMgrErrorCode.java#L24
Appreciate the prompt response. Now it all makes sense. Just a quick follow up question or two:
int GROUP_LOGS = 4
int GROUP_CRASH = 5
int GROUP_SPLIT = 6
int GROUP_RUN = 7
Appreciate any insights!
Hi, Basic Group is called Zephyr Group, as far as I remember. These are Zephyr specific commands, or actually just one, the erase app settings.
The other group you mentioned aren't supported on Zephyr, thus weren't migrated to SMP V2, so they don't support group errors.
Basic Group is called Zephyr Group, as far as I remember. These are Zephyr specific commands, or actually just one, the erase app settings.
Cool. By the way what is the group-id of the basic-group ("zephyr-group"). Can I find it somewhere?
(pardon me if I'm missing something obvious while reading between the lines)
https://github.com/NordicSemiconductor/Android-nRF-Connect-Device-Manager/blob/main/mcumgr-core/src/main/java/io/runtime/mcumgr/response/HasReturnCode.java
In our Laerdal.McuMgr bindings-library we need to perform exception-mapping and error-mapping between the Java world and the C# world whenever an error occurs during file-downloading or file-uploading (for example "file not found", "corrupted", etc).
Is it correct to say that in the context of file-uploading and file-downloading any McuMgrErrorException adheres to the following statements?
Likewise in the case of firmware-installation we have the following callbacks-proxy:
Is it correct to say that in the context of firmware-installation any McuMgrErrorException adheres to the following statements?
( I just want to be sure that there isn't some corner case where these integer fields are adhering to some other enums because if this happens our error-mapping and exception-mapping will end up mapping and reporting the wrong kind of error over to the C# world misleading the host-application! )