Ajay K
Forum Replies Created
-
AuthorPosts
-
October 9, 2020 at 3:15 pm in reply to: MDot 4.0.1 library compilation warning in mDotEvent.h #31233Ajay KParticipant
Hey Jason,
I think like you say it works as is currently and you don’t foresee any issues right based on my earlier comments? I just don’t want to deploy this in production and later find out we run into issues.
Thanks,
AjayOctober 8, 2020 at 1:40 pm in reply to: MDot 4.0.1 library compilation warning in mDotEvent.h #31232Ajay KParticipantThanks Jason for taking the time to respond, however i see it says read_ms is deprecated since mbed-os 6.0.0 and the version that is being used mdot library is mbed os 6.1.0 and when I look at mdotevent.h, all the lines of code above that warning seems to have been updated to use the chrono based elapsed_time, except for this line of code where the warning is generated. Is this intentional or something that was missed?
Thanks,
AjayOctober 8, 2020 at 1:26 pm in reply to: Do the User register values stay intact thru' power cycles. #31229Ajay KParticipantThanks Jason as always for the clarification.
Ajay KParticipantThanks Jason, I missed the “ifndef NDEBUG”. Thanks a lot for your inputs.
Thanks,
AjayAjay KParticipantHey Jason,
Sorry I am not sure what you mean by include logTrace and logDebug. This is what I have in the mtslog.h under ndebug.
#ifndef NDEBUG #define logDebug(format, ...) \ __LOG__(mts::MTSLog::DEBUG_LEVEL, format, ##__VA_ARGS__) #define logTrace(format, ...) \ __LOG__(mts::MTSLog::TRACE_LEVEL, format, ##__VA_ARGS__) #else #define logDebug(...) #define logTrace(...) #endif // NDEBUG
Thanks,
AjayAjay KParticipantHi Jason,
Thanks for your response. I am using an MDot not xDot and we log a lot of our debug entries to troubleshoot in the field using logTrace and logDebug, based on the logging level set. Currently the MDot when we set the log level to trace level doesn’t print out the logTrace and logDebug statements.
Are you saying this depends on the library being compiled using some #defines being set during the compile time?
We are using the latest libmDot located here https://github.com/MultiTechSystems/libmDot and not sure how the production library is compiled and with what #defines?
Thanks,
AjayOctober 8, 2020 at 11:41 am in reply to: Do the User register values stay intact thru' power cycles. #31221Ajay KParticipantAny thoughts on this? Is the User Register values stored on the internal MDot flash or MDot RAM?
Thanks,
Ajay.Ajay KParticipantAny thoughts on this issue as to why setting the logging level to the highest in my case TRACE_LEVEL doesn’t print out logTrace, logDebug statements?
Thanks,
AjayOctober 7, 2020 at 1:03 pm in reply to: Unable to flash firmware due to write_firmware step failing on bootloader. #31217Ajay KParticipantThis is resolved for now. Needed to upgrade the MDot bootloader to version 1.0.0 for it to work. Thanks to your support team to help us resolve this.
Thanks,
AjayOctober 7, 2020 at 11:48 am in reply to: Unable to flash firmware due to write_firmware step failing on bootloader. #31216Ajay KParticipantAny ideas as to how this can be resolved. Also if I power-up the mDot it just stays infinitely in a loop, printing debug o/p on the COM Ports as described earlier in the thread. This has completely blocked us, even though we are also tracking a ticket on this issue, it would be great if we can be unblocked at the earliest.
Thanks,
Ajay.October 6, 2020 at 3:02 pm in reply to: Conduit AEP: Cellular Mode configuration available on 5.2.1 firmware #31214Ajay KParticipantIts possible we may have used the SIM on another conduit before. So bottom line it should have worked with PPP as well, there is no reason for a cellular network to connect only under WWAN option?
Thanks,
AjayOctober 6, 2020 at 1:04 pm in reply to: Unable to flash firmware due to write_firmware step failing on bootloader. #31212Ajay KParticipantHi Taylor,
Thanks again for taking the time to respond. The bootloader version is mentioned below:
bootloader version v0.1.6-5-g4e0ca29
I have try with a development kit. However since we have had this custom board with us for over 2 years now, this is the first time I am seeing so many issues with the bootloader and inability to flash the firmware. I am not sure if this is anything to do with the 4.0.1 dot library or the multitool firmware o/p, which is appending the CRC
Thanks,
AjayOctober 6, 2020 at 12:55 pm in reply to: Conduit AEP: Cellular Mode configuration available on 5.2.1 firmware #31211Ajay KParticipantThe Conduit AEP model is MTCDT-L4N1-246A and the radio model and the radio status window had this information I am guessing is what you are looking for:
Manufacturer Telit
Model LE910C4-NFThanks,
AjayOctober 6, 2020 at 12:01 pm in reply to: Conduit AEP: Cellular Mode configuration available on 5.2.1 firmware #31208Ajay KParticipantThanks Steve and Jeff for providing your insights on PPP and WWAN. What is weird is if you have any thought on this issue we faced at one of our customers. This was a Conduit where we are trying to connect to the cellular network, and initially we chose PPP and it wouldn’t connect to the cellular network and when we switched it to WWAN it connected to the cellular network without any issues. Is there a reason for one working as opposed to other option not working?
Thanks,
AjayOctober 6, 2020 at 11:40 am in reply to: Unable to flash firmware due to write_firmware step failing on bootloader. #31207Ajay KParticipantAny thoughts on why this issue is occurring and how this can be resolved?
Thanks,
AjayOctober 6, 2020 at 12:55 am in reply to: Unable to flash firmware due to write_firmware step failing on bootloader. #31204Ajay KParticipantIf I power cycle the mdot, it sits in a loop and keeps printing out the following error.
[INFO] 0X7E000 bytes remaining
[INFO] 0X7C000 bytes remaining
[INFO] 0X7A000 bytes remaining
[INFO] 0X78000 bytes remaining
[INFO] 0X76000 bytes remaining
[INFO] 0X74000 bytes remaining
[INFO] 0X72000 bytes remaining
[INFO] 0X70000 bytes remaining
[INFO] 0X6E000 bytes remaining
[INFO] 0X6C000 bytes remaining
[INFO] 0X6A000 bytes remaining
[INFO] 0X68000 bytes remaining
[INFO] 0X66000 bytes remaining
[INFO] 0X64000 bytes remaining
[INFO] 0X62000 bytes remaining
[INFO] 0X60000 bytes remaining
[INFO] 0X5E000 bytes remaining
[INFO] 0X5C000 bytes remaining
[INFO] 0X5A000 bytes remaining
[INFO] 0X58000 bytes remaining
[INFO] 0X56000 bytes remaining
[INFO] 0X54000 bytes remaining
[INFO] 0X52000 bytes remaining
[INFO] 0X50000 bytes remaining
[INFO] 0X4E000 bytes remaining
[INFO] 0X4C000 bytes remaining
[INFO] 0X4A000 bytes remaining
[INFO] 0X48000 bytes remaining
[INFO] 0X46000 bytes remaining
[INFO] 0X44000 bytes remaining
[INFO] 0X42000 bytes remaining
[INFO] 0X40000 bytes remaining
[INFO] 0X3E000 bytes remaining
[INFO] 0X3C000 bytes remaining
[INFO] 0X3A000 bytes remaining
[INFO] 0X38000 bytes remaining
[INFO] 0X36000 bytes remaining
[INFO] 0X34000 bytes remaining
[INFO] 0X32000 bytes remaining
[INFO] 0X30000 bytes remaining
[INFO] 0X2E000 bytes remaining
[INFO] 0X2C000 bytes remaining
[INFO] 0X2A000 bytes remaining
[INFO] 0X28000 bytes remaining
[INFO] 0X26000 bytes remaining
[INFO] 0X24000 bytes remaining
[INFO] 0X22000 bytes remaining
[INFO] 0X20000 bytes remaining
[INFO] 0X1E000 bytes remaining
[INFO] 0X1C000 bytes remaining
[INFO] 0X1A000 bytes remaining
[INFO] 0X18000 bytes remaining
[INFO] 0X16000 bytes remaining
[INFO] 0X14000 bytes remaining
[INFO] 0X12000 bytes remaining
[INFO] 0X10000 bytes remaining
[INFO] 0XE000 bytes remaining
[INFO] 0XC000 bytes remaining
[INFO] 0XA000 bytes remaining
[INFO] 0X8000 bytes remaining
[INFO] 0X6000 bytes remaining
[INFO] 0X4000 bytes remaining
[INFO] 0X2000 bytes remaining
[INFO] 0 bytes remaining
[INFO] Flashing new firmware
[ERROR] write_firmware: lseek failed
[ERROR] update_firmware: Failed to flash new firmware
[INFO] Flashing backup firmware
[ERROR] write_firmware: open failed
[ERROR] update_firmware: Failed to flash old firmwareÿ[INFO] Backing up current firmwareOctober 5, 2020 at 4:39 pm in reply to: Conduit AEP: Cellular Mode configuration available on 5.2.1 firmware #31201Ajay KParticipantThanks Steve for the clarification. So bottom line if the two options are available in the conduit, its better to pick WWAN? Would that assumption be right?
Thanks,
AjayOctober 5, 2020 at 4:27 pm in reply to: Flashing firmware compiled using MBED Online/Offline compiler causes CRC Errors. #31200Ajay KParticipantThanks a lot Taylor for your help, the issue is resolved now.
Thanks,
AjayOctober 5, 2020 at 1:27 pm in reply to: Flashing firmware compiled using MBED Online/Offline compiler causes CRC Errors. #31197Ajay KParticipantThanks Taylor for taking the time to respond to this issue. I just need to ensure I understand your comments clearly for the offline build scenario.
The bootloader I have called out in the mbed_app.json gets packed with the final version of the bin file, however you are saying that I should use the fw_application.bin that is generated during the offline build instead, append the CRC using the python tool multitool and using the command below:
Appending CRC:
> multitool device crc -o output.bin fw_application.binThe second scenario is that for the online compiler scenario? Where you are suggesting we strip the bootloader off the resulting *.bin file that is created and then append the CRC using the tool?
Strip bootloader and append CRC:
> multitool device plain -b 0×10000 -c -o outut.bin fw.binThanks,
AjayOctober 5, 2020 at 12:55 pm in reply to: Flashing firmware compiled using MBED Online/Offline compiler causes CRC Errors. #31194Ajay KParticipantAny thoughts, this issue is blocking us from testing 4.0 mdot library.
Thanks,
AjayOctober 1, 2020 at 4:30 pm in reply to: Regarding using MDot Library version 4.0.0 and AEP Conduit firmware. #31192Ajay KParticipantThanks Jason for your help. I matched the release tag and used the right mbed-os-6.1.0. As I was using the tools release after that one. Anyway I am compiling all of this offline and was wondering if I should be worried about the warning I get while compiling the mDotEvents.h.
./libmDot/mDotEvent.h: In member function 'virtual void mDotEvent::ServerTime(uint32_t, uint8_t)': ./libmDot/mDotEvent.h:279:64: warning: 'int mbed::TimerBase::read_ms() const' is deprecated: Use the Chrono-based elapsed_time method. If integer milliseconds are needed, you can use <code>duration_cast<milliseconds>(elapsed_time()).count()</code> [since mbed-os-6.0.0] [-Wdeprecated-declarations] 279 | std::chrono::milliseconds(_timeSinceTx.read_ms());
Thanks,
AjaySeptember 30, 2020 at 10:32 pm in reply to: Regarding using MDot Library version 4.0.0 and AEP Conduit firmware. #31183Ajay KParticipantAny thoughts on the compilation error I am getting when compiling a custom firmware in the online compiler?
Thanks,
AjaySeptember 30, 2020 at 4:29 pm in reply to: Regarding using MDot Library version 4.0.0 and AEP Conduit firmware. #31181Ajay KParticipantI got the following compilation Error:
No member named ‘chrono’ in namespace ‘std’ in “libmDot/Lora.h”, Line: 116, Col: 16. This is while compiling on the online compiler.
Thanks,
AjaySeptember 30, 2020 at 3:52 pm in reply to: Regarding using MDot Library version 4.0.0 and AEP Conduit firmware. #31180Ajay KParticipantJason, it seems like mbed-os doesn’t seem to have a link for the mbed-os-6.1 release. Was this is a tools release? Do you have the github location for the mbed-os that was used to compile the mdot 4.0 library?
Thanks,
AjaySeptember 30, 2020 at 1:26 pm in reply to: Regarding using MDot Library version 4.0.0 and AEP Conduit firmware. #31178Ajay KParticipantThanks Jason for your response. Just curious since the latest mdot library 4.0 has been released and it pairs with mbed os 6.1, how come I don’t see this version of library available in the online compiler revisions for the library?
Also if I would like to build my firmware offline with this version, where can I pull the 4.0 library from and are there any specific version of the arm compiler I should be using since this is paired with mbed os 6.1?
Thanks,
AjaySeptember 27, 2020 at 11:49 am in reply to: Regarding using MDot Library version 4.0.0 and AEP Conduit firmware. #31175Ajay KParticipantThanks Jason for taking the time to respond. Few follow up questions:
1) You mentioned the mDot 4.0 “implements join nonce counter validation by default that verifies that the Join Accept nonce value has incremented from the last received value”. Does that mean if I disable this feature via the function calls you mentioned, can I work with older Conduit firmwares upto 1.7.4? Since most of our productions conduits are still on 1.7.4 firmware version.
2) Also you mentioned “with FOTA enabled the Dot will send GPS Time request MAC commands to sync the time. This can affect some network servers that do not have support for the GPS Time command.”. What network servers don’t have support for this command, is this only supported in certain conduit firmwares, or is this a hardware differences between the AEP based conduits that are shipped today?
Bottom line does using 4.0 dot library best benefit from using the latest conduit firmware currently I believe it is 5.2.1.
Thanks,
AjayJune 25, 2020 at 1:13 am in reply to: App-Manager hangs during installing custom app via command line/admin site. #30818Ajay KParticipantHi Jeff,
We have opened a ticket with Case #5102781. Usually Multitech is very quick to acknowledge a ticket, but I have not seen any response on this ticket for the last 48 hours.
Thanks,
Ajay.June 16, 2020 at 11:09 pm in reply to: App-Manager hangs during installing custom app via command line/admin site. #30754Ajay KParticipantHi Jeff,
When I executed the app-manager from the command prompt, I had copied the *.tar.gz file to the /var/volatile/tmp folder. Usually in the previous versions I could copy the file to /var/volatile and execute it from there, however as of 5.2.1 I get access denied errors when trying to transfer the file to /var/volatile. I could only copy the file to /var/volatile/tmp folder and execute it from there.
Like I mentioned I am not see any failure in the install script completing, its the app-manager that seems to not be exiting out once the install script for the custom app is completed and only a reboot seems to ensure a clean install.
The install of the custom app via the admin site is worse at this point.
Thanks,
AjayJune 15, 2020 at 6:35 pm in reply to: Flashing MDot firmware compiled using MBED Online compiler causes CRC Errors. #30746Ajay KParticipantHave this resolved now. The online compiler is still causing the CRC errors. However I got the offline build working and so we can close this issue at this point.
Thanks Jason for calling out the bootloader issue on the github issue.
Thanks,
Ajay.June 15, 2020 at 4:52 pm in reply to: Flashing MDot firmware compiled using MBED Online compiler causes CRC Errors. #30745Ajay KParticipantHi Jason,
I compiled this offline finally and now I am getting the following error, when I successfully flash the firmware. I am not sure why I am getting this error now, here is how I am compiling the source code from the command prompt using mbed-cli.
mbed compile -t GCC_ARM -m MTS_MDOT_F411RE --profile mbed-os\tools\profiles\debug.json
Error I get once the MDot runs the application:
Timer 0x20006670 error -3: Resource not availableThanks,
Ajay -
AuthorPosts