LGA DevKit+EXS82-W start application "Unknown error" problem. And what is at^susrw ? | Thales IoT Developer Community
June 24, 2021 - 11:27am, 10766 views
Hi,
I am currently working on module EXS82-W together with LGA DevKit, driver is Ubuntu 20.04. After setting up software environment required and check the firmware, I started to manage embedded applications.
I follow the user guide of SDK, build the application, generate the application root of trust and sign it to the application, verify it, download the signed application to the target. Then, I opened another terminal window to start listening. But when I tried to start the application, it always shows "Unknown error, failed!" (as the sceenshot shows).
I have tried many different ways,
1) Go through app.py and Ctrl+f find this error, it didn't mention; but very interesting thing is there is a line in app.py:
if c.send('at^susrw=1,"A:/' + sargs.APPNAME + '.bin"') == STATUS_KO:this AT command, I couldn't find any related infomation online or from the EXS82 ATC document.
2) Change to the other application, helloworld, logging... still the same problem
3) Change the module, still the same problem
4) Thinking maybe it's because the FW is newer than the one in the archive, so we "updated" back to 118 from 124, new problem is when I type lsusb in terminal window, it's not Cinterion but Qualcom, and it couldn't connected, only port /dev/ttyUSB0
5) Check .bin file's permission, enable it, but still same error.
I'd appreciate any kind of help.
Thank you and best regards,
Joefy
Hello,
The thing is, even I have tried the wrong version, it's inside the 48B folder, I don't understand why it can went wrong. And thank you fot sharing the update documents, I didn't know that exists before.
I have tried what you recommended, restart, 'no firmware in module', different baud rates, but they all said module update failed.
It was like this:
[2021-07-12 15:25:35]Initializing firmware update...
[2021-07-12 15:26:04]WARNING: AT-Command-Mode not detected (trying fall back with 115200)!
[2021-07-12 15:26:11]ERROR: Cannot send update command!
[2021-07-12 15:26:11]Module update failed
[2021-07-12 15:26:28]
[2021-07-12 15:26:28]Initializing firmware update...
[2021-07-12 15:26:34]ERROR: Cannot send update command!
[2021-07-12 15:26:34]Module update failed
And all this update method, I assume it's based on the module already connected to the PC with tool connect.py? But my problem is, after reenumerating the port by the python update tool, I can see from device manager that it still has one port, but I cannot connect PC with module through this port, which means it cannot send AT commands to the module.
And, I don't have the usf file under the same folder. I have a folder named SWUP, then two folders inside, BL112OH and BOOTONLY, open them, one is EXS82-W_SERVAL_300_048B_sign02prod_ep, and another is EXS82-W_rev00.022_arn01.000.01_SERVAL_300_048B_sign02prod_e_bootonly. Is this right?
Maybe you know more about this situation? Thank you ahead for your help.
BR,
Joefy
Hello,
In your log it looks as if the tool is not running in the 'no firmware in module' **** as it tries to send the update command.
If the firmware is not working and the module is in the firmware upload **** it can't reply to AT commands but it is already in the firmware upload ****. So the firmware upload tools should not try to send any commands, just start uploading the firmware.
If you use gwinswup or glinswup you should not use the Python script. In case of Windows just reboot the module (try to power it down and up to be sure) start gWinSwup, check the option, select the port and start. Try on ASC0 just after the module starts. If no success please also check on USB. Please use the files from BL112OH folder.
BR,
Bartłomiej
Hello,
Thank you for your reply. I have tried to power off and up the module and tried on ASC0, but still the same log. When I try USB, it says:
ERROR: Cannot open COM-Port!
It makes sense, cause after the reenumerate the ports, when I connect with native USB interface, and check device manager, I couldn't find any com port.
As for what you said 'just start uploading', you mean directly use the application? And by saying 'power it down and up', you mean the module? I do it by changing the power supply switch, is it OK?
BR,
Joefy
Hello,
There ***** to be a USB port visible in device manager. Otherwise gwinswup will not connect.
ERROR: Cannot open COM-Port! may mean that there is no such port number in the system or the port is open in another application.
As for ASC0 you need to plug the cable to ASC0 on the board and have the ASC0 switch set to USB. There should also be jumpers installed in ASC0_A section.
Normally gwinswup send AT commands to the module after start to switch to the firmware upload ****.
When the option 'no firmware in module' is checked gwinswup should not do that but start the firmware upload.
You may use the power supply switch or unplug the board. After powering up again you need to press 'ON' button.
BR,
Bartłomiej
Hello,
Thank you for your answer, that's really precise. But that's exactly what I have done. I am using ASC0, and have the ASC0 switch to USB, the jumpers already installed in ASC0_A section. To power down and up, I use the power supply switch, and then press the "ON" button.
And you mentioned the gwinswup send AT commands, means it's already in the firmware upload ****, right?
That's what I have tried so far. Is there anything I can try or any opinion?
BR,
Joefy
Hi Joefy,
As I'm taking over ****rating from Bartłomiej for a time, let me get more familiar with your setup.
Could you tell me who's your Thales contact person and from which source have you downloaded our Embedded Processing SDK for EXS82-W module?
Regarding your question, in general if the "No Firmware in Module" option is selected in gwinswup utility then no AT commands should be sent by the updater - as the module boots into a special FDL (Firmware Download) **** it won't respond to any commands and simply waits for firmware data. However, our EXS82/62 modules expect one command to be sent in their "No Firmware in Module" ****: AT^SFDL. This triggers update procedure.
In your case it seems like the bootloader might have gotten corrupted and therefore your module fails at further updates. The USB port that you see in Windows, is it enumerated as "Qualcomm HS-USB QDLoader 9008"?
BR,
Ida
Hello,
I was contacting with MARGO Hervé, who sent me the SDK 48B folder. And I was using everything provided in the folder and the what the instruction said.
I don't know how to check it in Windows, in device manager it just says USB serial port. And I change to Linux, if I connect through ASC0, it's
Bus 001 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
And if I change to native USB, before I update the FW, I saw Cinterion, and now, it's:
Bus 001 Device 006: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL ****).
Do you have any idea or thoughts about this situation? Thanks!
BR,
Joefy
Hi Joefy,
Thank you for those details. Since the bootloader got corrupted on your module, it boots up in a chipset fallback **** that cannot be managed by gwinswup utility or the SDK tools. To fix this issue, your Thales contact will reach out to you shortly regarding further steps which we can propose.
BR,
Ida
Hello,
I have received the new module, and here is the firmware info:
Modem version (rev): 01.200
Applicative version (arn): 01.000.01
Bootloader version (sbl): SBL1_125
Is it the latest version? Since before, the way through python tool is wrong file, how should I update the firmware?
And another question, when I try to start the example application, it returns CME ERROR: 767. It means "operation failed", do you know what might be the cause?
Best regards,
Joefy
Hi Joefy,
Rev. 01.200 ARN 01.000.01 is currently our latest firmware dedicated for embedded processing on EXS82, so there's no need to change it. We are currently reviewing our SDK archive to update it with proper files so for now please don't use USF files that were part of your SDK.
Regarding the application issue, let me check if I can get more information regarding this error code. One question though: have you verified your signed application against the public key of your root of trust? Did this verification pass? Also, did you load your root of trust certificate on this new module successfully?
BR,
Ida