This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MCU-PLUS-SDK-AM263X: Keywriter Not Executing and Flash Data Resetting to 0 on AM263x HS-FS Device

Part Number: MCU-PLUS-SDK-AM263X
Other Parts Discussed in Thread: UNIFLASH, AM2634

Tool/software:

Hello TI,

I am encountering an issue with the HS-FS variant of the AM263x device. Here's the situation:

  1. I used the otp_keywriter_am263x_SR_11_09_01_00_05 keywriter.
  2. Through Uniflash, I programmed the keywriter binary into flash at address 0x0 (the SBL start address).
  3. After programming, I checked the flash content at 0x0 and verified that the data was correctly written.

However, upon a power cycle, the following issues occur:

  • The keywriter does not execute.
  • Checking the flash content at address 0x0 again using Uniflash, I find that the data has been reset to 0x0.

I tried an alternative method:

  • Using the UART mode with a flashing script to program the binary.
  • In this case, the phenomenon is the same with using Uniflash.

Additional observations:

  • When the QSPI mode is used to boot the device, the serial port receives a string of output logs.
  • After this log appears, if I check the flash content at address 0x0 using Uniflash, the SBL content has been cleared.
  • The ROM version and related information displayed on my EVM (as shown in the attached image) appear different from what is illustrated in the user guide examples.

Could you please help me understand:

  1. Why does the flash data reset to 0x0 after booting in QSPI mode?
  2. Why isn't the keywriter executing?
  3. Is there a compatibility issue with the ROM version?

I also have another question related to enabling secure boot:
On a custom AM2634 board where only QSPI boot is supported and programming is done through Uniflash, enabling secure boot and running the keywriter to convert the device to HS-SE will, by default, lock the JTAG interface. This makes further development impossible.

To address this, I am considering modifying the devconfig settings in the SDK to enable the debug port option and recompiling the keywriter. The goal is to keep the debug port open after the keywriter executes. Is this approach feasible?

Could you please help me understand:

  1. Can modifying the devconfig settings as described ensure that the debug port remains open after executing the keywriter?

Thank you for your assistance!

Best Regards,

Yang