Persistent flash problems with littleFS in 1.20.1.r1
-
Running a gpy extended test, getting ValueError: syntax error in JSON when we try to import JSON about 1 in 10 trys.
- Am I right in thinking that indicates the part of flash where the JSON lib is stored is dodgy?
- Would pycom-fwtool-cli.exe -p COMxx erase_all then a 1.20.1.r1 reload maybe help or is it simply that littleFS is just as flawed as FAT was on these devices?
-
@jcaron I misunderstood the 'syntax error in Json' message. I thought it was referring to a syntax error in the json library we import but I now realise it was referring to the json packets from the server that library decodes. I think my problems are down to the lte getting into a state where it reports connected but can't run data. It seems my only option to fix this is a machine.reset() since trying to reset the modem fails with an OSError (because it thinks its in a data state) and I can't disconnect it (with a view to resetting it) because that gives an OSError too.
-
@kjm I'm a bit perplexed... You initially mentioned a problem with importing files from the FS, now the files come from a server... It's quite difficult to trace the origin of the problem if we don't know what you are doing exactly (ideally with the relevant code, logs, and data). IMHO, despite all the issues one can face with the Pycom devices, it's still more probable that the issue is in your code (on the server or on the device), especially with failures rates of 1 in 10, even more so if you're not using any kind of deep sleep.
As for errors, don't shoot the messenger. Communication (especially wireless) WILL lead to errors due to lost packets and connections.
-
JSON is an awfull fiormat. There is no way to mark which data type your numbers have. So you will run quite often into parsing problems.
Python is an awfull language, if you have to run it on small machines. If you do a lot of string operations you have to deal with memory fragmentation. Depending on the messages you parse, there may be no part of free memory which is large enough to keep buffers requested by the OS.
The second problem is not easy to solve. Either it will help to dispose as much as you can and call the GC before your JSON parsing or you have to redesign the whole program and write your own libs which don't use Pythons string operations. Avoid floats where ever it is possible. They work in the same way as strings, but will fragment your memory much faster.
I suggest to check first, if you can figure out if there are messages which runs and which fails every time. So you can debug much faster. Check than your JSON parsing on a huge machine, so you will not run into memory issues. If it is a memory problem, keep the JSON as short as possible -> short property names and as few whitespace as possible. If you need human readable JSON, use an editor which can do nice formatting. You cannot defragment your memory. Someone started to work on this, but it stucked in an early stage. Either you finish this project or you have to find a good time for a reboot.
-
@jcaron The JSON is coming down from a server which also uses non JSON replys on occasions. I tried to get a peek at self.content in requests to see the malformed JSON but when the reply isn't in JSON format it throws an error that it can't convert a byte array to a string. Thinking of going back to my old strategy of rebooting the device if a request fails. Trying to chase down all the errors requests throws is doing my head in. I've never seen a library with such a repertoire of woes, OSError: [Errno -76] MBEDTLS_ERR_NET_RECV_FAILED, OSError: [Errno 113] ECONNABORTED, OSError: [Errno 118] EHOSTUNREACH, [Errno 202] EAI_FAIL, OSError: [Errno 666] YOU WANT DATA, SAY PLEASE,.....
-
@kjm start by printing out the raw JSON when the error occurs (or even always). You can then copy-paste the JSON in any JSON validation to find out what is wrong.
How are you generating the JSON? “Manual” assembly of JSON seems easy, but always ends up in trouble. Always use a JSON library to generate JSON, if you didn’t.
-
@jcaron I've just realised it's not the imported ujson library that has the syntax error it's the JSON it's trying to process, so this isn't file system related at all. How exactly do I log the contents of the JSON so I can see where the problem is? The usual stuff ( like ack=r.json()['msg_type']) I use to check JSON isn't going to work because the JSON has errors.
-
@kjm When you upgrade from a previous version, like 1.18.x to 1.20.1, going through a flash erase is advisable. Without erase there were problems reported with NVS and WiFi.
-
@kjm You should probably give more details as to what your test actually does. Also, logging the contents of the JSON which triggers the error would probably be a good idea.
