Need help on SPI2

Hi Luan,

One typical mistake people do is not enabling the input buffer (by selecting the IN bit in the pinmux register) of the SPI CLK pin. In case this isn't set the SPI RX logic won't be clocked => You will always read 0. For a little further info please have a look at: http://elinux.org/BeagleBoard/SPI

 I hope this is your problem and that this helps :-) - Good luck
  Søren

Thank you Soren for your response.

I did set the pinmux register for Mode 0 ( SPI mode ) and input enable for SOMI.

Please let me know if you have another suggestion.

Luan

Hi Luan,

Please read my post again - You as well need to set the input enable for the SPI CLK line. Have you done this?
  Søren

Hi Soren,

It is working now.  I just wonder why the clock line is an output from the processor but input enable needs to be set for it to work.

Thank you for your help. 

Luan

Hi Luan,

You are welcome. The reason you need to set the CLK as INPUT (even though it driven by OMAP) is that the pad input buffer is used for feeding the clock to the RX path of the SPI IP. AFAIK this is done in order to account for the propagation delay the system might have. In case of using the clock directly the "original" internal clock in OMAP, it would be 2 time the buffer-delay (output of CLK line and input of SOMI line) ahead compared to the actual data transfer edges on the SOMI line.

Driving the input stage of the SPI IP block with the actual clock signal on the line ensure that you won't run in to problems with this. That being said I think the propagation delay is short compared to the 48MHz maximum SPI clock anyway, so there might not be any huge practical difference in real life. Tunning the input clock from the actual output pad is however pretty common in many silicon designs...

 I hope this explains the problem/feature - Glad that you made it work :-)
  Søren

Hi Soren,

Thank you for your explanation.  I got it now.

You are so helpful so I want to take advantage of you for another issue that I have with the OMAP3530 EVM.  I can write and read some of  the GPIO pins and not some others.  I try to do it in the Xloader so that there would not be any conflict caused by the BSP but also not working - writing does not cause any changes at these pins and reading always returns 0.  For example, I have the pin mux set up for 2 GPIO pins as below:

OUTREG16(&pConfig->CONTROL_PADCONF_MMC1_CLK, (INPUT_ENABLE | PULL_UP | MUX_MODE_4));

//GPIO_120

//GPIO_130

I can't not get GPIO_120 to work but I can with GPIO_130.  Actually, I can't not any of MMC1 pins to work as GPIO but I can with all MMC2 pins.

Clocks are enabled for all GPIO ports.

Again, I appreciate your help very much.

Luan

Hi Luan,

Luckily this is another of the typical "newbie" topics/problems you here hit :-)

Please see: http://processors.wiki.ti.com/index.php?title=Additional_Configuration_for_GPIO120-129_on_OMAP35x for a solution :-)

Only glad that I can help - Good luck
  Søren

Hi Soren,

Yes, I am new to OMAP and WinCE as well.  I am lucky that I got your help on my drivers development.  Here is another question for you.

Our company designs a single board computer after the OMAPEVM, using the OMAP3530 and similar Flash as well as SDRAM.  Copying the files MLO, ebootsd.nb0, and nk.bin from the EVM project onto a SD card, I am able to boot our custom board.  However, after eboot copies the OS image to SDRAM and jumps to the image launch address, the code crashes somewhere and I no longer see debug messages coming out on the COM3 debug terminal.  Using the same SD card, it can go all the way to show the window screen.

I dumped out the first 1024 long words before the jump, starting at the launch address, and the data are the same between the EVM and our custom board.  I also added code in the Eboot to test the SDRAM for the entire space except the Eboot portion.  The test passes.

As far as I know, Eboot is running in SDRAM, so SDRAM configurations should be OK.  Why does the OS not run?  Do you have any suggestions for me on how to debug this kind of problem?

Thanks,

Luan

Hi Luan,

Problems like these are always great fun :-) I'm not very familiar with booting WinCE, but hereby a couple of generic debug advices:

1. Double checke HW (using exact same memory-chip and connections) For a smaller physical memory MLO and eboot might work, while a bigger misconfigured Windows image might fail.
2. Do you have access to JTAG for single stepping the code - This is always nice when bringing up a (new) OS on a new board :-)
3. Put a printf/GPIO-flipping statement/llop at different places wuring initial WinCE boot in order to see where it fails
4. Readout and compare more than the 1024 bytes (ideally the complete memory - or several 1024 sections at various places you know needs to be identical)

Good luck - I hope this gave you a little inspiration
 Søren

PS: For another time please start another post for others to better find it in the future since the topic changed completely from the original SPI issue :-)