Re: [Paparazzi-devel] lisa - m upload problem

[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...

See https://github.com/paparazzi/paparazzi/issues/415

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
Sent: Tuesday, October 1, 2013 10:39 PM
To: Paparazzi devel list

Subject: Re: [Paparazzi-devel] lisa - m upload problem

 

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
Sent: Tuesday, October 1, 2013 7:53 PM
To: address@hidden
Subject: Re: [Paparazzi-devel] lisa - m upload problem

 

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

I have studied the paparazzi boot loader earlier when I have modified it to add a CAN gateway. It was some time ago but I think the information below is still relevant.

First, I would like to re-phrase your wording. In the boot loader terminology upload always refers to the device-->programmer direction and download is the programmer-->device direction. So when you program the flash of the micro it is actually a download, not upload as you call it.

My findings are that:
1. The upload is not implemented in the DFU part of the boot loader code.
2. There is no local verification if the flash memory value of the programmed bytes (or half-words) are matching the intended data.
3. There is no MD5 or any other checksum implemented in the boot loader code.

As I see option 2 would be the simplest to implement, this would at least provide certain level of protection against code corruption. It is a kind of immediate comparison of the indtended 16bits value to the value read back from Flash after programming. It could still go wrong, if a broken programming algorithm is changing other address locations besides the intended one, which might not always be recognized by the simple read-back-compare in the boot loader.

Option  1 a nice to have feature that provides high certainity of the download quality at the expense of a relaitively large code. It is also slower due to the upload time, but it is not extreme so might be tolerated.

Option 3 in a form of a CRC could be actually implemented. Two typical solution exists.
3.a One is when the programmer sw calculates a crc or checksum and requests the device to do the same for a given address range then send back the calculated CRC. The programmer can then decide if the values are matching. This is the most common implementation. 
3.b Another option is if the boot loader itself calculates the CRC on the fly both for the received data (on the RAM buffer) and it compares this value locally to the programmed data (either on the fly or after all data has been downloaded).

If any, I would vote for option 3.b because this requires practically no modification in the download protocol and could be implemented with relatively small code change and this is still faster than reading back the complete code to the PC and compare it there.

I can provide a patch for option 2 or 3.b (the latter may take more time to implement and test) if anyone is interested.

Regards
Karoly

---

From: address@hidden
To: address@hidden
Date: Mon, 30 Sep 2013 22:02:03 +0300
Subject: [Paparazzi-devel] lisa - m upload problem

 

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

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

 

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

 

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel