I have rebuilt the kernel to get SFTP up and running (Yocto, cURL and SFTP), httpGet is up and running for connection verification, and…
The log shows the data is received, no errors. I connect to every possible link (console, Linux app, etc), no data out. Even the printf’s go straight to log, no console output. AT!MAPUART does not have any useful effect.
Platform is 17.10 on a MangOH Red. I’m obviously missing something - how do I send data from (or to) UART 1?
This post helped me get my UART1 working. My problem was with how the RX and TX are labelled. The pin labelled RX is the TX on the CF3 module and vice versa. That post also includes some things to try regarding the dip switches, it is hard to say whether they helped or not because I had the RX and TX around the wrong way…
Looks like things are going to a whole new level.
I was using the sample app httpGet to test access. Something is going wrong.
Again, it is a MangOH Red, attempting a cell data connection to a remote site. When I start the app attempting to access the basic location (https://httpbin.org/get) it works fine and repeatably. When I re-install attempting to access https://test.boater.tech/v1/hello, the access fails, and (after that) even dropping back to the original site fails consistently. The attached file are the logs from the attempts.
Note that the site above does exist and is accessible from a normal browser. The only recovery I have found is to re-flash the memory with the latest firmware.
Another note - I went ahead and dropped back to the release firmware, not the build with SFTP and newer libcurl support.
There is a supervisory stop in the log, where I stopped the app prior to downloading a new version.
Logs
SierraWirelessLogs.txt (8.0 KB)
List
Is there anything earlier in the logs that indicates why the supervisor is stopping the app?
Is your app sandboxed? An easy thing to try is to set sandboxed: false in your adef and see if the problem goes away. If it does, then you’re likely having problems accessing some sort of resource due to sandboxing.
The sbtrace tool can help you discover if your app is requesting filesystem resources that it can’t obtain.
Another good tool is running strace on the process that is failing. I started to write a lengthy forum post, but I decided to write it down in the mangOH wiki instead. The wiki page: Debugging sandboxed Legato apps using strace · mangOH/mangOH Wiki · GitHub
Apologies for the long delay - got pulled onto another project.
The reason for the supervisor stop is I stopped the app to download a version that referenced a different site - no other changes.
Sandboxing is not specified - I’ll add your change.
That still leaves the question - why does changing the site referenced, which actually sends less data than the original sample site, break the system to the point that even loading the httpGet app again referencing the original site still leaves the system so broken it must be reloaded. Not just the httpGet app, Legato as well.