OMAP-L137 crystal connection

Harri,

It may be that the oscillator is not quite stable and is stopping the PLLs from locking correctly.

I would check that the load capacitors are of the correct value for the particular crystal you are using. This can sometime have a big effect on the crystal stability.

I don't think that connecting the grounds should be a problem, but you may get slightly better stability (ppm) if you follow the datasheet,

BR,

Steve

Hi Steve,

thanks for the super fast reply! I'm using this crystal: http://www.epsontoyocom.co.jp/english/product/Crystal/set02/tsx3225/index.html

It's 24MHz and I've tried 18pF and 15pF (calculated closest) as load caps. In both cases the signal is quite nice sine wave of 800 mV in OSCIN and a more distorted wave with quite a big over/undershoot at peaks in OSCOUT. Does this sound normal?

I also noticed that my RTC crystal isn't oscillating, that's why I got suspicious about the grounding in the first place. RTC not being enabled shouldn't prevent crystal oscillation, right?

Is there anything else than supply voltages (checked ok) and clock quality that makes OMAP refuse releasing reset? My BOOT[0..3,7] are all pulled low by 47k resistors. ~TRST is pulled low with 4k7 and CPU reset is pulled high with 10k.

I'm assuming that I could connect to the CPU with a JTAG ICE regardless of the boot mode (after getting it out of reset, of course), am I right?

Best Regards,

      Harri

Harri,

Unfortunately I don't really know too much more about the L137 at the moment, so can't really comment.

Here are some suggestions though...

Make sure RTC_CVDD is correctly supplied.

Make sure POR is correctly asserted then de-asserted.(see section "6.5.1 Power-On Reset (POR)" in the datasheet) The oscillator must be oscillating before the reset is de-asserted.

Make sure power supplies are stable before releasing reset.

If possible, try sourcing an external clock from an oscillator rather than a crystal, just as a test.

BR,

Steve

Ok, I'll check those. The fact that RTC_CVDD is crucial was really valuable information. I had a wrong diode casing in that rail and got no voltage in RTC_CVDD. Corrected that and got the RTC crystal oscillating but the CPU stays in reset. I then extended the ~RESET line rise time on power-up but had no success after that either.

I'll re-check the voltages and timings and try feeding the clock from a function generator as you suggested.

Thanks a lot for your help! I'll get back when I have something new to tell or ask you.

Best Regards,

    Harri

Now I have tried all things mentioned above. All voltages are spot on and no excess interferences. I removed the crystal-to-GND capacitors and fed the clock from a function generator (1Vpp square) to CLKIN. I varied the frequency from 1MHz to 20MHz and finally go connected with JTAG.

So, my next step was to try out the EVM gel file (evmc6747_dsp.gel) but it fails in PLL setup with a message

Trouble Writing Memory Block at 0x1c1403c on Page 0 of Length 0x4:
Error 0x00000002/-1060
Error during: Memory,
An unknown error prevented the emulator from accessing the processor
in a timely fashion.

This happens on the line

    PLL0_PLLCTL &=  0xFFFFFFFE;  /*PLL BYPASS MODE*/

Am I still far from success? The message is a bit awkward with its timing problem reference.

Furthermore, is there a better gel file to start with? I've designed my board similarly to EVMOMAPl137 as much as possible (ext SDRAM is on EMIFB, for example) but is there a better skeleton somewhere? I was surprised not to find anything corresponding to OMAP-L137 or even C6747 in the standard CCS 3.3 installation.

I really appreciate your help!

      Harri

Harri,

Are you able to manually write that value to the PLL0_PLLCTL register through a memory window?  Do you see the PLL REVID?  If not, please try to clear and setup the memory map again.

-Tommy

The problem is, I'm not getting far enough to try. When that error occurs, CCS offers to disconnect. Sometimes I've got farther when there's another popup saying the PLL function isn't proceeding and I can step out of it. Even after that my memory window doesn't respond. I've got some other error messages which indicate the JTAG connection is very unreliable right now.

I've noticed that OMAP is _hyper_sensitive about power line quality so I'm improving my filtering first before experimenting more with JTAG.

Thanks for your reply, I'll post my observations later.

     Harri

Harri,

To advance the debug process, can you edit the GEL file so that it bypasses PLL configuration?  You should still be able to connect to the device while it is in PLL-bypass mode.

-Tommy

Regardless of including PLL config or not, It halts to the error

Trouble Writing Memory Block at 0x1c14154 on Page 0 of Length 0x4:
Error 0x00000002/-1139
Error during: Memory,
Device driver: Emulation Connection Loss Detected on Target CPU.

which is in the BootConfig area according to the GEL. If I force it to proceed (click Cancel instead of Disconnect) it hangs in setting up power modules so that I have to kill the CCS window, it never reacts to anything else.

Power line quality doesn't seem to affect it, I tried to feed the 1.8V rail (which was the most noisy) with a lab power supply and got same results. I suppose I should do the same with all rails to be sure.

Btw, how sensitive is OMAP to over voltage? There's a slight possibility that I could have had a ~4V voltage in the 3.3V rail for a second or so when fiddling with power enables.

Thanks for your effort Tommy, I really appreciate it.

The address above is one of the PINMUX registers. If I comment out the line in PINMUX setup, I get another error on the next line. Sometimes it's

Trouble Writing Memory Block at 0x1c14168 on Page 0 of Length 0x4:
Error 0x00000002/-1139
Error during: Memory,
Device driver: Emulation Connection Loss Detected on Target CPU.

I suppose nobody can know what is the main reason for the malfunction. I'll re-check my clocks and try to make sure they are stable.

Edit: more info is that I noticed my 3.3V line makes a huge drop during the connect., ~1.6V which certainly is more than can be tolerated. Some of the times the error message has said there's target power loss. So that's my next issue to take care of before even hoping for a successful connection.

 Edit 2: Now I'm feeding the 3.3V from a lab supply and get no more power losses. Even PLL setup finishes ok, but the script hangs in the PSC setup. Canceling the excution drops me to the CCS window and I can even see and change the CPU registers. Disassembly shows dashes but if I choose 'Reset CPU" it shows disassembly at addr 0x700000. If I try to write '1' to PTCMD register bits, they go back to zero and PTSTAT doesn't change. That explains the script hanging in PSC setup. And this happens in every PSC0_lPSC_enable() call. Any hints about that?

Btw, should the ~RESETOUT pin really indicate CPU state at all times (except when configured as AMUTE0)? I noticed it stays low even on the EVMOMAP board and it works and connects ok.

I'm writing a reply in case nobody has read my previous edited post and waits for an email. In addition to the above, I'll add one question:

Since it definitely is a problem that my 3.3V line drops during JTAG connect, how high is the current spike OMAP draws during GEL setup? I'm feeding 3.3V with a LDO which is capable of sourcing 400mA, is that really not enough?

Harri,

I would not expect to see that much power draw on the 3.3V supply just by plugging into JTAG.  I think the next step will be to find out if there is contention somewhere that is sinking the current.

The AMUTE0/RESETOUT pin is supposed to behave as an open-drain when the RESETOUT function is selected so a pull-up should be attached to see RESETOUT toggle.

-Tommy

Ok, thanks for the clarification for the RESETOUT function. I've made some progress with the board, too. It turned out that the board had been damaged during my severe testing. I stripped another board of the power supply and fed all three required voltages with a lab supply. Now I'm able to connect with JTAG without errors and load code into the internal RAM. So I'll just have to correct my power supply portion and should be fine (easy to say...).

I suppose I should start another thread about the new issues but I'm using this one for the first simple questions because you're following this one.

For my exterdan SDRAM, I'm using EMIFB just like the EVM. However, I can't see it with CCS memory window in the base address 0xC000 0000. Could it be because my SDRAM configuration differs from the chips used in the EVM? The EVM has IS42S16160B-6BL (4M x16x4 Banks) whereas I have IS42S16320B-7BLI (8M x16x4 Banks). I can't see why that could make a difference in EMIFB config registers but does it?

Another question is, where can I find the error codes for the tests found in %INSTALL_DIR%\boards\evmomapl137_v1\dsp\tests? I'm getting error 191 from SDRAM test and error code 32 for the UART.

Thanks again!

Harri,

Glad your board is working.

The "error code" is included in the test .c files (you can see them included in the projects).  You can also set a breakpoint in CCS where the test function is called and step into the function to see where the code execution leads to.

If EMIFB is not configured properly you will not see valid data in the memory window.  This would include LPSC enable, clock settings, SDRAM architecture, and memory timings.  Different SDRAMs have different timings so you must verify and update the EMIF settings as needed.  Please start a new thread if you need to dig deeper.

-Tommy

Thanks, Tommy! As for the last post in this thread, I'm canceling the SDRAM problem :)  I just had forgot to uncomment the GEL  EMIF initializations after my previous trials. SDRAM is working fine, the test passed and I can execute programs in SDRAM. I'll dig the UART error codes from the source.

Thanks a lot for your help!

Where can I find sample code for the OMAP-L138 of an I2C driver that uses DMA?  I'm trying to figure out how much of the transaction (start / stop) is handled automatically, and whether the transaction should be started using the DMA registers to fire off the event, or the I2C registers.

Thanks,

m++

Check out the BIOS PSP driver kit at  http://software-dl.ti.com/dsps/dsps_public_sw/psp/BIOSPSP/02_10_01/index_FDS.html

Regards,

Sandeep K