• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 180 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM263P4-Q1: UNIFLASH : Cannot Flash by XDS11S in QSPI(1S) Boot Mode

Kier
Mastermind 8065 points
Part Number: AM263P4-Q1
Other Parts Discussed in Thread: TMDSCNCD263P, UNIFLASH

Tool/software:

Hello,

Our TMDSCNCD263P board will be in an enclosure in a high voltage environment. As a result we cannot easily reach the board and change the boot mode.

Granted, the instructions here (AM263Px MCU+ SDK: TI Uniflash Tool) mention to put the device into DevBoot mode. However, in practice I have been able to flash in QSPI(1S) mode using the onboard XDS110 debug emulator for months until very recently, irrespective of the instruction to use DevBoot. Therefore, I've not been concerned about the need to change the boot mode switches.

My problem is that now, for some reason, it is now failing as shown below:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: ***OnTargetConnect() Launched***
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: AM263Px Initialization Scripts Launched. Please Wait...
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: AM263Px_Cryst_Clock_Loss_Status() Launched
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: Crystal Clock present
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: AM263Px_SOP_Mode() Launched
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: SOP MODE = 0x00000002
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: QSPI - 1S Functional boot mode
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: AM263Px_Read_Device_Type() Launched
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: EFuse Device Type Value = 0x000000AA
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: AM263Px_dual_or_lockstep_mode() Launched
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: r5fss0 = 0x00000101
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: r5fss1 = 0x00000000
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: R5FSS0 is in Lockstep mode
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: R5FSS1 is in Dual core mode
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: MSS_CTRL Control Registers Unlocked
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: MSS_TOP_RCM Control Registers Unlocked
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: MSS_RCM Control Registers Unlocked
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: MSS_IOMUX Control Registers Unlocked
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: TOP_CTRL Control Registers Unlocked
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: *** R5FSS0 Reset DualCore ***
[10/02/2025, 17:13:12] [INFO] Cortex_R5_0: GEL Output: ***R5FSS1 Reset DualCore ***
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

As you can see in the log, UniFlash has no problem connecting to the device. I have tried UNIFLASH 8.7 through to 9.0,

I hope you can appreciate that having to change the boot mode from QSPI(1S) -> DevBoot -> QSPI(1S) is wholly impractical for us.


My first request: Please advise why (in principle) the SOC cannot be flashed in QSPI(1S) mode. This might offer some clues as to how I can rescue the situation.

  • 0
    Mastermind 8065 points

    The cause of this issue is because our application configured the Mux to be able to use HSEC_EQEP2_A and HSEC_EQEP2_B for GPIO. This means that the EEPROM becomes disconnected.

    This is ostensibly no problem for our application since we are not using EEPROM. However, what is not obvious is that the stock flasher.out file used by UniFlash needs to read the EEPROM otherwise it fails. See TMDSCNCD263P: Why Does the OSPI Flasher Read The EEPROM? - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums.

    When I restored the I2C connection in my application, the problem was solved and I was once again able to flash with UniFlash in QSPI (1S) mode.

    The lesson is that if you want to use UniFlash with its stock flasher.out, then your application must not use pins which communicate with the EEPROM on I2C. The alternative is to make a custom flasher which avoids reading the EEPROM altogether.

     The question still remains: Why does the manual mandate DevBoot mode for flashing by UniFlash? Why not QSPI (1S)? Is it purely to avoid the situation I have just described or are there other reasons?

  • 0 in reply to Kier
    TI__Mastermind 35982 points

    Hi Kier,

    Kier said:
    The lesson is that if you want to use UniFlash with its stock flasher.out, then your application must not use pins which communicate with the EEPROM on I2C. The alternative is to make a custom flasher which avoids reading the EEPROM altogether

    The flasher present in Uniflash by default is for TI boards. Could you please try to modify the flasher project present at sdk for your board and try again.

    sdk_path\tools\flasher\jtag_uniflash\am263px-cc

  • 0 in reply to Nilabh Anand
    Mastermind 8065 points

    Thanks Nilabh, but I've changed our application to connect the EEPROM again to avoid my having to make a customer flasher. I will however make a custom flasher for our custom PCB in a month or so.

    But for now, it's critical for me to understand if there are knock-on effects to using QSPI (1S) boot mode with UniFlash:

    - Why does the manual mandate DevBoot mode for flashing by UniFlash? Why not QSPI (1S) also?

    - Is it purely to avoid the situation I have just described or are there other reasons?

  • +1 in reply to Kier
    TI__Mastermind 35982 points
    Kier said:

    But for now, it's critical for me to understand if there are knock-on effects to using QSPI (1S) boot mode with UniFlash:

    - Why does the manual mandate DevBoot mode for flashing by UniFlash? Why not QSPI (1S) also?

    There should not be any limitation of using Uniflash in QSPI 1s boot mode. I will take a min to explain how uniflash will work in QSPI 1s.

    The  boot pins are set to QSPI 1s and once the device is powered on ROM checks for boot pins and tries to boot in 1s mode, it will go and read the flash at location 0x0, depending on if the valid image is present it will either boot or go to redundant locations:

    If none of these locations have valid images, System enters into Panic i.e. code waits for watch-dog to reset the device, WDT timeout is 180sec.

    WDT will issue an reset after 180 sec, so if you want to use Uniflash, the care that needs to be taken care is that, it needs to be done before ROM issue a reset. 

  • 0 in reply to Nilabh Anand
    Mastermind 8065 points

    Thank you very much for the information.