so trying to flash some new code is resulting in an error, which doesnt say much about why it failed
fwupdate download yocto-legato_wp85.cwe 192.168.2.2
Connecting to service …
Connecting to service …
Download started …
Error in download
I suggest running logread -f on the target before running fwupdate on your build machine. That will allow you to view logs that will probably indicate the failure that is occurring.
ok did the recommended thing, only error i really see is below
Mar 26 20:03:53 swi-mdm9x15 user.err Legato: =ERR= | fwupdateDaemon[560]/swiQmi T=main | swiQmi.c swiQmi_CheckResponse() 813 | Sending QMI_SWI_M2M_FDT_SEEK_REQ_V01 failed: rc=-49 (x), resp.result=0.[0x00], resp.error=0.[0x00]
Mar 26 20:03:53 swi-mdm9x15 user.err Legato: =ERR= | fwupdateDaemon[560]/le_pa_fwupdate T=main | pa_fwupdate_qmi.c pa_fwupdate_Download() 1069 | Seek to offset 0 failed
Mar 26 20:03:53 swi-mdm9x15 authpriv.info dropbear[1237]: Exit (root): Disconnect received
Mar 26 20:04:11 swi-mdm9x15 authpriv.info dropbear[1279]: Child connection from 192.168.2.3:53752
Have you tried using swiflash or fdt2 instead of fwupdate? I wonder if this is an fwupdate issue or something deeper.
ive also tried swiflash like 10 times… also doesnt seem to ever get into firmware download mode
Ive got 2 mangos here, same image, 1 appears ok, the other doesnt, board boots and runs whats on it flashed previously ok, just cant seem to reflash it…
whats the usage of fdt … that ive not tried and where is it located?
Have you tried putting dip switch 7 in the up position and then pressing the reset button prior to running swiflash? That can help it to get started. Once it starts programming, flip dip switch 7 back down.
fdt used to be available on source.sierrawireless.com. For some reason, around the time that fdt2 came out, fdt was removed from source.sierrawireless.com and .exe files were provided for all of the official releases. It seems like lots of people still have fdt2 though. Maybe they are getting it through FAEs? Try what I suggested regarding swiflash and let me know if that works.
you cant remotely flip dip switches on deployed devices over the wire… seems there ought to be a more logical and ingenious way to remotely update complete spk firmware builds on the boards without breaking down infrastructure… luckily its on my desk so… ok ill try it, but what about when theres 100s of thousands deployed… ?? and no we cant use sierras cloud pretty mq interface to update them… and you know why…
Yes, I agree that remotely flipping dip switches is not possible. I also see that there’s a lack of guidance for people who wish to do remote firmware updates without using AirVantage. I’m making a mental note of that and I’ll try to bring it up with the right people when I get a chance.
No joy I cannot seem to flash this board for the life of me anymore… it simple seems to ignore the fact the board does reboot but never seems to recognize it in download mode or the boards not getting there… it boots and runs fine from what i can tell