• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 515 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.

NHET RAM and registers acting as "Write Only" ... ?

Richard G
Prodigy 50 points
Other Parts Discussed in Thread: TMS570LS20216

I'm experienced with the (N)HET, but I'm starting a new project on a TMS570LS20216 and creating a new driver from scratch. I am able to load a small PWM output program to NHET RAM, configure the NHET registers, start the program running, and continue to modify the registers/RAM while running (pin toggles, simple duty cycle sweep). However I cannot seem to read any of the registers or NHET RAM contents - they always read back 0.

I have tried it with the NHET running/stopped, NHET parity enabled/disabled, program fields protected/not, suspend ignore enabled/disabled, changing GCR Master Priority field, lowering VCLK2, debugger attached/detached. I single step through the assembly and everything seems normal except always reading back 0. HTU, DMA, and R4 MPU are unconfigured/disabled as far as I know, and always running privileged mode. MIBSPI registers and RAM can be read just fine.

I'm very confused. Is there some other system level setting of the 570 I might be missing? Any other ideas?

 

  • 0
    TI__Genius 14205 points

    Hi Richard,

    I could not reproduce your issue at my desk. I am still working on it.

    Couple of Suggestions

    1) Check whether peripherals are Enabled ( PENA bit in Sys) and also check the Peripherals out of powerdown mode( in PCR - PSPWRDWNCLR0)
    2) Try a 32bit read and see if you still see the issue. ( Just a try ).
    3) If you have any Memory Mapping configured in CCS GUI please remove it and take it to default.

    Best Regards
    Prathap

     

  • 0 in reply to Prathap
    Prodigy 50 points

    My colleague and I seem to have found an explanation for this issue:

    The problem came from VCLK2 and VCLK dividers in SYS->CLKCNTRL being changed at the same time.

    Our startup logic incorrectly assumed the value of these fields after reset was zero (default value of both is binary 0001); so while configuring the first clock accidentily wrote to both. Correcting the logic to read-modify-store for both dividers, one at a time, makes this behavior go away.

    Regards,
    Richard

     

  • 0 in reply to Richard G
    Prodigy 50 points

    Correction:

    The values being written turned out to match the default values, so it was not a matter of being written at the same time, but of being written in the wrong order.

    #define DESIRED_CLKCNTRL      0x01010100
    #define VCLK2R_MASK                   0x0F000000
    #define VCLKR_MASK                     0x000F0000

    //set VCLKR2
    SYS->CLKCNTRL = DESIRED_CLKCNTRL & VCLK2R_MASK;  //this line accidentily overwrites VCLKR
    //set VCLKR and PENA
    SYS->CLKCNTRL = DESIRED_CLKCNTRL;

    Doing this set VCLK faster than VCLK2 which is forbidden. The issue was resolved by changing the logic to:

    //set VCLKR2
    SYS->CLKCNTRL = (SYS->CLKCNTRL & (~VCLK2R_MASK)) | (DESIRED_CLKCNTRL & VCLK2R_MASK);
    //set VCLKR
    SYS->CLKCNTRL = (SYS->CLKCNTRL & (~VCLKR_MASK)) | (DESIRED_CLKCNTRL & VCLKR_MASK);
    //set PENA
    SYS->CLKCNTRL = DESIRED_CLKCNTRL;

    Regards,
    Richard