Placing an Array in Flash

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Placing an Array in Flash

      I've defined the following in a C++ file and it isn't referenced by anything. I'm just trying to configure the 16 bytes used by the Kinetis K64 flash protection mechanism..

      Source Code

      1. static const U8 _flash_protection[] __attribute__ ((section(".flash_protection"))) =
      2. {
      3. 0xDE, 0xAD, 0xDE, 0xED,
      4. 0xDE, 0xAD, 0xDE, 0xED,
      5. 0xFF, 0xFF, 0xFF, 0xFF,
      6. 0xFF, 0xFF, 0xFF, 0xFF,
      7. };

      I'd like to place it at 0x400 but this doesn't seem to work:

      Source Code

      1. <ProgramSection alignment="4" load="Yes" keep="Yes" name=".flash_protection" start="0x400" size="16" />

      It seems to work fine for my vector placement:

      Source Code

      1. <ProgramSection alignment="0x100" load="Yes" name=".vectors" start="$(FLASH_START:)" />
      I'm using MacOS SES 4.10a.

      Thanks.
    • Hello,

      Thank you for your inquiry.
      Are you using the ES CPU support packages by any chance for your project?
      If yes you should see the following code snippet in the MK64xxx_Vectors.s:

      Source Code

      1. #if 1
      2. .section .vectors, "ax"
      3. // fill to 0x400 for the flash configuration field
      4. //.fill 0x400-(_vectors_end-_vectors), 1, 0xff
      5. .org 0x400, 0xFF
      6. BackDoorKey:
      7. .byte 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
      8. #if defined(E_SERIES)
      9. RESERVED:
      10. .byte 0xff, 0xff, 0xff, 0xff
      11. EEPROT:
      12. .byte 0xff
      13. FPROT:
      14. .byte 0xff
      15. FSEC:
      16. .byte 0xfe
      17. FOPT:
      18. .byte 0xff
      19. #else
      20. FPROT:
      21. .byte 0xff, 0xff, 0xff, 0xff
      22. FSEC:
      23. .byte 0xfe
      24. FOPT:
      25. #if defined(MKL03Z4) || defined(MKL17Z4) || defined(MKL17Z644) || defined(MKL27Z4) || defined(MKL27Z644) || defined(MKL33Z4) || defined(MKL33Z644) || defined(MKL43Z4)
      26. .byte 0x3b
      27. #else
      28. .byte 0xff
      29. #endif
      30. FEPROT:
      31. .byte 0xff
      32. FDPROT:
      33. .byte 0xff
      34. #endif
      35. #endif
      Display All
      This was implemented by us so our customers do not lock their devices everytime while creating a new project due to the inconvenient lok bit placement on Kineits devices in the middle of Flash.
      To be able to write this Flash section make sure to put this code block to #if 0 and select the correct K64 device type. e.g. MK64FN1M0xxx12 (allow security)
      Otherwise J-Link will do corrections before Flashing so you don't lock your device accidentally.

      Best regards,
      Nino
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support contact us per e-mail.
      Alternatively our support ticketing system can be used as well: segger.com/ticket/
    • Hi Nino,

      I am aware of this code. Can you answer my question? Why does that not work? What is the correct way to do this? I don't understand why that wouldn't place those 16 bytes at 0x400.

      Can you elaborate on the differences between the "allow security" selection? While I appreciate that you make efforts to ease development it's important to understand what is actually being done by the debugger or the source files that are copied to the project.

      Related: What is the option to configure the J-Link to verify the download? The output suggests that 0.000 seconds were spent verifying. I can't seem to find the option. I did find the menu option to do so but I would have found this issue much faster if the flash verify had been enabled. At the moment I am using the J-Link Lite but have a J-Trace Pro in transit for this project. I replaced the firmware on the K64-TWR on-board debugger.

      Now that I have purchased a license I'll send a support request and point to this.

      Thanks.
    • I created a separate assembly file:

      Source Code

      1. .section .flashsecurity, "ax"
      2. BACKDOORKEY:
      3. .byte 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
      4. FPROT:
      5. .byte 0xff, 0xff, 0xff, 0xff
      6. FSEC:
      7. .byte 0xfe
      8. FOPT:
      9. .byte 0xff
      10. FEPROT:
      11. .byte 0xff
      12. FDPROT:
      13. .byte 0xff
      Display All
      Then used the following in my flash placement file:

      Source Code

      1. <!DOCTYPE Linker_Placement_File>
      2. <Root name="Flash Section Placement">
      3. <MemorySegment name="$(FLASH_NAME:FLASH)">
      4. <ProgramSection alignment="0x100" load="Yes" name=".vectors" start="$(FLASH_START:)" />
      5. <ProgramSection alignment="4" load="Yes" keep="Yes" name=".flashsecurity" start="0x400" size="16" />
      This is satisfactory but I'd like to understand why my original approach did not work.
    • I was able to link the above and place the bytes correctly but I changed the device to the "allow security" version. Now I'm running in to errors when attempting to download the application.

      I realize that I effectively included these bytes but changed to the "allow security" version of the chip which is incorrect. But if I don't define those bytes and place them at 0x400 what will prevent the linker from writing odd data to that special location?
    • Hello Kenny,

      In the security area of Kinetis devices is one bit that will lock a device indefinitely so that not even J-Link can recover it anymore.
      That is what the allow security device differentiation is for.
      Why it did not work before for you has two reasons.
      One is that the startup code was already placing information to 0x400 which you tried to link additional data to which will not work. You can't link different data to the same location.
      The second issue is that if you do not select the allow security device J-Link will prohibit you locking the device indefinitely. It will write your data at 0x400 that you selected expect that one bit.
      If you really want to set that bit you need to select the appropriate allow security device, otherwise J-Link will not write that bit.

      Kenny wrote:

      I was able to link the above and place the bytes correctly but I changed the device to the "allow security" version. Now I'm running in to errors when attempting to download the application.
      The errors are expected. If you lock the device indefinitely J-Link can't access it ever again -> access errors.
      So make sure you application is 100% correct as after locking the device you can't access it with any debug probe ever again.

      Best regards,
      Nino
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support contact us per e-mail.
      Alternatively our support ticketing system can be used as well: segger.com/ticket/
    • I don't believe that first point is true. I had not included that code and wasn't trying to link two sections to the same place. What I had done was define the vector table in C++ as an array and placed that in the section .vector. But I understand that I am asking too much for you to debug this issue without the actual code.

      I have the solution above which is based on the code you pointed out so that's fine. If the linker placement issue comes up again I'll submit an isolated project to recreate the problem.

      Thank you for the other information.