boards: nxp: frdm_k64f: use SW2 instead of SW3 for MCUboot

[henrikbrixandersen]

Use SW2 instead of SW3 for entering MCUboot serial recovery/USB DFU mode. Holding SW3 during reset results in a NMI, causing the boot process to halt.

[henrikbrixandersen]

This fixes 4511662 for the frdm_k64f board, not sure if others have the same issue. @butok How was this commit tested?

[fabiobaltieri]

oof, should there be a comment about it on that line? not a fan of cluttering devicetree files with comments but this may be worth it

[henrikbrixandersen]

oof, should there be a comment about it on that line? not a fan of cluttering devicetree files with comments but this may be worth it

A comment about what above which line? Suggestions welcome :)

[fabiobaltieri]

A comment about what above which line? Suggestions welcome :)

You are only changing one line :-) anyway, forget it I, I can't think of anything silly to add, would hate a comment that describes what signal doesn't do, imagine mcuboot-button0 = &user_button_2; /* this is not an NMI */, yikes

[henrikbrixandersen]

You are only changing one line :-) anyway, forget it I, I can't think of anything silly to add, would hate a comment that describes what signal doesn't do, imagine mcuboot-button0 = &user_button_2; /* this is not an NMI */, yikes

We could add a comment above the declaration of SW3 (a line I did not change here) noting that this switch is NMI capable?

[fabiobaltieri]

We could add a comment above the declaration of SW3 (a line I did not change here) noting that this switch is NMI capable?

Yeah that may work, just something that one would read while porting to a new board and not make the same mistake.

[butok]

Thank you for catching this issue.

It was assumed that SW0 alias is functional for all boards, as it used by the basic Zephyr button example.
So the mcuboot-button0 was set to SW0 button value (user_button_3 for this platform).
It means that sw0 = &user_button_3 alias can be problematic.