Ajay K

Forum Replies Created

Viewing 30 posts - 61 through 90 (of 302 total)
  • Author
    Posts
  • in reply to: MDot 4.0.1 library compilation warning in mDotEvent.h #31233
    Ajay K
    Participant

    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,
    Ajay

    in reply to: MDot 4.0.1 library compilation warning in mDotEvent.h #31232
    Ajay K
    Participant

    Thanks 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,
    Ajay

    Ajay K
    Participant

    Thanks Jason as always for the clarification.

    in reply to: Logging Levels for MDot Library 4.0.1 #31228
    Ajay K
    Participant

    Thanks Jason, I missed the “ifndef NDEBUG”. Thanks a lot for your inputs.

    Thanks,
    Ajay

    in reply to: Logging Levels for MDot Library 4.0.1 #31226
    Ajay K
    Participant

    Hey 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,
    Ajay

    in reply to: Logging Levels for MDot Library 4.0.1 #31224
    Ajay K
    Participant

    Hi 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,
    Ajay

    in reply to: Do the User register values stay intact thru' power cycles. #31221
    Ajay K
    Participant

    Any thoughts on this? Is the User Register values stored on the internal MDot flash or MDot RAM?

    Thanks,
    Ajay.

    in reply to: Logging Levels for MDot Library 4.0.1 #31220
    Ajay K
    Participant

    Any 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,
    Ajay

    Ajay K
    Participant

    This 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,
    Ajay

    Ajay K
    Participant

    Any 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.

    Ajay K
    Participant

    Its 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,
    Ajay

    Ajay K
    Participant

    Hi 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,
    Ajay

    Ajay K
    Participant

    The 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-NF

    Thanks,
    Ajay

    Ajay K
    Participant

    Thanks 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,
    Ajay

    Ajay K
    Participant

    Any thoughts on why this issue is occurring and how this can be resolved?

    Thanks,
    Ajay

    Ajay K
    Participant

    If 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 firmware

    Ajay K
    Participant

    Thanks 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,
    Ajay

    Ajay K
    Participant

    Thanks a lot Taylor for your help, the issue is resolved now.

    Thanks,
    Ajay

    Ajay K
    Participant

    Thanks 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.bin

    The 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.bin

    Thanks,
    Ajay

    Ajay K
    Participant

    Any thoughts, this issue is blocking us from testing 4.0 mdot library.

    Thanks,
    Ajay

    Ajay K
    Participant

    Thanks 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,
    Ajay

    Ajay K
    Participant

    Any thoughts on the compilation error I am getting when compiling a custom firmware in the online compiler?

    Thanks,
    Ajay

    Ajay K
    Participant

    I 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,
    Ajay

    Ajay K
    Participant

    Jason, 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,
    Ajay

    Ajay K
    Participant

    Thanks 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,
    Ajay

    Ajay K
    Participant

    Thanks 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,
    Ajay

    Ajay K
    Participant

    Hi 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.

    Ajay K
    Participant

    Hi 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,
    Ajay

    Ajay K
    Participant

    Have 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.

    Ajay K
    Participant

    Hi 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 available

    Thanks,
    Ajay

Viewing 30 posts - 61 through 90 (of 302 total)