• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 86 subscribers
  • Views 128 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

F29H850TU: automate the initial flashing process.

Jan Bock
Expert 3860 points

Part Number: F29H850TU
Other Parts Discussed in Thread: UNIFLASH

We need to automate the initial flashing process. I'm using the UniFlash/DSLite command line tool:

First run (MCU is in bankmode=0) — works fine:

  1. Set bankmode to 1
  2. Flash application (FlashImageOperation=1)
  3. Flash application (FlashImageOperation=0)
  4. Reset, run

Second run (bankmode is already 1) — fails:

  1. Flash application (FlashImageOperation=1)
  2. Flash application (FlashImageOperation=0)
  3. Reset, run

Error:

error: C29xx_CPU1: Error writing the init algorithm. Flash algorithm returned error code. Operation cancelled.

error: C29xx_CPU1: File Loader: Memory write failed: Unknown error

Failed: File: Multiple Files: Load failed.

The same error occurs when attempting to set bankmode back to 1.

The only thing that changes between the first and second run is that an XRS reset is performed during the bankmode=1 switch. DSLite/C29 supports via CLI:

  • 0. CPU Reset
  • 1. CPU Reset without halt

When I perform a reset with halt (-r 0), it executes but the MCU continues running (status LED keeps blinking). I'm concerned the reset isn't actually working, which is why the second flash attempt fails.

I have the latest version of DSLite/UniFlash. I can reproduce this reliably. We're receiving 20 devices in the coming days and would like to test an initial production process.

 

  • 0
    TI__Mastermind 21825 points

    Hi Jan,

    When you are referring to a "Reset", I'm assuming you are referring to a CPU reset. I'm only highlighting this to make sure you are performing an XRSn right after the bank mode switch.

    When you XRSn and the second flash attempt fails, are you able to check the SSUGenRegs.SSUMODE register to make sure you're in SSUMODE1? And is the bankmode actually the desired BANKMODE1? Could you provide any more details on your exact steps, if possible as well.

    Best Regards,

    Aishwarya

  • 0 in reply to Aishwarya Rajesh
    TI__Expert 3860 points

    Hello Aishwarya, 

    • SSUMODE=1
    • Seccfg ist FF => default
    • both Bankmgmt are "6" => bankmode  1 => targeted bankmode

     

    In parallel we can watch into all registers - they can be read one after the other with the debugger. 

    Jan

  • 0
    TI__Mastermind 21825 points

    Jan,

    Apologies for the delay. Yesterday was an US Holiday. Is this replicable using CCS?  I am connecting you with another Flash expert for assistance.

    Best Regards,

    Aishwarya

  • 0
    TI__Mastermind 27300 points

    Hi Jan,

    Jan Bock said:
    When I perform a reset with halt (-r 0), it executes but the MCU continues running (status LED keeps blinking). I'm concerned the reset isn't actually working, which is why the second flash attempt fails.

    For changing the bankmodes you need to issue an XRSn not a CPU reset. 

    In the GEL file of the generated package (through uniflash), can you add this content:

    Example Directory: uniflash_windows\ccs_base\emulation\gel\f29h85x.gel

    GEL_CLI_executeReset()
{
    'REG'::DevCfgRegs.SOC_SECURE_BOOT_INFO_REG7 = 0x00000000;
    'REG'::CpuSysRegs.SIMRESET = 0xA5A50002;
    GEL_TextOut("Issued XRSn reset pulse to device.\n");
}

    Then in the command prompt, instead of calling (-r 0) call (--post-flash-device-cmd executeReset), this should execute the XRSn properly. It would also help to probe the XRSn on your hardware to verify that the reset is getting properly applied.

    Please try this method and let me know if you are still seeing similar issues.

    Best Regards,

    Marlyn