fdMonitor only works sporadically

Legato Application Framework
14

After countless attempts it seems like I successfully downgraded it by using the one-click tool from https://source.sierrawireless.com/resources/airprime/software/wp76xx/wp76xx-firmware-release-12/ (…at least the tool didn’t throw an error).

image
image466×812 11.9 KB

Then I upgraded it again to 16.3 using the one-click installer from https://source.sierrawireless.com/resources/airprime/software/wp76xx/wp76xx-firmware-release-16,-d-,3/

image
image453×807 11.9 KB

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…

image
image546×806 11.9 KB

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.

15

but you don’t see problem with another new chip for softreset and hardreset, right?
If so, problem only happens on this particular old module.

Not sure if this can revert your old module back to default state: (be careful of the mtd number)

16

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.

17

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?

18

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.

image
image967×236 11 KB

19

did you try this yocto cwe?

20

No, I haven’t tried that yet.

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?

image
image985×115 4.46 KB

21

maybe you try the test build first

22

Ok, so I flashed the device with release 16.0.1 GENERIC via the Windows one-click-tool.

image
image571×993 17.4 KB

Then I downloaded the swiflash tool from http://downloads.sierrawireless.com/tools/swiflash/swiflash.zip and ran swiflash -m WP76xx -i yocto_wp76xx.4k_msm_serial_hs.cwe which (after the second attempt) resulted in the following log.

image
image525×992 15.1 KB

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.

image

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…

image

We then tried your UART_Test1 application by removing all apps first and then flash your app.

image

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.

image
image1115×749 36.9 KB

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.

image
image1020×326 14 KB

23

can you paste the ati8 here?

As said before, you cannot use " swiflash -m wp76xx -r " in new memory module with any FW or old memory module after R12.

If you need to erase the userapp partition, you need to use this:

24

image
image921×176 5.5 KB

If we restart the app, UART works again (as mentioned in the original post with the watchdog).

Ah yes, you are right, I forgot about that. However, after clearing the user partition, the error remains the same.

25

seems you are not using my yocto image “yocto_wp76xx.4k_msm_serial_hs.cwe”, the yocto build time should be december 2022…

26

Reflashed it

image
image932×198 5.51 KB

Now I don’t even got data with cat < /dev/ttyHS0 :frowning:
Baudrate was wrong. Now we get something with cat < /dev/ttyHS0. Will try, if the application also gets data.

27

Error still exists. Even microcom doesn’t work anymore after the application ran and was stopped again.

image
image1506×772 34.7 KB

28

I don’t see the error
Is that you cannot receive uart data sometimes?

29

Yes, that’s exactly the problem. There’s no error shown, just nothing received anymore.

30

Then is the cts changing state?

You can see my app is changing the state of cts pin by ioctl()

31

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.

32

I want to know if ioctl() still works while rxd pin cannot receive data

BTW, if you microcom only instead of legato application, will you see the issue that no data can be read sometimes?

33

As mentioned here, microcom didn’t work properly anymore after the application ran.

As a different solution, we tried to simply run a Shell script as an application

sandboxed: true
start: manual

bundles:
{
    dir:
    {
        ${LEAF_WORKSPACE}/workspace/CL_Agent/requiredFiles/bash-uart /
    }
}
requires:
{
    dir:
    {
        /bin /bin
    }

    device:
    {
        [rw] /dev/ttyHS0 /dev/ttyHS0
    }
    
}
processes:
{
    run:
    {
        ( sh /bash-uart/bash-uart.sh )
    }
}

#!/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:

  1. Step: Ran the script directly with sh ./bash_uart.sh. Outcome: All data was received.
  2. Step: Started the Shell script via app (app start bash_uart). Outcome: The script was started but no content was received or displayed.
  3. 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.