Issues with Downloading firmware


I’m running an embedded Linux, with kernel 3.10.104 on an arm processor. I’ve compiled both the slqssdk and the fwdnld as well as the fwdnldLite exe. If I run the fwdnldLite from the command line, I can successfully download new firmware to an EM7455. If I run it via a system call in a C application, it starts, but stops during the download process and hangs, never to return. I’ve tried running it with different permissions, and also calling a shell script instead of calling it directly, but nothing seems to work. Once the same firmware is installed, subsequent calls in any method (direct or through the app) won’t hang, but doesn’t download to the device saying it already has this version.
I’ve also tried running the full version that needs the slqssdk, but that ends with SWI API: SDK launch failed: Permission denied. The slqssdk has 777 permissions, so it shouldn’t be a permission problem. I’ve tried running it root on the command line, with no success.

I’m at a loss here. Any help would be appreciated.



Hi @Evets
Check the logs for the lite-fw-download for the working and non-working case to see what’s different. You can also run with options “-l /path/mylog.txt -e 1” and compare the 2 cases. I’m guessing it maybe something to do with the QDL port access.
slqssdk needs elevated privilege to access the ports/device files. “Firmware_Download” has been used via system calls successfully.


Hi @ajoseph,
Thanks for responding. I tried that…
In the case where it’s run from my program, it fails the “send Hello” step and receives a response that has an unknown header : 15.
It then tries to fallback on FIREHOSE and then proceeds to get stuck.

Any particular reason it would fail that step?



I’d check if the QDL port is being picked up correctly. The lite-fw-download tool will identify the ports automatically (not sure when this was added, I’ve tested 4.0.14) but you can try passing the port as well via command line. Since it’s EM7455, I assume you have .cwe and .nvu in one folder and you’re passing the folder path to the tool. Some logs will be useful.


Hi @ajoseph,
Yes, I call this with -d /dev/ttyUSB0 and it both cases, whether run from my program via a system() call or via the command line, the command is the same. If the files aren’t there or the path is bad, it will exit out before it goes any further.