Kirk,

You probably need to enable the peripheral (and its clocks) using its 
CM_PER register in order to read and write its registers.

Let me look up the address in the TRM real quick and I'll post some 
psuedo-code.

Jason Reeder



On Wednesday, September 14, 2016 at 2:48:51 PM UTC-5, Kirk wrote:
>
>
> Jason,
>
> I'm trying to use the new sys_mcspi.h header file which you provided.
>
> I have a simple test program I adapted from some example code that toggles 
> a gpio pin which I monitor with a scope.
> I use the toggle rate seen on the scope to determine whether phaseBit is 
> zero or not.
> (the code is below)
>
> The code writes a 1 to the phase control bit in the SPI config register.
> Then it reads it back into the phaseBit variable.
>
>
> I figure if it writes a 1 it should read back a 1.
> Trouble is it's always reading back 0.
> The code does what is expected if I force a 1 or 0 into phaseBit
>
>
> Not sure what I'm doing wrong. (remember I'm new to PRU work)
>
> Do does the code have to do something to enable access to the SPI 
> registers?
>
> Thanks,
> Kirk
>
>
> /*
>  * Based on the examples distributed by TI
>  *
>  * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
>  *
>  *
>  * Redistribution and use in source and binary forms, with or without
>  * modification, are permitted provided that the following conditions
>  * are met:
>  *
>  * * Redistributions of source code must retain the above copyright
>  *  notice, this list of conditions and the following disclaimer.
>  *
>  * * Redistributions in binary form must reproduce the above copyright
>  *  notice, this list of conditions and the following disclaimer in the
>  *  documentation and/or other materials provided with the
>  *  distribution.
>  *
>  * * Neither the name of Texas Instruments Incorporated nor the names of
>  *  its contributors may be used to endorse or promote products derived
>  *  from this software without specific prior written permission.
>  *
>  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>  * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>  * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>  * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>  * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>  * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>  * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>  * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>  * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>  * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>  */
>
> #include <stdint.h>
> #include <pru_cfg.h>
> #include <pru_ctrl.h>
> #include <sys_mcspi.h>
> #include "resource_table_empty.h"
>
> volatile register uint32_t __R30;
> volatile register uint32_t __R31;
>
> void main(void)
> {
> volatile uint32_t gpio;
>
> volatile uint32_t phaseBit;
>
>
> /* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */
> CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
>
> // attempt to write an SPI configuration bit and read it back
> CT_MCSPI0.CH0CONF_bit.PHA = 0x1;
> phaseBit = CT_MCSPI0.CH0CONF_bit.PHA;
>
> // by forcing phaseBit to 0 or 1 here I get the expected toggle rate below
> // phaseBit = 1;
>
>
> /* Toggle GPO pins TODO: Figure out which to use */
> gpio = 0x000F;
>
> // if phaseBit is non-zero toggle fast, otherwise toggle slow
> while (1) {
> __R30 ^= gpio;
> if(phaseBit == 0)
> {
> __delay_cycles(1000000); // toggle at approx 100Hz
> }
> else
> {
> __delay_cycles(500000); // toggle at approx 200Hz
> }
>
> }
> }
>
>
>
>
> On Wednesday, September 7, 2016 at 3:55:36 AM UTC-7, Jason Reeder wrote:
>>
>> Kirk,
>>
>> Do a 'git pull' on your pru-software-support-package repo and the 
>> sys_mcspi.h files should be in the include/am335x/ folder. Let me know if 
>> you run into any problems while using it, I didn't have time to test it out.
>>
>> Jason Reeder
>>
>> On Saturday, September 3, 2016 at 8:30:56 AM UTC-5, Kirk wrote:
>>>
>>>
>>> OK, I see it now.  Thanks for pointing that out
>>> I overlooked it because I thought he pru_*.h files were specific to the 
>>> PRU peripherals.
>>> Should have looked closer.
>>>
>>> Here's the directory I'm looking in and the header files in it:
>>>
>>> /opt/source/pru-software-support-package/include/am335x
>>>
>>> pru_cfg.h
>>> pru_ctrl.h
>>> pru_ecap.h
>>> pru_iep.h
>>> pru_intc.h
>>> pru_uart.h
>>> sys_mailbox.h
>>> sys_pwmss.h
>>>
>>> I don't see anything for SPI0 and SPI1 on the host processor.
>>> I'll be needing to get at them too.
>>> Any ideas?
>>>
>>> Thanks,
>>> Kirk
>>>
>>>
>>>
>>> On Thursday, September 1, 2016 at 5:18:07 PM UTC-7, Jason Reeder wrote:
>>>>
>>>> Check out this header file in the PRU Software Support Package: 
>>>> https://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/master/include/am335x/sys_pwmss.h
>>>>  
>>>>
>>>> The eQEP, ePWM, and eCAP modules make up the PWMSS peripheral.
>>>
>>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4527ab0a-f1d1-451a-86bd-3b1b6fc731b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to