lpc176x: don't write to 0x2FC.

[jernejp21]

Leave 0x2FC - 0x2FF alone, since it stores values for code read protection. We don't want to lock flash permanently.

According to user manual, 0x2FC is reserved for CRP mechanism. It might happen that generated code is exactly the same as CRP1, CRP2 or CRP3. For that reason we should avoid writing to that area.

[Arksine]

Interesting. I think the chances that we would unintentionally write CRP3 are extremely low, but I see the utility in making it impossible. If its decided that we need to avoid 0x2FC, I think a simpler solution would be something like this:

diff --git a/src/generic/armcm_link.lds.S b/src/generic/armcm_link.lds.S
index 2f789f13..46126584 100644
--- a/src/generic/armcm_link.lds.S
+++ b/src/generic/armcm_link.lds.S
@@ -22,6 +22,9 @@ SECTIONS
         _text_vectortable_start = .;
         KEEP(*(.vector_table))
         _text_vectortable_end = .;
+#if CONFIG_LPC_FLASH_START_0000
+        . = 0x300;
+#endif
         *(.text .text.*)
         *(.rodata .rodata*)
     } > rom

I'm curious to see Kevin's feedback. If we make this change to Klipper I will also make it to Katapult.

[github-actions[bot]]

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards, ~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[KevinOConnor]

Interesting, thanks. I agree it is worthwhile to change the code to avoid this problem.

I agree with Arksine in that I'm unsure about changing FLASH_APPLICATION_ADDRESS and about introducing a new "vector" segment in the linker script. I do think we should introduce a new lpc176x_link.lds.S file though (as I think we should try to avoid adding board specific code to the src/generic/ directory). How about copying src/generic/armcm_link.lds.S to a new src/lpc176x/lpc176x_link.lds.S and adding Arksine's suggestion there (along with a comment about needed to avoid CRP1).

Thanks again, -Kevin