Remove "Board Recovery" section from datasheets of boards without feature

[per1234]

What This PR Changes

Some Arduino boards have a bootloader that allows them to be recovered from a "soft bricked" state by pressing the reset button twice.

The bootloader on the boards which do not have a native USB capability don't recognize this double reset. The reason is because the "soft bricked" state is specific to the native USB boards, so boards without native USB have no need for this recovery capability.

Previously, bootloader support for double reset was claimed for several boards which do not have such a bootloader. Since these boards do not have or need any sort of "board recovery" system, the "Board Recovery" section is removed entirely from their datasheets.

Contribution Guidelines

• I confirm that I have read the contribution guidelines and comply with them.

[karlsoderby]

@marqdevx @jcarolinares since this is in datasheet, I don't think I am the right person to review! Can you check this out?

[marqdevx]

I think this section does not only point to soft-bricked cases
Could be due to a sketch that has something weird going on, should it be better to reword it instead of deleting it?
@per1234 @aliphys @jcarolinares

[per1234]

Could be due to a sketch that has something weird going on

It is impossible for the sketch to interfere with the upload on the Uno, Mega, and Nano boards.

I'm not so knowledgeable about the Nano Every, but I am also not aware of any way it could interfere and I have never seen a single example of this happening. Even though it uses a different type of programming, the Nano Every is similar to those other boards in having a dedicated USB interface chip. By the nature of this design, the sketch program can't directly affect the USB chip.

Even if there was some rare case where resetting the Nano Every at the right time could recover the board from some state where the sketch is interfering with the correct functioning of the ATSAMD11D14A USB chip, the board does not have any special treatment of a double reset, and that reset would need to be timed very precisely, so the current information is false and harmful to the customers regardless. So I think it is better to simply remove it. If eventually we see that there is some case where the board can be soft bricked and recovered by some procedure, that accurate information can be added to the datasheet.

Information must be personally verified by the author before adding it to Arduino's documentation. Unless someone is able to verify that some recovery technique is available, such a section should not be present in the datasheet.

[jcarolinares]

Could be due to a sketch that has something weird going on

It is impossible for the sketch to interfere with the upload on the Uno, Mega, and Nano boards.

I'm not so knowledgeable about the Nano Every, but I am also not aware of any way it could interfere and I have never seen a single example of this happening. Even though it uses a different type of programming, the Nano Every is similar to those other boards in having a dedicated USB interface chip. By the nature of this design, the sketch program can't directly affect the USB chip.

Even if there was some rare case where resetting the Nano Every at the right time could recover the board from some state where the sketch is interfering with the correct functioning of the ATSAMD11D14A USB chip, the board does not have any special treatment of a double reset, and that reset would need to be timed very precisely, so the current information is false and harmful to the customers regardless. So I think it is better to simply remove it. If eventually we see that there is some case where the board can be soft bricked and recovered by some procedure, that accurate information can be added to the datasheet.

Information must be personally verified by the author before adding it to Arduino's documentation. Unless someone is able to verify that some recovery technique is available, such a section should not be present in the datasheet.

Thank you for the comment @per1234 you are right in this case. Those blocks of the datasheet are generic at this moment but they should be edited taking into account the particularities of each board.

@i-herrera maybe we need to review the pro family too?

[jcarolinares]

@marqdevx do you know if we have a way to discover that those changes are not destroying the format? (undesirables page breaks)

[marqdevx]

@jcarolinares It is not going to "destroy" anything, the page breaking is separate thing :D (It could be fixed before merging anyway)
They are automatically done from puppetteer .

[per1234]

I'm happy to make any modifications that are needed. Just let me know. I am not familiar with the Markdown to PDF conversion system used for the datasheets but welcome an opportunity to learn about it.

[marqdevx]

I'll make a video and a doc on how to use it once we publish the new npm package for the renderer, now is a little bit tricky and we are removing that "trickyness" :)

[per1234]

Thanks @marqdevx. I didn't intend to place any burden on you to assist me in learning about this subject. So please don't go to any trouble on my account. I am sure the information would be useful for contributors to these documents, so I'm certainly in favor of any additional documentation of the content system you might choose to add.

[marqdevx]

Yeah no worries, I was gonna make it anyway :D atleast internally

[marqdevx]

Shouldn't we add this change to th changelog?
@aliphys @jcarolinares