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

[Karoly Molnar]

Hi

In order to test this update I need to know which autopilots (which micros) are using luftboot. I am aware of LISA-M, but is there anything else? The reason I am asking is because the change might be hardware dependent. So it would be good to test on all potential targets before it is merged.

Regards
Karoly

---

From: address@hidden
To: address@hidden
Date: Tue, 1 Oct 2013 22:21:43 +0300
Subject: Re: [Paparazzi-devel] lisa - m upload problem

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: address@hidden [mailto: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