• State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 83 subscribers
  • Views 626 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.

TMS320F28377D: Features of DSP are missing

Bob Fisher1
Prodigy 70 points

Part Number: TMS320F28377D

My customer has multiple custom-made PCBs with TMS320F28377DZWTS DSPs populated on them.  One particular DSP, when connected to via debugger shows the following unexpected values in the Device Configuration Registers:

  • PARTIDL.QUAL = 11 (expected 10 for TMS)
  • PARTIDH.FAMILY = 01111111 (expected 0000011 for dual core)
  • DC0.SINGLE_CORE = 0 (expected 1 for dual core)
  • DC1.CPU2_FPU_TMU = 0 (expected 1)
  • DC1.CPU1_VCU = 0 (expected 1)
  • DC1.CPU2_VCU = 0 (expected 1)
  • DC1.CPU1_CLA1 = 0 (expected 1)
  • DC1.CPU2_CLA1 = 0 (expected 1)
  • DC20.GS6-GS15 = 0 (expected 1 for all GSx RAM areas)

Across all PCBs, all 28377D DSPs have these registers set to their expected values except this one DSP.  Is there any insight as to why this specific DSP is configured differently than the rest?  Again, they are all TMS320F28377DZWTS DSPs.

The DSP in question has the following device markings: YFC-75AFXEW.

We are connecting to this DSP via Blackhawk XDS560v2-USB System Trace Emulator.  This same emulator has been used to connect and verify the Device Configuration Registers of a different 28377D DSP successfully as well.

We have attempted power cycling, connecting from different PCs, and still see the same bad configuration for that one DSP.

  • 0
    TI__Guru** 117001 points

    Hi Bob,

    After connecting the device to CCS, can you issue reset from CCS and then click on run icon of CCS and then after CPU halts, check the values again. Let me know what you find.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 70 points

    Thanks for the response, Vivek!

    So I did what you requested, and after halting the CPU following the "CPU Reset" via CCS, the device registers do read back properly.  This lasts until power is cycled to the DSP.  Then the registers revert back to the incorrect configuration.

    Can you explain A) why the registers appear correct after a CCS issued reset, and B) if there is a way for it to persist over DSP power cycles?

    Steps Taken:

    1. Connected to target
    2. Verified Device Config Registers = Incorrect
    3. Clicked "CPU Reset" in CCS
    4. Clicked "Resume" in CCS
    5. Clicked "Suspend" in CCS
    6. Verified Device Config Registers = Correct
  • 0 in reply to Bob Fisher1
    TI__Guru** 117001 points

    Bob,

    What is the boot mode pin setting on this board and other working board ? If it's Get Mode  (1/1) then device will go in reset cycle and when you connect to CCS, BOOTROM may not initialize the device completely based on what part of the code was run before connecting to CCS hence when you run the full BOOT ROM code again, all the register get initialized properly.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 70 points

    Vivek,

    Yes, the boot mode pin settings for both boards is Get Mode (1/1) for GPIO72 and GPIO84.

  • 0 in reply to Vivek Singh
    Prodigy 70 points

    Vivek Singh said:

    If it's Get Mode (1/1) then device will go in reset cycle and when you connect to CCS, BOOTROM may not initialize the device completely based on what part of the code was run before connecting to CCS hence when you run the full BOOT ROM code again, all the register get initialized properly.

    Does this mean it is only an issue when connecting to the target via CCS?  If the DSP booted from Flash (independent of a debugger), would it boot fine?  Why is it just this single DSP that exhibits the initialization issue when connected to CCS, and not any other DSPs?

  • 0 in reply to Bob Fisher1
    TI__Guru** 117001 points

    Hi Bob,

    Does this mean it is only an issue when connecting to the target via CCS?  If the DSP booted from Flash (independent of a debugger), would it boot fine? 

    Yes, this issue specific to CCS connection only and is not applicable when running stand alone (without CCS connection). In standalone it'll boot fine.

    Why is it just this single DSP that exhibits the initialization issue when connected to CCS, and not any other DSPs?

    This is surprising to me also. Can you probe the XRSn pin on working board and non-working board (without CCS connection) and see if there is any difference in XRSn toggling or pulse ?

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 70 points

    Vivek Singh said:

    Can you probe the XRSn pin on working board and non-working board (without CCS connection) and see if there is any difference in XRSn toggling or pulse ?

    Sorry for the delay.  I will get you an answer on the XRSn lines tomorrow hopefully (remote lab setup makes probing HW challenging).

  • 0 in reply to Bob Fisher1
    TI__Guru** 117001 points

    Hi Bob,

    Let me know if you need any further info on this else please mark the post resolved.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 70 points

    Hi Vivek,

    I apologize for the delay.  Finally got a response regarding the XRSn line waveforms and I'm told both boards have a clean signal with no difference between the two.

    Back to the drawing board, it seems.

    Bob

  • 0 in reply to Bob Fisher1
    Prodigy 70 points

    I was informed both boards had a signal like this.  No unusual pulses.

  • 0 in reply to Bob Fisher1
    TI__Guru** 117001 points

    Bob,

    Can you also add the VDD/VDDIO to this plot and compare working and non-working board.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    TI__Guru** 117001 points

    Hi Bob,

    Were you able to check VDD/VDDIO sequence and working and non working board?

    Regards,

    Vivek Singh