|
| From: | Refik Sever |
| Subject: | Re: [Paparazzi-devel] lisa - m upload problem |
| Date: | Wed, 2 Oct 2013 09:46:05 +0300 |
Hi Stephen, Yes, we had successful flights with this configuration. As I wrote before, we did not change any configuration file. We only made "clean, build and upload" of the same configuration files. We had two crashes, then without uploading the new file, we checked on the ground that it really freezes when it switches to auto2. After that, we made "clean, build and upload" of same files, and now it successfully flies. If a similar error occurs again, I will check it with simulation, as you recommend. Best regards, Refik From: address@hidden [mailto:address@hidden On Behalf Of Stephen Dwyer Hello Refik, Just out of curiousity, have you had any successful auto2 flights with this configuration (airframe, flightplan etc). Have you simulated the flight carefully to make sure it is not a problem in the higher level code? In addition, is it possible to reproduce the problem in simulation or not? (You can try manual or auto1 by eliminating the -norc option in the sim - it is quite difficult with the little slider interface though....). Just some thoughts on further identifying the problem. Thanks, -Stephen Dwyer On Tue, Oct 1, 2013 at 3:27 PM, Felix Ruess <address@hidden> wrote: On upload it will first build the firmware. So if any dependencies changed (and assuming this was properly detected) it will recompile that part of the code and re-link. It's a bit to late to check now, but when you click upload and pay attention to the output you can see if and what parts get recompiled. If you want to be safe, clean before building or uploading. Unfortunately not every change is properly detected as changed dependency (e.g. with some of the indirect includes). Also if you switch between compiling sim and ap targets, it is always better to clean first. E.g. modules that are only valid for ap or sim are not properly unloaded unless you do a clean first. But usually you will immediately notice this since it won't build in most cases... On Tue, Oct 1, 2013 at 10:33 PM, Refik Sever <address@hidden> wrote: Hi Felix, We did not change anything in our airframe and the other configuration files in the two trials. Then, is it possible that the generated files be different from each other? I assumed that they are exactly the same, thats why I suspect on upload process. Best regards, Refik From: paparazzi-devel-bounces+refiksever=address@hidden [mailto:paparazzi-devel-bounces+refiksever=address@hidden] On Behalf Of Felix Ruess
Just keep in mind what Michal mentioned: We don't actually know if the the generated firmware file was correct the first time... it might just as well be the case that you changed some things but didn't properly rebuild it and the actual upload was working fine... On Tue, Oct 1, 2013 at 9:21 PM, Refik Sever <address@hidden> wrote: Hi Karoly, It would be great to implement the CRC. I am waiting for the patches :) It will also be OK for me to wait for the complete readback of the flash and check it on PC. Is the complete readback of flash memory from USB cable implemented? Readback from JTAG cable is another option but since the JTAG connector is in the middle, it is hard for us to connect the cable. @Michel: We added the preflight check of Manuel-Auto1-Auto2 switch to our check list. But, if the code is corrupted for different flight plan blocks, we may not detect it on the ground. That's why I want to be sure that the uploaded code is not corrupted. Best regards, Refik From: paparazzi-devel-bounces+refiksever=address@hidden [mailto:paparazzi-devel-bounces+refiksever=address@hidden] On Behalf Of Michal Podhradsky HI Karoly, CRC would be great. I actually thought there is some code checking already implemented. Although from Refiks comment it is not conclusive that the problem was a random error in the uploaded code, or the compiled code itself. Refik, for the time being, you might want to do some extra pre-flight checks like switch to Manual-Auto1-Auto2 and look at the ap response. That would tell you if your plane is safe to fly. Regards M On Tue, Oct 1, 2013 at 10:21 AM, Karoly Molnar <address@hidden> wrote: Hi Refik From: address@hidden Hello, Last week, we had a crash. We thought that it was due to interference from GSM base station. Today, we had another crash and we found that the two crashes were not due to interference. We flied with the same hex file uploaded to Lisa-M. During flight in auto1, there was no problem. When we switched to auto2, the autopilot again freezed. It was exactly the same behavior with the previous crash, which also happened when we switched to auto2. After the crash, we tested the autopilot on the ground. We send take off command in auto1, and then we manually switched to standby. When we switched to auto2, and it again freezed. After that, we re-build the same airframe file and upload the code. Now, everything is normal. It seems that it did not upload correctly. We are uploading the file using USB cable. Does it verify the uploaded file by reading it back? How can I make it verify the file? Is is possible that it uploads wrong and partially runs the code? If this is the case, doesn't the MD5 signature become wrong? Regards, Refik _______________________________________________ Paparazzi-devel mailing list address@hidden https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
|
| [Prev in Thread] | Current Thread | [Next in Thread] |