• State Answer Suggested
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 820 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.

How do I configure McSPI3 on Variscite's OMAP3730 (DM3730)

John Drinkall
Prodigy 60 points
Other Parts Discussed in Thread: OMAP3530

There must be a black art to this, as I've not been able to do this so far. I've changed the bootloader to add in MCSPI3_PADS in initialPinMux. I've changed the MUXMode to be 1, since looking at Table 13-4 Core Control Module Pad Configuration Register fields, it seems to want to be MuxMode 1 rather than 0.

 

I've then written a simple application that uses the IOStream interfaces (CreateFile, and DeviceIoControl to configure and read write status registers, but I'm not seeing anything.

 

1. Do I need to enable the clock for SPI3, or does the driver handle it? [I've tried EnableDeviceClocks(OMAP_DEVICE_MCSPI3, TRUE); in Eboot and that doesn't seem to have an effect.]

2. I've also tried this in eboot, rather than xldr

    OUTREG16(&pConfig->CONTROL_PADCONF_MMC2_DAT3, (INPUT_DISABLE | MUX_MODE_1));

/* McSPI3_CS0  */\

OUTREG16(&pConfig->CONTROL_PADCONF_MMC2_DAT2, (INPUT_DISABLE | MUX_MODE_1));

/* McSPI3_CS1  */\

    OUTREG16(&pConfig->CONTROL_PADCONF_MMC2_DAT0, (INPUT_ENABLE | MUX_MODE_1));

/* McSPI3_SOMI */\

    OUTREG16(&pConfig->CONTROL_PADCONF_MMC2_CMD, (INPUT_DISABLE | MUX_MODE_1));

/* McSPI3_SIMO */\

    OUTREG16(&pConfig->CONTROL_PADCONF_MMC2_CLK, (INPUT_ENABLE | MUX_MODE_1));

/* McSPI3_CLK  */

 

I've also added it into the OS image, and checked that it's there, active in the running drivers list.

 

I've spent a couple of days on this now, something that should be trivial, yet the complexity of Windows CE means that it's a nightmare to get it working. Any pointers would be much appreciated.

 

Thanks John Dr.

 

  • 0
    Mastermind 9310 points

    Hi,

    What reference BSP is your BSP based on? 6.15 or unified 2.30?

    If it is the latter, it does not include out-of-the-box support for MCSPI3 but can be arranged pretty easily.

    - Under PLATFORM\EVM_OMAP3530\SRC\INC\bsp_padcfg.h:

    You need to add an MCSPI3_PADS entry containing the configurationd detailed above.

    - Under PLATFORM\EVM_OMAP3530\SRC\BSP_COMMON\BSP_PADCFG\bsp_padcfg.c

    Add the following declaration:

    const PAD_INFO MCSPI3Pads[] = {MCSPI3_PADS END_OF_PAD_ARRAY};

    And add proper match in the switch case function:

    case OMAP_DEVICE_MCSPI3: return MCSPI3Pads;

    After that you can select SPI3 in the catalog and rebuild your BSP. For your test application refer to the SPI test app under PLATFORM\EVM_OMAP3530\SRC\test\Tux_SPI to see an example on how to use the "sdk_spi.h" interface.

    If you are based on the 6.15 BSP, all PIN mux should be done in XLDR as you tried above. In any case you don't need to manually enable the clocks, those should be automatically handled by the driver.

     

     

     

  • 0 in reply to Adeneo Embedded support team
    Prodigy 60 points

    Hi,

     

    1. How do I find out what the BSP is based upon?

    2. Looking in those files, I already have those changes in there.

    3. I've also tried adding a call to configure the pads in OALLIB init.c - since the configuration settings seemed to be overwritten if they were just placed in the XLDR.

    4. I've also changed the pad settings in the SPI driver - since some of them were still not the same as the values I set in OALLIB.

    5. Thanks for the info on Tux. I'll check that out.

     

    Is there anywhere else these pin mux settings could be set?

  • 0 in reply to John Drinkall
    Mastermind 9310 points

    1.2. If you found those files, it means you are based on the unified 2.30 BSP

    3. You are not supposed to that, the driver should do it by a call to RequestDevicePads. OAL init only request pads required by the OAL functions, not drivers. Note that requested pads are reserved and cannot be requested twice, hence you should always check out the return code of RequestDevicePads. In the SPI dirver, it should issue an error message in case of a conflict.

    4. Where exaclty in the SPI driver did you change those? Direct pad configuration should not appear in a driver, only a call to RequestDevicePads should be used.

  • 0 in reply to Adeneo Embedded support team
    Prodigy 60 points

    I changed them in SPI_INIT. I'll check RequestDevicePads return value and see what it says.

     

    Also I don't have a test for SPI in my src\test directory - there was one in smdk6410\src\test - but that looks to be calling a different driver the IoCTL definitions are different.

    My plaform is based on the VAR-SOM-OM37 BSP, which I guess based on your unified BSP.

     

    So I should be altering the pads in the XLDR? I tried that and they had different values by the time the driver was called.

     

    Thanks

     

    John

  • 0 in reply to John Drinkall
    Prodigy 60 points

    With some help I can now see output on my SPI3 line, but the CS0 and MOSI lines seem to be picking up data from something else.

     

    the pins are MMC2_DAT3 and MMC2_CMD. I can't see these being set anywhere - has anyone else seen this?

     

    Cheers

     

    J

     

  • 0 in reply to John Drinkall
    Prodigy 60 points

    I've set the pin mux for SPI3 in the XLDR.

     

    When the driver loads, after RequestDevicePads has been called I've checked the values in the registers and they are not the settings that I specified in the Xldr. Is there anywhere else that this is configured?

     

    Thanks J