• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 84 subscribers
  • Views 726 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.

TMS320F28377S: Flash loading problem on custom board

Daniele Sgroi
Prodigy 10 points

Part Number: TMS320F28377S
Other Parts Discussed in Thread: UNIFLASH, TPS62080A

Hallo, we designed a custom board with TMS320F28377S, largely based on LAUNCHXL-F28377S schematic, including our peripherals devices (all on SPI and GPIO).

Our runtime SW has been developed and debugged succesfully on the LAUNCHXL board.

We use a XDS100-V3 JTAG interface to connect to the custom board.

When connecting to CCS, the device is correctly identified and we are able to load and run it (including breakpoints and step-by-step operations) on RAM.

We consider this a proof that the JTAG is working properly, however, we are unable to upload and run the binary code on the FLASH memory.


When trying to upload to LFASH, CCS console report the following messages:

C28xx_CPU1: GEL Output:
Memory Map Initialization Complete
C28xx_CPU1: Error: (Error -1044 @ 0x0) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 9.3.0.00042)
C28xx_CPU1: Trouble Halting Target CPU: (Error -1135 @ 0xC095) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 9.3.0.00042)
C28xx_CPU1: Unable to determine target status after 20 attempts
C28xx_CPU1: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

We double-checked the CPU Power Supply pins and found anything looking bad.

We double-checked the CCS configuration and, again, anything is looking bad.

Do you have some hints and checks to suggest?

Thanks in advance,

Daniele

  • 0
    TI__Guru* 87155 points

    Daniele,

    Based on the error, the flash programmer is not even invoked yet.  

    Just to confirm: You were never able to load to flash on this device - correct?

    OR did you program some code on this device's flash earlier successfully and started seeing issues after that for the next iteration?

    How are the boot mode pins configured? Hope you tried in wait boot mode.

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    Prodigy 10 points

    Hallo Vamsi,

    thank you for your feedback.

    The device is new, we never been able to load anything on Flash. In addition, also the flash blank command from Uniflash does not work.

    For what is related to Boot mode pins we tried both GPIO72/84 = 11 (GetMode) and 10 (Wait) whithout success.

    Daniele

  • 0 in reply to Daniele Sgroi
    TI__Guru* 87155 points

    Daniele,

    Thank you for the information.  

    1) When you connect to the device via CCS and start loading a flash based image, did you see the flash erase/program window pop up?  

    or did you get the below error even before you got the pop up?

    C28xx_CPU1: GEL Output:
    Memory Map Initialization Complete
    C28xx_CPU1: Error: (Error -1044 @ 0x0) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 9.3.0.00042)
    C28xx_CPU1: Trouble Halting Target CPU: (Error -1135 @ 0xC095) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 9.3.0.00042)
    C28xx_CPU1: Unable to determine target status after 20 attempts
    C28xx_CPU1: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

    2) Did you load your flash based image on LAUNCHXL-F28377S successfully using the same CCS/Uniflash setup?

    I am trying to isolate the failure and hence are my questions.

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    Prodigy 10 points

    1) No popup, just the error in the console output

    2) Same Project but different programmer setup because the LAUNCHXL has it's embedded XDS100-v2 programmer. We changd the  TMS320F28377S.ccxml setup under TargetConfigs to reflect the different connection device (XDS100-v3 for our board). The XDS100-v3 is confirmed working with another ARM based CPU.

    Daniele

  • 0 in reply to Daniele Sgroi
    TI__Guru* 87155 points

    Daniele,

    As per https://www.ti.com/lit/pdf/spraco1 - XDS100V2 is supported for TMS320F28377S.  

    XDS100V3 is not listed.

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    TI__Guru* 87155 points

    Daniele,

    I did not use XDS100V3 previously. I spoke to our team and they suggested to check with CCS team to confirm whether this is supported or not.

    Meanwhile, could you try erase operation from the flash plugin GUI (instead of program load) and see if that works?

    Flash Plugin GUI is available at:  CCS debug view -> Tools -> On-chip Flash -> In this GUI, you can scroll down to find the erase button.

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    Prodigy 10 points

    Hallo Vamsi,

    I don't see any reason why XDS100V3 should not be supported, but I'm looking forward for the results of your investigation about it.

    Both Uniflash and CCS allow selection of XDS100V3 with TMS320F28377S.

    Erase operation does not work either from Uniflash and CCS Flash Plugin GUI.

    Thanks,

    Daniele

  • 0 in reply to Daniele Sgroi
    TI__Guru* 87155 points

    Daniele,

    I agree with you - XDS100V3 should be listed in SPRACO1 guide - I think it is just not updated (I filed a ticket).

    I asked our CCS team to take a look at this post for you.

    Thanks and regards,
    Vamsi

  • 0 in reply to Daniele Sgroi
    TI__Guru**** 475881 points

    Hello Daniele,

    XDS100v3 should be supported.

    I was able to successfully connect and debug to my F28377D controlCard+Dock with an external XDS100v3. 

    Can you run a JTAG connectivity test and post the results here?

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 10 points

    Hallo,

    sorry for the long delay.

    We solved our issues, by checking the 1,2V voltage supervisor.

    Our analysis was that during flash programming, the CPU power consuption rises a bit and some current "spikes" on the power supply generate some undervoltage resets.

    By adjusting the PSU supervisor we were able to solve this issue. 

    Thank you for your support.

    Daniele

  • 0 in reply to Daniele Sgroi
    TI__Guru* 87155 points

    Daniele,

    Glad it is a power issue. In your first post of this thread, you mentioned that supply is checked and is good.  Hence, I assumed you checked during programming.

    Did you notice spikes more than the quoted numbers is datasheet for flash program/erase operations?  Please let me know.

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    Prodigy 10 points

    For the 1,2V we used a combination of TPS62080A regulator and a TPS3702CX12DDCR supervisor.

    What we have noticed is that with the nominal reference voltage divider for the regulator (64k9/39k2 Ohm) the output voltage is slight below the nominal 1,2 Value (we measured 1,12 to 1,15 V on average).

    During the flash operations, the current surge from the CPU makes the 1,2V Power line noisy when looked with an oscilloscope.

    This is especially true when setting the PLL at higher frequencies.Lowering the PLL frequency helps to have a more robust communication.

    In this condition, some "spikes" falls below the supervisor undervoltage treshold of 1,09 V, resetting the CPU.

    We are looking at the regulator layout to let it have a less noisy feedback network.

    Daniele

  • 0 in reply to Daniele Sgroi
    TI__Guru* 87155 points

    Daniele,

    Got it. Thank you for the details - that helps others.  Supply should be able to meet the demand throughout the flashing process. I am closing this post now.

    Thanks and regards,

    Vamsi