After that the device didn’t ask me to set a password and even the command history is still available… So I guess it was not reset at any point.
So I repeated the downgrade to R12 procedure, ran swiflash.bat -m WP76XX -r (yes, I also tried swiflash.bat -m wp76xx -r) and ended up with the same error…
So the error that the UART is not working properly after a soft-reset still exists. So once again I’m asking, is there something the gets removed on a hardreset? Otherwise I don’t so a reason, why it works after a hard- but not after a soft-reset.
Yes, we also see it on new chips. At least if the chip is flashed on my colleagues machine. Could it be a problem if the device is not restarted properly after the update (e.g. by just pluging out the supply)? The issue might be a problem with our software, however, if we cannot reset the device to a clean state, we cannot find out at which point the system gets corrupted. Resetting it to the version 10.1.0.1 (https://source.sierrawireless.com/resources/airprime/software/wp76xx/wp76xx-firmware-release-10,-d-,1,-d-,0,-d-,1/) also didn’t help.
I think using swiflash to reset to factory state cannot work for your module in old FW like R12.
(i guess it is because your module is using new memory)
Have you tried this?
But if you can also see this issue in new chips, then that means it is not related to default state.
Have you isolated if this is related to legato?
Can you take a new module and run with pure linux application compiled by the toolchain instead of legato application?
Just to give an update on this topic. We got a little bit further. We have two devices of which one is sending data to the Sierra Wireless via UART. If the services that send the UART data are shut down and the WP76xx is rebootet, UART works flawlessly but if the services are running, something seems to happen with the Sierra’s UART but we haven’t figured out what yet. It might be some control character problem because sometimes we receive something like “^M” as character. I don’t know but it’s very strange. Is there a plan to update the Kernel any time soon? Because we are using completely new devices which still run on Kernel 3.18.140 which is heavily outdated and seems rather buggy to me.
What does that mean? Because that’s what we get before the UART stops working. Not sure if it has any relation to the issue, just asking. Is it just an information, that the interrupt was triggered?
Then I ssh-ed onto the device but app status returned exactly the same status as before (the grayed-out apps are ours). Nothing changed.
Then we setup a Raspberry to use it as a flashing device with pure Linux instead of WSL on Windows, which raised this error message when trying to reset the device by running swiflash -m wp76xx -r. Both USB ports on the MangOH red board are connected, the flash process starts but still it fails to flash the image…
We then tried your UART_Test1 application by removing all apps first and then flash your app.
We started the app, sent several UART messages and encountered exactly the same issue that at the beginning some messages are being received and then suddenly it stops working.
From our point of view at this point the device clearly is broken but we cannot reflash it to the default state as described above. Also, if we stop the app and do cat < /dev/ttyHS0 the Kernel panics after some seconds or if something is sent via UART it panics immediately and the device is being restarted.
Now I don’t even got data with cat < /dev/ttyHS0
Baudrate was wrong. Now we get something with cat < /dev/ttyHS0. Will try, if the application also gets data.
I don’t get the point. What do you mean? In which way does that change the current behaviour? Nothing is received after a while and I don’t think it’s related to the CTS/RTS pin, since we don’t have one.
#!/bin/sh
stty -F /dev/ttyHS0 115200
echo "----------> started UART"
while read -r c; do
echo $c
done < /dev/ttyHS0
We also put this script manually into the home directory to check if it works, if we execute it directly, not from within the app.
This was the procedure:
Step: Ran the script directly with sh ./bash_uart.sh. Outcome: All data was received.
Step: Started the Shell script via app (app start bash_uart). Outcome: The script was started but no content was received or displayed.
Step: Stopped the app and ran sh ./bash_uart.sh again. Outcome: Sometimes it didn’t work at all, sometimes some characters were missing. After some restarts it works again (only if executed from the home directory).
The local shell script always worked if the app was not involved.
So even with this small script, there is something off. There must be something in the Framework that completely tilted which can only be cleared by a hard-reset.