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.

Omap L138 eHRPWM so close....

Other Parts Discussed in Thread: OMAP-L138, OMAPL138

...and yet so far. I have the eXperimeter board which has no linux driver for the eHRPWMs, so I wrote a simple linux driver to set up both eHRPWMs to generate a square wave based on the most simple example in the eHRPWM user's guide. At first the registers were reading back zeroes until I took the eHRPWMs out of low power mode, then they came to life and I could read back correct default values so that allowed me to verify the endianess of my driver commands that set the registers.

The remaining problem is that even though the eHRPWMs are set up and ready to go the counter never increments. I checked the eHRPWM clock source in the PLL registers and the PLL status/control registers are indicating the ASYNC3 clock (used by the eHRPWM) is alive. I changed the ASYNC3 clock to be sourced from PLLC0 and then from PLLC1 but in either case the counter doesn't budge.

Now for the mysterious part. There was a forum response regarding L137 PWM code examples that pointed users to the F28335 T.I. DSP chip code examples for eHRPWM control since that chip uses the same eHRPWM as the L137/L138. In that code the is a register called PCLKCR1 that is used to enable the clock to the eHRPWMs! This register is briefly referred to in the L138 System User's Guide, but it is not described in detail in either the L138 System User's Guide nor the L138 Data Manual. Does this register exist in the L138 and is it used to enable the clock to the eHRPWMs?

Thanks!

-JV

  • Have you checked the Power and Sleep Controller (PSC) module which controls the various clocks to specific modules.  The appropriate clock needs to be enabled to allow the propagation of the clock from the PLL to the eHRPWM.  The section 6.8 in the OMAP-L138 datasheet describes some of this.

  • Yes, the PSC was initially holding the eHRPMWs in low-power mode which caused all eHRPWM registers to be read back as zeroes. I then set the "Next State" field of the PSC  MDCTL17 register to active and then set the PTCMD register to cause a power transition so that the "Next State" value would take effect. This brought the eHRPWM to life in the sense that the eHRPWM registers could be written and read successfully. I also read the PSC MDSTAT17 register and it shows that MCKOUT is on, MRST is de-asserted, and LRSTDONE is done. Is there anything else needed beyond this to activate the eHRPWM clock? Is PCLKCR1 used for this on the L138?

     

    thanks,

    -JV

  • Hi JV

    JayVee said:
    Is PCLKCR1 used for this on the L138?

    No, PCLKCR1 is not used on OMAPL1x devices (and does not exist on the OMAPL1x register memory memory map). If there are any references to that register in the sample code or user documentation , the likely got carried over from the F28x , as you know the module is same as what are present on the F28x.

    I know there was one reference to that register cited in the OMAPL138 datasheet under the eCAP section, and we are going to fix that. Could you point me where you saw it mentioned in the System Guide?

    On your main issue of not being able to make the counters work...still thinking through this. Can you explain a bit more on your development environment, you mention using the OMAPL138. What is the DSP doing while you are running this app from the ARM side on Linux?

    Regards

    Mukul

  • The reference to PCLKCR1 I found is the one you referred to in the data sheet, (none in the system manual, I mixed the two docs up). So far I have just been using the linux kernel that came with the eXperimenters kit and adding kernel modules and user space programs that run on the Arm. I haven't programmed the DSP to do anything yet unless the SDK linux kernel is doing something with the DSP. Now I'm firing up CCS4 with the XDS510 emulator to peek at the registers through JTAG to get another view of things.

  • Ok thanks.

    Have you also looked at the example on the wiki

    http://processors.wiki.ti.com/index.php/C6747_EHRPWM_Example

    This is a DSP side example for a DSP only device in the same family, but you might find some relevant initialization/reference steps that you could apply to your ARM side driver too.

    The thing that catches my eye is the SYSCFG.CFGCHIP1 write to TBCLKSYNC bit( eHRPWM Time Base Clock (TBCLK) Synchronization: Allows the software to globally synchronize all enabled eHRPWM modules to the time base clock (TBCLK).)

    // Unlock the config registers
       SyscfgRegs->KICK0R = CSL_FMK(SYSCFG_KICK0R_KICK0, KICK0R_UNLOCK);
       SyscfgRegs->KICK1R = CSL_FMK(SYSCFG_KICK1R_KICK1, KICK1R_UNLOCK);

       // Stop all the Time Base clocks
       SyscfgRegs->CFGCHIP1 = CSL_FMKT(SYSCFG_CFGCHIP1_TBCLKSYNC, STOP);

    Also seems like the DSP is not in the picture, but one minor thing to note especially if you tried something from the emulator side would be aware of the fact that SYSCFG.SUSPRC by default make DSP the emulation suspend source. Recommend changing the EPWRM control to ARM for any CCS based debug and development from ARM side.

    Hope this helps

    Regards

    Mukul

  • Thanks Mukul, that TBCLKSYNC bit was set low which disables the eHRPWM clocks. Some closing thoughts:

    1.) all the examples in the eHRPWM User's Guide should include those programming steps, in order for any of the examples to work.

    2.) There's a mistake in the System Control Manual, which is that the PLLRST bit in the PLLC0 and PLLC1 registers is low when the PLL is not in reset, but it actually is high.

    3.) The SDK should include an eHRPWM driver example to go along with the PWM tests that are included in the SDK test suite. It looks like there was a davinci_pwm driver in the Monta Vista distro that was subsequently removed from the OmapL138 SDK. If this driver could be resurrected for the August release of the SDK then the test suite PWM tests would run and it would be a good addition to the SDK.

    Thanks!

    JV

  • Hi JV

    Thanks for the feedback, I will pass it along to the documentation owner and SDK folks to comprehend and respond if necessary.

    JayVee said:
    2.) There's a mistake in the System Control Manual, which is that the PLLRST bit in the PLLC0 and PLLC1 registers is low when the PLL is not in reset, but it actually is high.

    Not sure if I see the issue in the documentation on this one, PLLCTLx.PLLRST =1 implies that the PLLs is out of reset (reset is de-asserted/ not asserted). Are you looking at the latest system guide on the product folder

    http://focus.ti.com/lit/ug/sprugm7d/sprugm7d.pdf

     

    Regards

    Mukul

  • Ok I see that it's been fixed in rev D of the System Guide (I was looking at rev C which has it backwards).

    -JV

  • hi mukul

    i have down loaded CCS 4.1.2 and i am using xds100v2 to connect to omap l138

    when i do a connect nothing happens,, not even gel script gets executed

    cn you help me with this

     

    ravi

  • Hi Ravi

    When you say "connect nothing happens" , are you trying to connect to ARM or DSP.

    Is this a custom board or the OMAPL138 EVM from LogicPD.

    I am hoping you have also seen the information provided on the wiki articles

    http://processors.wiki.ti.com/index.php/How_to_connect_to_the_OMAP-L138/C6748_EVM_board_using_CCS%3F

     

    There is an also update to the XDS100v2 CPLD code which will increase reliability. Please see: http://processors.wiki.ti.com/index.php/XDS100#Q:_My_XDS100v2_does_not_work_reliabily_with_the_OMAPL138_.2F_DM365_.2F_ARM926_core. for links to upgrade CPLD. Although if you are not able to connect and no error messages are popping up , your issue might be different.

    Regards

    Mukul

  • hi mukul thanks

    i am using a hawk board(loaded with linux and i am tryingto connect to it while its booting)

    1) i am trying to connect to ARM

    2) Is it safe to update CPLD,,, is it safe(i guess changes cannot be reverted back) and also is it backward compatible

    3) previously i had CCS 4.0.xx in that if selected XDS100v2 ,,,omapl138 target is not dispalyed ,,,, i use to connect to it selecting L137,,,, can you help me with this

     

    regards

    ravi

     

  • Hi Ravi

    I didn't realize you have a parallel thread with the same questions running in another forum post

    http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/46595/165229.aspx#165229

    I  believe Tommy has addressed your queries. If you have follow up queries on the response, please post them on that forum post.

    Regards

    Mukul

  • Hi JayVee,

    you got the pwm running on linux!!!?

    I try to use the pwm on a L138 experimenter board with the davinci git kernel.

    For me the Omap L138 eHRPWM is so close and yet so far at the moment.

    I configured the PWM-Registers like a simple example in the pwm User Guide.

    I can set and read the registers.

    I modified the pinmux register.

    Please tell me how to proper set the TBCLKSYNC bit in linux ?

    Whats your driver-module code to set this bit?

    Thank you very much,

    regards,

    Bastian.