BiSS solution fails to detect I/O

I will forward this to the ISDK team.

Hi David;

    Thanks for taking time to respond. This project is rather important to me and I really appreciate your help. First I am working with the tidu794a document which has quite a lot of good information on the design and operation of the firmware package and wiring changes for the IDK card. I did make some progress on Friday. While leaving the firmware trapped in it's ACK hunt loop with a small change to cause an infinite loop in it, I was able to trace my xmit problem to a faulty solder joint on the mod for shorting R422. Once repaired, I was able to see the 333 Hz signal going out. Fine, but I still have no response from the encoder or the IDK is not yet seeing the signal.  Could there be an electrical incompatility between the encoder and the RS-485 receiver? How about the signal and digital grounds? Must I have the chassis ground of the encoder connected to the IDK? Right now it's just the 2 return wires Rx(-) and Rx(+), 2 xmit wires  and the power connections +/- 5VDC from the IDK powering the encoder. I had a problem with the CAN bus along these lines that were comfounding till we worked them out. Any clues here would be helpful. I will recheck the wiring changes on the Rx side again to be sure I don't have similar problems.

Hi David;
More progress. Looks like I had both the Rx+/- and Tx+/- reversed. Corrected that and got around 1 sec worth of return signal from the encoder. Now I think I have a framing or logic problem of some sort with the firmware. Any suggestions?
Aaron

Hi David;

    Good news! I seem to have the encoder running. It is producing a return signal that matches the Master Design Doc exhibits. When rotating the encoder, it definitely indicates changes in the data core waveform. My next problem is to use the post process program block to activate an interrupt to have the ARM core fetch the data off the shared memory block. Any references and suggestions you can make along these lines would be much appreciated. There is no advice in the design doc at all along these lines and I think there should be. Also, now looking forward to the production configuration where I need to set up a (.KO?) binary load to be able to boot and run on power up. References to good examples and any tricks and technique you can suggest here would also be useful.

Thanks again for your time.

Aaron

Hi David;

    Thanks again for your reply.

     Well, I read thru the EnDat Master. Man, there would be a lot of work to convert this over to the BiSS firmware interface. I don't think even the shared memory addressing is the same. Also, many functions would need to be cut away and the shared mem and intc would still need to be invented for the BiSS firmware. I was hoping that there was a more complete example. At least a 'C' driver for the firmware. Even the PRU driver is set up for unix. Is there a Windows port for this lib?

Thanks,

Aaron

Hi David;
OK, so in reviewing most of the examples in the .86 dev kit given for the PRU use the prussdrv.c et al driver code to implement the low level 'C' interface the ARM has with the PRU. However this code will not compile. It has various function call references, defines etc. That are not present in any of the code I have downloaded so far. Do you know what code environment has these code references? If I know what these calls and defines are supposed to represent, I can rewrite for my port.
Aaron Kellner

Hi David;

    I am using the RTOS not Linux. But I wasn't aware of the existence of the driver you mention. I my scanning of the files I have including the Endat master diagnostic  program, it wasn't clear one existed. Maybe it should be in the comments somewhere? I'll look into the training guide and see what I can do with it. Hopefully it will work. Thanks for your help!

Aaron

Hi David;

    Now having problems building the LLD\pruicss_drv et. al. as a ARM lib to access the PRUs. Is there a ready made CCS project file? I tried to concoct my own but there are so many paths and dependancies that I'm not sure everything is being included with the correct paths nor which versions match. I am getting deep down in the xdc tools 'undefined' errors on some of the core structs. I'll list what I have built with:

bios_6_45_01_29, sysbios_ind_sdk_2.1.1.2, xdctools_3_32_00_06_core

looks like basic types from types.h are not being found. i.e. xdc_bits16, xdc_bits32, IGate_Provider_Handle, etc.

Any clues on how this is supposed to fit together?

Thanks for your time,

Aaron Kellner

Hi David;
Thanks again for your reply. I have the correct XDC tool version, but the download package for sys/bios comes with the newer versions. How do I find the old ones?
Aaron Kellner

Hi David;

   I was hoping it would have been as easy as downgrading to the matching version, but no, still not building. Any other suggestions? Maybe a makefile somewhere I could use as the template?

Aaron Kellner

Hi David;
I beat the compile problem down to a compile time error in HWI.H. The preprocessor error is "#error "target not supported by legacy HWI module". Further analysis showed that the Sitara doesn't seem to be supported by the •SYS/BIOS 6.42.2.29 Real Time Operating System that is recommended in the Software list in your earlier post. Further the directory trees are really quite different between the 6.42 and 6.45 versions making selective use problematical. I see in this post you are using 6.42.3.35. Is that version supporting the Sitara? Or another waste of time? It's clear this sys_bios_driver lib is key to the ARM/PRUSS integration. Can you please advise on the build?

Hi Aaron

I apologize the SYSBIOS version should be  SYS/BIOS 6.42.2.29. It was a incorrect selection on my part.

David

Hi David;
As I mentioned, the version you quote above 6.42.2.29, doesn't work for the Sitara. I did however get it to compile. Had to do 2 things. 1) Build with 6.45.00.19, a step below the current rel, and modify BIOS.H to eliminate the conditional compile around the PREFIX ALIASES since there was no reason not to include them in the build. Then I got an absolutely clean build except for a warning on the rel version on an out of range index in the EMAC section. Analysis showed it may be intentional so I left it.
Quite a battle.
As I review the example code, I note that almost none of what I have, is designed to work with the driver I just made? You're saying Endat Master uses it, I will take a look to see if I can build that and modify from there.

Aaron

Some explanation is needed.
There are some differences between the motor control and the EnDat diagnostic.

In the motor control example, we use the periodic triggered mode of the EnDat firmware.

The EnDat diagnostic uses the host triggered mode of the firmware. To configure periodic triggered mode ICSS_L IEP CMP2 only needs to be setup with required timing for periodic trigger mode.

In the motor control example, - this is done by ADC PRU (OnChip/SDDF). The PRU indicates completion by clearing of particular bit through the shared memory interface). The relevant bit is the LSbit of byte @0x54440002. In host trigger mode, host will set this bit & EnDat firmware will clear upon command completion.

In periodic trigger mode, upon periodic event, the EnDat firmware will set this bit (before starting EnDat command) & will clear it upon command completion.

The sddf design guide in {IA_SDK_HOME}\interfaces\sddf\doc has some additional information. Note - references to CMP2 in this document should be CMP1.

1. In host triggered mode - host triggers command send

2. In host triggered mode, as well as the periodic trigger mode, - the user has to wait until the command is finished to get received data

3. In periodic trigger mode, the IEP CMP2 event triggers command send, however there is a perquisite - that host sets up the command to be sent beforehand

4. Although in periodic trigger mode the host has to wait till command process is finished. Note - in the FOC code the EnDat trigger is synchronized to the FOC interrupt such that by the time FOC interrupt happens the last EnDat command is guaranteed to complete.
This keeps to keep the interrupt handling code light weight so that there is no wait for the command completion. Additionally, to keep interrupt handling code to minimum, “endat_get_2_2_angle()” is invoked (command setup in FOC is EnDat 2.2 position) instead of an alternative (more lengthily) method which would be a combination of “endat_recvd_process()” & “endat_recvd_validate()” as done in EnDat diagnostic example.

5. In the current release, Reg triggering of EnDat so that it occurs with the PWM event in the FOC , is implemented when the Sigma Delta is used for the ADC input. (This does not occur when the ADC is used)
In the next release (2.1.2), Reg triggering EnDat with PWM event will be available for both Chip ADC and Sigma Delta input.

6. In the motor control example all of the components of the drive system are synchronized in Sigma Delta in the current release. The same will be true with the on Chip ADC with next release. The IEP counter is configured by ADC PRU to reset on PWM3 SYNCOUT (which in turn is configured to trigger at PWM start), CMP1 is programmed to trigger ADC SOC from PWM start & CMP2 to trigger EnDat from PWM start. The FOC interrupt is triggered indirectly on ADC EOC (via an event by ADC PRU upon detecting actual ADC EOC). In effect ADC, EnDat & FOC interrupt is in synchronization with PWM.

David

Hi David;

   It's been a while. I am now in the process of stripping down the 'endat_diagnostic' down to what I need for BiSS which in fact is totally different than the algorithm used in the endat pgrm. First I needed a synchronous interrupt to propagate from the BiSS firmware all the way to output on an LED pin I could then  use in the upstream system for every rec'd message. I have so far only installed this via system event bit enable on R31.b0 = 0x24 in the firmware. I got the code line from the PRU_industrialEthernetTimer code which uses this to interrupt the ARM after a timer interval and preamble written in 'C' for Linux. However, I believe that I can do the preamble on the ARM side and just have the firmware set the bit to engage the int which the ARM side can ten clear in the HWI handler. The method of data exchange should be similar and much simpler. I don't need to adjust timing so that's also redacted. 

My question is, can one do the event mapping from the ARM side?

Hi David;
After more research, I don't see why I can't use the XDC to map the interrupt back to the ARM system. The question then becomes, what event and what intc number I should use on the RTOS side and then what bit in the pru0 R31 reg is the one I set to fire the event? I assume it can only be the 0 or 1 bit since I only get the 2 pru to ARM interrupts, correct? So what event number does the XDC set up for?
Aaron

Hi David;

  Had a few days off and finally got back to this problem. Re-wrote most of the monitor program to simplify and port over to the BiSS firmware operation. Started to debug it and got stuck at the firmware load off of the header file buffer. The preamble looks good as well as all the magic number addresses that were supplied by the Endat  Diagnostic program. All this code is basically identical to the Endat stuff. I traced the problem to the actual PRUICSS_pruWriteMemory() loop. Obviously this loops a coupla' thousand times as each byte is loaded. Somewhere in the course of this loop the load fails.  S a coupla' questions: 1) What is the correct width to set the header file generator to for the prudriver to use, 1 or 4? I tried bot neither works. But knowing would help. 2) There appears to be a compile option to MEM_BARRIER_DISABLE for the pru driver code. How does this switch get set? 3) Anything else you can think of that would stop the load from proceeding.

Thanks for your time.

Hi Aaron,

i am blissfully ignorant of BiSS, will do my bit as possible to help morph EnDat application to BiSS one.

Seems PRUICSS_pruExecProgram() is getting hung @PRUICSS_pruWriteMemory(). Before that, is PRUICSS_setPRUBuffer() invoked over C array format of BiSS PRU firmware ?, similar to that for EnDat (as in EnDatFirmware array @interfaces/endat_master/firmware/edat_master_bin.h).

Or another way - use endat_diagnostic application as is, but replace EnDatFirmware[] with the one for BiSS, put a infinite loop after PRUICSS_pruExecProgram() and see whether BiSS firmware starts executing in PRU (in console, single channel option would have to be selected & when prompted for channel number, give 0 so as to get above mentioned array contents loaded to PRU). This will help know whether something was missed while application was re-written. And may be, even before that, build endat_diagnostic appication as is & check that EnDat firmware is running in PRU to make sure that your setup is fine.

Regards
afzal

Hi Afzal;
Trying to get some insight on why my version of the endat diagnostic is failing to start the PRU. I wrote an abbreviated version just taking the initialization and firmware load section for testing the use of an interrupt from the PRU to the ARM. I used the firmware from the PRU_Timer example. If I load it just like the BiSS firmware using the BiSS GEL scripts it runs the PRU and halts after the expected timer delay. However, attempting to load and run it using the code from endat to initialize and run doesn't work. Seems like the firmware is loading, but looks like the PRU clock doesn't run since the firmware jumps to the HALT immediately. Thus I don't see any time delay. I tried to get the proper processor setup by copying the GEL file operations as they work to load and run the firmware. Can you suggest a debugging strategy?
Aaron

Hi Afzal;
I haven't had any luck in trying to get the firmware loaded so I started scanning the Ti E2E blog. found that there is a problem with loading the PRU. See git.ti.com/.../master. Could this be part of the problem?

Anyone???

Hi Aaron

On July 13 there was a release of v02.01.02.02 of the ISDK, which includes an EnDat design document and the EnDat firmware source. The EnDat design document is located in {IA_SDK_HOME\interfaces\endat_master\doc.

This release does not contain changes to the EnDat Example application, the EnDat Driver or the PRUICSS LLD. However there are good improvements in documentation and in the descriptions contained in the include files.

David

Hi David;

   Nice to hear from you again. Well, I've been rebuilding the SYS_BIOS_DRIVER lib as necessary to try to get this to work in the debug mode. Maybe that's my mistake, anyway, even if I get the timer test firmware load in word by word then allow the PRU to reset enable and start the clock as the GEL files do, I can't seem to get the PRU to run the firmware. SO I have to believe that somehow the ARM load is not working across the internal buses. I am sure that I am calling to enable the OCP master for instance 0 of the PRU. Can't figure why the PRU won't run. Can you reflect any ways I could debug this?

Thanks,

Aaron

Hi David;
Just like to point out that there is no firmware for the endat program and no ARM code for the BiSS program. So who knows if either really works? At this point I would doubt it. I was never able to get your "industrial Ethernet" solutions working either. Maybe the ARM processor is a good product, but I doubt strongly that the PRUs are functional. You can't even tell me how to debug the system.

Hi Aaron

It has been a long path. I appreciate your patience.
Hopefully the improvements in the latest release, ISDK 02.01.02.01, for the EnDat documentation and firmware will provide much more visibility into the EnDat implementation and operation. Using the defaults for installation the firmware will be at C:\ti\sysbios_ind_sdk_02.01.02.02\sdk\interfaces\endat_master\firmware . The documentation is at C:\ti\sysbios_ind_sdk_02.01.02.02\sdk\interfaces\endat_master\doc.

When using a debug configuration, it is often necessary to substantially increase the SYSBIOS Heap and stack SYSBIOS settings in the .cfg file.

Often it is advantageous to create a shell program which contains the basic initialization and run configuration to validate the initialization and running of the PRU. This also provides a convenient example to show where the problems are occurring. A simple PRU code could be something as simple as a set and clear of a bit in R30 and to see an external pin toggled. This is a pertinent since the BISS clock is generated in this manner.

David

Hi David;
The idea of a "shell program" is exactly what I have been doing with the PRU industrial timer example port over to SYS_BIOS. I am using its firmware which is, as you say, all of 9 words of code to implement a timer that runs down after 21 secs and fires the R31 bit 1 interrupt. In theory it should go out to the ARM. Here is the result I have. If I use the GEL scripts I have from the BiSS firmware test that did get output on the Biss bus, I am able to see the PRU run for the appropriate time then suspend. So the PRU will take and run if it has the firmware shoved down its throat. Proved both with BiSS and the timer. On the ARM side is where the struggle has been. Despite messing with all the sys enables and resets used first in the endat program examples, then from the GEL scripts to get the PRU to take the load and run under the ARM, mule like, it refuses.
You say that there is new software to update the endat with. I'll check it out.
At this point I am thinking of using a BiSS interface card and just using the IDK for the console and interface via the ARM.
Everyone's patience comes to an end at some point.
Too bad, we had bigger plans for this part.
Aaron

Hi David;
Took a look around for the SDK ver you mention, can't find it. Got a link?

Hi Aaron

It is at http://downloads.ti.com/sitara_indus/esd/SYSBIOSSDK-IND-SITARA/latest/index_FDS.html

SYSBIOSSDK-IND-SITARA  02_01_02_02

David

Hi Dave;

    I appreciate your efforts in helping me to try to use this part and recommending the new version of the SDK. As it happens your assumptions are unfounded. As I reviewed the code which has become too familiar to me these past few days, I see no difference in any of it. The firmware read of the endat stuff was interesting, but unhelpful. I have to believe that there is some hidden register setting I am missing. Are you sure this code works? Have you ever seen it read an encoder? If so did you build the code for yourself when you saw it happen? I tend to think not. I should have realized that as soon as I started working the BiSS firmware with no ARM interface code supplied. It wasn't supplied because it doesn't work. No, the PRU will not load from the driver code you supply. I have ordered a BiSS interface card and will use the ARM as its console since the ARM works great as billed. If you can convince me that this code set actually works, I will reconsider it for our system again. Maybe.

Thanks again for your efforts,

Aaron

Hi David;
Well, tried and tried, could never get an interrupt back from the PRU nor confirm that it was loading code. BTW I could never get the clock on it running either far as I could tell by using the register setting method either.
Now trying to implement the McSPI interface on SPI0, correct me if I'm wrong, pinning out on the J16 expansion socket of my Industrial IDK at pins 24 = CLK, 26 = DIN, 28 = DOUT and 30 = CS. I have looked thru the examples given and found one showing the 4379 exactly. It's at "...PDK_am437x_1_0_2/packages/ti/drv/spi/example/mcspi_serializer".
I found the Library and understand the data flow based on the following document processors.wiki.ti.com/.../StarterWare_McSPI. Is this correct? I will try once again to build and run your example code. My question is, does this all sound right and am using the example I should be? My target is the BiSS interface chip, the MB4 from ICHause. I will be using the SPI to operate it instead of the uncooperative PRU. It runs at ~ 1 Mhz on the SPI bus. Do I need to use interrupts or Callbacks from the SPI to manage the data rate? Please advise.
Thanks,
Aaroni

Hi David;
Once again foiled by TI's out of date examples. Apparently all the configuration lib calls are failing. Any suggestions? Newer examples? Notes on what's changed over time? Anyone?
Aaron

Hi Aaron

The SYSBIOS Industrial SDK and Processor SDK are different software platforms. It is difficult to port applications between the two.

If you are looking for a SPI example to include in the SYSBIOS SDK there is a input  example in the example utils.

at C:\ti\sysbios_ind_sdk_02.01.02.02\sdk\examples\example_utils\example_utils.c .This uses SPI0 to control a

SN65HVS882 to read 8 digital inputs.  This uses SPI0 which is shared.

To change this for your interface will require defining the new SPI interface at the sysbios and starterware board libraries. 

I use a grep tool to rapidly find the related references in different files. 

A word of caution - When building an application in sdk_02.01.02.02 it uses

• Code Composer Studio version CCS 6.1.2.00015
• Industrial SDK version 2.1.2
• SYS/BIOS 6.45.01.29 Real Time Operating System
• XDC Tool 3.32.00.06
• NDK 2.24.3.35
• Compiler GNU v4.8.4 (Linaro

 as described in http://processors.wiki.ti.com/index.php/SYSBIOS_Industrial_SDK_02.01.02_User_Guide#Software.C2.A0

David

Hi David;

   I don't know exactly what you're talking about with the example_utils program. I see that it does do a simple exercise of the LCD output. and I have used this very program as a jumping off point for many of the tests I have run since the framework is a good driver base. But there is no interface to any HV chip in it. Further I have found references to McSPI interface device driver in the utils lib device driver code. Therefore I know there is a good place to start. My problem is that the theory of operation of the driver code. No documentation that matches what I see. Please check out the header "mcspi.h" and "mcspi_board.h". I can include these in my program set the path to sysbios_ind_sdk_02.01.02.02\sdk\board\include\ and it will compile and link with the utils lib. Then I can use calls in the header to operate the lib which has all the essential MCSPI operators like reset config etc... BUT, the header documentation is very very poor in describing what I need to do to use these great abilities. Are you saying that I should look at the LCD driver to get a clue? Does it use the MCSPI?

Aaron

Hi David;
Yeah, after I read your comment on the HVS882, I looked into the pin config situation. Turns out the pins I was thinking about using are mapped to the PRU ICSS 1. Is there any way to re-map them? I was thinking of trying the PINMUX tool to see if I could do it. The other option is to simply re-purpose the 882 interface. I need 2 way comms of course, but I don't need digital input so might be a good trade off. Not too much new code to write. I see I'll need to re-wire at R437, R111, R99 and R105 to my MB4 card. It's not clear from the schematic, is pin B14 marked LD the actual data/serial line? Is that the one I need to make Tx/Rx?
Thanks for your patience,
Aaron

Hi David;

    Well, I took a look at the PINMUX tool last nite, since I can't use it from work, and discovered that indeed the pins extended on the J16 IDK connector for the processor marked SPI0 are indeed connected directly to the SPI0 device in the Sitara. In fact the PRU is a redirected resource to them. I generated a new PINMUX file set which uses these pins directly as is noted by the PINMUX tool and will attempt to edit them into the supplied mapping as an instance to the MCSPI instance chain. And I'll eliminate the instance that maps the PRU. I'll let you know if I can get the SPI0 to deploy on the required pins. If so, it's an interesting solution that I didn't see documented anywhere. Not everyone wants to mess around with those PRUs if they can derate to a easier implementation.

   I had another unrelated question. I am trying to walk into the board_support lib and for whatever reason the debugger won't enter that code. I don't even get the 'select source location' dialog to point to the source. The debugger simply walks over the calls to this lib. Any clues on what's wrong?

BTW, on the endat program, I spent a lot of time on it only to discover that it uses polling not interrupts to fish data from the PRU. Not ideal. Also compiled the EMAC connection layer example only to discover that it doesn't have a net layer. Do you have a suggestion on what I could use for that?

Aaron

Hi JJ

The data sheet contains the description of the pinmux settings in the Pin Attributes table which can help you investigate configuration options. When configuring only a few pins it can sometimes be practical to directly configure the pinmux registers.

When debugging you can include the {IA_SDK_HOME} /board/board_support.c {IA_SDK_HOME}/starterware/board/board_am43xx.c as part of your project. You will have some difficulty seeing some of the structures because they are declared static. To get around this you can declare them in the main application and reference them as external elsewhere. Depending upon the amount of visibility that is needed - it sometimes is necessary to rebuild the libraries for debug mode. When rebuilding the libraries to support debug mode - it is often necessary to significantly increase the app.cfg settings for stack and heap.

Typically we use the Network Development Kit (NDK) which provides services like TCP/IP. The ICSS-EMAC contains support for the NDK. There is a short discussion of this in the processors.wiki.ti.com/.../ICSS_EMAC_LLD_developers_guide
Alternatively the Ethernet/IP example can be modified to work as a Switch application by removing the Ethernet/IP dependencies. The steps to create Switch application can be found at processors.wiki.ti.com/.../SYSBIOS_ISDK_Steps_for_creating_stand_alone_switch_example


David

Hi David;

    Checking in with you again for more advice. I followed the doc 'Board and CHIPDB Details' and seemed to have added the SPI0 instance of the SPI resource to the system. I have added a new instance of the SPI in am337xx.c with an ID, added a "MOD" id and a case in the board support.c to call a special init() function for this instance. As I walk thru the initialization process, it looks and works identical to the HVS882 instance but no GPIO pins are set up since the PINMUX tool didn't call any out. Also the I2C bus there before didn't use GPIO for these pins either. So the pinmux operation uses the designated pins for the MCSPI0 channel. So far so good. Problem is that when I try to force the Cs signal by calling the MCSPIAssert() call with my instance (the same one used by the 882 code), nothing happens on my scope. Checking the 882 for the DigIn operation does show.So I tried adjusting all the defaults like the ctrlinfo member in the config id list, reversing polarity in my init call before making the final PRCM call, changing the pin modes  in the pinmux list, adjusting the pinmux bits to be different than the 882 (no pull up, pull down etc.) all to no effect. My question is what else could be wrong? I started the effort trying to mimic the setup for the 882 bus at MCSPI0 instead of MCSPI1 while eliminating the I2C bus that was formally set up on 2 of those pins. From what I can analyze on my new code edits, they should have worked unless the multiplexing that is supposed to occur on T22 and T21 is failing. Any thought on how to debug?

Aaron

Hi David;
OK here's more unexplained problems. Since I couldn't get the new SPI0 running based on the use of the MCSPICsAssert() and corresponding DeAssert calls while viewing the output Cs0 pin of MCSPI0 at T20 or pin 30 of J16. I figured I would try the same test on the working 882 SPI1 instance with the Cs line output at A16 and at R99 using the force assert and deassert like I was trying for the SPI0 test. Nothing doing. The calls to force the de/assert don't work even on a working instance. What's up with that? If I send a command to get the Digin, I can clearly see the Cs line working at the pin noted above (R99). Maybe you can shed some light?
Aaron

Hi David;

    OK, I figured out the assert/deassert problem. The SPI channel must be in SINGLE mode and you cannot have more than one channel in operation for a SPI CS force operation to work. This code was left in for the build as a 335x option or whatever. However, it's confusing as such without any notation on it as to it's conditional operational nature, again poor documentation.

I have an additional question in attempting to get the SPI0 channel open on the required pins T22,21,20 & P23 for the output on J16. There are 4 bits in the CTRL_CONF_SPI0_SCLK register description on pg 871 of the AM4379 manual that may be key to the pins function . These are marked CONF_SPI0_SCLK_MMODE and described as "pad functional Signal Mux". I've looked thru the 41 hundred odd pages of the manual and can't seem to find what exactly this means. I note that the output of the PINMUX tool assigns these to zero, but the former assignment via the pesky PRUSS device, has the pins assigned the value 6. What do they need to be and how do I find the bit definitions?

Thanks,

Aaron 

Hi David;
OK, so with the MCSPI_CH_SINGLE setting on SPI0 I can now force the Cs pin at will. Scope proves it. But still no action on the data and clock pins. This despite scrupulous attention to the settings on the pins and correct enabling of the channel before sending. I am still using the exact same code that was used in the UTILS program to run the SPI input from the 882. As I say the Cs works fine with it. So I'm very close to correct, still not right though. Any debug ideas?
Aaron

Hi David;
Well, good news, I played around with the comm modes and MCSPI_DATA_LINE_COMM_MODE_1 did the trick, 7 is the default. So I had to throw away the parallel input for the sake of the SPI0 channel working as required. I could go back and try it all again to see if I can figure out why this setup works and see if I can get the second channel up, but there are way to many ill defined parts here to make the time worth the outcome. Especially since I have no need of the parallel input at this time. Can you say exactly what the comm modes actually do? I read the documentation and there are sums of masks involved but what do the masks configure? It's not really clear at all from the explanations.
Aaron

Hi Aaron

Are you looking at the modes under typedef enum mcspiDataLineCommMode in mcspi.h?

These set the value of the  MCSPI_CH0CONF,  MCSPI_CH1CONF, ... registers

For example,

    MCSPI_DATA_LINE_COMM_MODE_1 = (MCSPI_CHCONF_IS_LINE0 |
                                   MCSPI_CHCONF_DPE1_ENABLED |
                                   MCSPI_CHCONF_DPE0_MASK),

Enables only  line 1 as an output. The definitions are in Z:\BoosterPack\SPI_In_test\sysbios_ind_sdk_02.01.02.02\sdk\starterware\include\hw\hw_mcspi.h

David