LGA DevKit+EXS82-W start application "Unknown error" problem. And what is at^susrw ? | Thales IoT Developer Community
June 24, 2021 - 11:27am, 9815 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,
My is actually 124, the one provided with 48B is 118, so I still need to update the bootloader and the firmware together, accordinly, right?
BR,
Joefy
Could you write how exactly you read this value?
Hello,
Yes sure. I had a call with a Thales engineer, and through ATI1, we got the result as I mentioned before. And apparently he has a table, says which bootloader, what version... and together these information, you can know 36A, or 48B, or sth else. That's all I know.
BR,
Pinying
I'm sorry, I didn't express myself clearly - I meant how you get the bootloader version. But anyway if a Thales engineer advised you everything should be fine. I can add that having the correct gwinswup version (the executable that updates the firmware) you can safely update 36A to 48B which is currently the latest and recommended version for embedded processing. And this gwinswup version depends on the bootloader installed on the module (which is not updated with this gwinswup program). That is why for the particular firmware version there can be more than one updating executable for different bootloaders.
ATI1 returns the official firmware version and indeed it can be mapped on the values like 36A or 48B. I asked about how you get the bootloader version from the module to be sure that the number you read is correct. But if you have consulted all this with a Thales engineer everything should be fine. There's no need to continue here.
Best regards,
Bartłomiej
Hello,
He haven't replied for a week, so I was thinking maybe you can also help me. I was doing exactly what the instruction said and from what you told me. But it failed again, after download the new bootloader, it just decided to reenumerated USB ports and I lost the connection with the module. And I can not download the firmware version.
Here is what I got:
Really, I don't know what to do, and what's the problem. I am doing exactly what the instruction told me, and didn't interrupt this operation. Without the module, I literally cannot forward my work.
I'd appreciate any kind of help.
BR,
Joefy
Hello,
In my previous post I wrote you about Windows tool for firmware update. Now I see that you use the usf files from SDK package. Seems like the bootloader update succeeded. Please reboot the module and check it it works. It looks like the port is not available. Honestly I have never tried this kind of update. I'd need to consult. I don't know which version uf usf file is there, I mean for which bootloader version. Didn't you also get the swup folder with gwinswup programs and usf files grouped by the bootloader version?
BR,
Bartłomiej
Hello again,
I checked the SDK package for 48B and found out that the firmware which is placed in the SDK/firmware folder is appropriate for the bootloader version 107 or lower. So now if your bootloader is 118 you need a different firmware usf file. Please let me know if you also have received swup folder and can find the appropriate firmware file. If not I can send you the right usf.
Best regards,
Bartłomiej
Hello,
Yes, so now the bootloader in my module is 118, but I don't have other version of the firmware and I don't know how to update if now I cannot connect to the PC?
BR,
Joefy
Hello,
The thing is, I have tried Windows before, but probably the unzip process sth went wrong, when I tried to build the example application, it kept failed, so I changed to Linux. And I do exactly what the instruction said, so I really don't know what to do now if the module's port has been reenumerated, and could not connect with the PC. I reboot the module and its still the same (I hope you mean reset button? Let me know if it's not). As for gwinswup, I have this file but I am not using windows, besides, the instruction didn't mention how to update the module this way.
And yes, the port is not available right now, before has ASC0/1, and USB0; after update, only USB0; and we can't make USB0 connect.
If you got any reply, please let me know, I'd be very grateful. Thanks!
BR,
Joefy
Hello,
It looks like there can be no valid firmware on the module after you tried with the wrong version. In that case the module starts in the firmware upload ****. The firmware can be loaded with the option 'no firmware in module'. Python script probably doesn't support this **** as I see. You can use gwinswup tool with the proper option checked or glinswup (which is also used by the Python script). If you have gwinswup you should probably also have the right usf file in the same folder - you could use it with glinswup. Please run glinswup with -h flag for help.
I'll send you the document which contains the information how to proceed in such a case. It only describes gwinswup usage but general rule is the same. Please see 'Troubleshooting gWinSwup' chapter.
Best regards,
Bartłomiej