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

[Karoly Molnar]

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