• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 54 subscribers
  • Views 342 views
  • Users 0 members are here
Support feedback
Options
Options

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.

UniFlash 6.3.0.3193 : CPU2 Verification Fails After CPU1 Load

Kier
Mastermind 8055 points
Other Parts Discussed in Thread: UNIFLASH

Hello,

I have a dual CPU project for LAUNCHXL-F8379D that runs standalone.

Verification succeeds on both CPUs. If CPU1 is then re-flashed (without changing the hex file) verification then fails on CPU2. If UniFlash is restarted, verification succeeds again. In other words, the steps are:

Verify CPU1 : OK

Verify CPU2 : OK

Load CPU1 : OK

Verify CPU2 : Failure

Restart UnfiFlash

Verify CPU2 : OK

Since verification succeeds after UniFlash restart, I suspect the problem lies with UniFlash. Here's the log steps before restart:

[29/06/2021 08:17:32] [INFO] C28xx_CPU1: GEL Output: Memory Map Initialization Complete
[29/06/2021 08:17:33] [INFO] C28xx_CPU1: If erase/program (E/P) operation is being done on one core, the other core should not execute from shared-RAM (SR) as they are used for the E/P code. Also, CPU1 will be halted to determine SR ownership for the CPU which will run the Flash Plugin code, after which CPU1 will be set to run its application. User code execution from SR could commence after both flash banks are programmed.
[29/06/2021 08:17:36] [SUCCESS] C28xx_CPU1: Program verification successful for W:/Build/OBC_CPU1/CPU1_FLASH/OBC_CPU1.hex
[29/06/2021 08:17:39] [INFO] C28xx_CPU2: GEL Output: Memory Map Initialization Complete
[29/06/2021 08:17:39] [INFO] C28xx_CPU2: If erase/program (E/P) operation is being done on one core, the other core should not execute from shared-RAM (SR) as they are used for the E/P code. Also, CPU1 will be halted to determine SR ownership for the CPU which will run the Flash Plugin code, after which CPU1 will be set to run its application. User code execution from SR could commence after both flash banks are programmed.
[29/06/2021 08:17:40] [SUCCESS] C28xx_CPU2: Program verification successful for W:/Build/OBC_CPU2/CPU2_FLASH/OBC_CPU2.hex
[29/06/2021 08:18:30] [SUCCESS] Program Load completed successfully.
[29/06/2021 08:18:33] [ERROR] C28xx_CPU2: File Loader: Verification failed: Values at address 0x80000@Program do not match Please verify target memory and memory map.
  • 0
    TI__Guru* 87105 points

    Kier,

    After the program load, device will be left in the state in which the program loader has used it.  Hence, please try to issue a reset and then do the verify.

    Query for the reset actions by clicking below highlighted.

    Then, issue a reset using below reset button.

    Let me know how it goes.

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    Mastermind 8055 points

    Hello Vamsi,

    It seems a reset of CPU2 (not CPU1 as per your picture) does solve the issue. Thank you.

    However, if I select "Execute selected reset after program load" this appears ineffective. The CPU2 verify fails again unless, as you suggested, I click Reset Now button.

  • 0 in reply to Kier
    TI__Guru* 87105 points

    Kier,

    Glad it helped.  I meant to show where the button is available (not specifically CPU1 or 2).

    Regarding "Execute selected reset after program load" option: Maybe the "keep target connected" option enabled for this.  Let me try and get back to you.

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    TI__Guru**** 450651 points

    Hi Vasmi,

    Just to confirm, this option did not work for you also?

    Thanks

    ki

  • 0 in reply to Ki
    TI__Guru* 87105 points

    Ki,

    I tried with verbose mode enabled.  I did not see the reset execution info note in the console output when I enabled the "Execute selected reset after program load" action.  

    Maybe the action is implemented but the info is not printed in the flow of program load?  Please check.  

    Standalone "Reset Now" action did print the info as Kier mentioned.

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    Mastermind 8055 points

    Hi Vamsi,

    Thanks for the investigation. Regarding "Execute selected reset after program load", I think that all the evidence suggests that reset is not executed:

    1) "Reset Now" fixes the original reported problem.

    2) "Reset Now" registers a console message.

    3) "Execute selected reset after program load" does neither 1) or 2).

    Do you want me to raise a separate post for this problem?

    Kier.

  • 0 in reply to Vamsi Gudivada
    Mastermind 8055 points

    Thanks Vamsi. I could not find the "Keep Target Connected" option to try. Please can you tell me where is located?

    Kier.

  • 0 in reply to Kier
    TI__Guru**** 450651 points
    Kier said:
    I could not find the "Keep Target Connected" option to try. Please can you tell me where is located?

    You can press the CPU status indicator in the upper right corner. This will open a small dialog window where you can toggle the action to keep target connected:

  • 0 in reply to Vamsi Gudivada
    TI__Guru**** 450651 points
    Vamsi Gudivada said:

    I tried with verbose mode enabled.  I did not see the reset execution info note in the console output when I enabled the "Execute selected reset after program load" action.  

    Maybe the action is implemented but the info is not printed in the flow of program load?  Please check.  

    Standalone "Reset Now" action did print the info as Kier mentioned.

    Thanks Vamsi, I see the same. It doesn't look like the reset action took place. I will file a bug for this.

    Thanks

    ki

  • 0 in reply to Ki
    TI__Guru**** 450651 points

    I filed a bug for this. Tracking ID: https://sir.ext.ti.com/jira/browse/EXT_EP-10432

    Thanks

    ki