lisa - m upload problem

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

lisa - m upload problem

refik

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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: lisa - m upload problem

Karoly Molnar-3
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: [hidden email]
To: [hidden email]
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 [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: lisa - m upload problem

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 <[hidden email]> 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: [hidden email]
To: [hidden email]
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 [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: lisa - m upload problem

refik

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=[hidden email] [mailto:paparazzi-devel-bounces+refiksever=[hidden email]] On Behalf Of Michal Podhradsky
Sent: Tuesday, October 1, 2013 7:53 PM
To: [hidden email]
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 <[hidden email]> 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: [hidden email]
To: [hidden email]
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 [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

 


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: lisa - m upload problem

flixr
Administrator
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 <[hidden email]> 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=[hidden email] [mailto:[hidden email]=[hidden email]] On Behalf Of Michal Podhradsky
Sent: Tuesday, October 1, 2013 7:53 PM
To: [hidden email]
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 <[hidden email]> 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: [hidden email]
To: [hidden email]
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 [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

 


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: lisa - m upload problem

refik

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=[hidden email] [mailto:paparazzi-devel-bounces+refiksever=[hidden email]] 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 <[hidden email]> 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=[hidden email] [mailto:[hidden email]=[hidden email]] On Behalf Of Michal Podhradsky
Sent: Tuesday, October 1, 2013 7:53 PM
To: [hidden email]
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 <[hidden email]> 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: [hidden email]
To: [hidden email]
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 [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

 


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

 


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: lisa - m upload problem

flixr
Administrator
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 <[hidden email]> 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=[hidden email] [mailto:[hidden email]=[hidden email]] 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 <[hidden email]> 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=[hidden email] [mailto:[hidden email]=[hidden email]] On Behalf Of Michal Podhradsky
Sent: Tuesday, October 1, 2013 7:53 PM
To: [hidden email]
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 <[hidden email]> 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: [hidden email]
To: [hidden email]
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 [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

 


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

 


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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=[hidden email] [mailto:[hidden email]=[hidden email]] 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 <[hidden email]> 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=[hidden email] [mailto:[hidden email]=[hidden email]] On Behalf Of Michal Podhradsky
Sent: Tuesday, October 1, 2013 7:53 PM
To: [hidden email]
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 <[hidden email]> 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: [hidden email]
To: [hidden email]
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 [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

 


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

 


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: lisa - m upload problem

refik

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: paparazzi-devel-bounces+refiksever=[hidden email] [mailto:paparazzi-devel-bounces+refiksever=[hidden email]] On Behalf Of Stephen Dwyer
Sent: Wednesday, October 2, 2013 2:40 AM
To: [hidden email]
Subject: Re: [Paparazzi-devel] lisa - m upload problem

 

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 <[hidden email]> 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 <[hidden email]> 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=[hidden email] [mailto:[hidden email]=[hidden email]] 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 <[hidden email]> 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=[hidden email] [mailto:[hidden email]=[hidden email]] On Behalf Of Michal Podhradsky
Sent: Tuesday, October 1, 2013 7:53 PM
To: [hidden email]
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 <[hidden email]> 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: [hidden email]
To: [hidden email]
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 [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

 


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

 


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

 


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

 


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: lisa - m upload problem

Karoly Molnar-3
In reply to this post by refik
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: [hidden email]
To: [hidden email]
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: paparazzi-devel-bounces+refiksever=[hidden email] [mailto:paparazzi-devel-bounces+refiksever=[hidden email]] On Behalf Of Michal Podhradsky
Sent: Tuesday, October 1, 2013 7:53 PM
To: [hidden email]
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 <[hidden email]> 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: [hidden email]
To: [hidden email]
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 [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

 


_______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: lisa - m upload problem

flixr
Administrator
Hi Karoly,

AFAIK, Lisa/M, Lisa/S and Lia (basically the same as Lisa/M with different connectors) use luftboot.

Cheers, Felix


On Fri, Oct 4, 2013 at 12:54 PM, Karoly Molnar <[hidden email]> wrote:
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

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: paparazzi-devel-bounces+refiksever=[hidden email] [mailto:[hidden email]=[hidden email]] On Behalf Of Michal Podhradsky
Sent: Tuesday, October 1, 2013 7:53 PM
To: [hidden email]
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 <[hidden email]> 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: [hidden email]
To: [hidden email]
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 [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

 


_______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel