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.
I am scoping out an application on OMAP 3530 SoC where linux code interacts with the user and DSP code acts as a multi-channel waveform generator. I will be using DSP-Link for the two sides to communicate. My questions are:
Thanks in advance for any insights.
In reply to Brad Griffis:
So, on the clocks, the sysclk = 26Mhz. This is clearly not inside the band specified in this register setting.
Is there somewhere this gets divided to meet this range? I'm not sure I've seen this anywhere?
Ultimately though, what effect are any of these clks going to have on the gpio toggle speed. From the sounds of it, little or none - I'm guessing.
With some cuts and jumps on the fpga board I should be able to make this happen - move the spi pins to the jtag pins on the fpga.
Some advice on setting up the SPI would be nice. I know I'm on my own on the jtag to fpga protocol. But Xilinix goes through this fairly well - so I should be able to handle that.
I will have to do some research on the TMS signal and its usage in the configuration process.
I'll post back when I have an understanding of the details - it will most likely be tomorrow or Monday before I can get to and through it.
Thanks again for the insight.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to MPope:
I recommend researching TMS before you hack up your board or go too far down the path of programming SPI. Otherwise you may do a lot of work for nothing!
Thanks for the ref on the clk stuff. I'll have a look and see if it helps make sense of things.
It's not looking to good for the spi use unless it can handle single bit operations.
I found this nice description, while I was eating lunch, on the jtag sequence.
There are a bunch of different length transfers as well as some that require tms to transition at the end.
Table 10-4: Single Device Configuration Sequence
TAP Controller Step and Description
Set and Hold # of Clocks TDI TMS TCK
1. On power-up, place a logic 1 on the TMS, and clock
the TCK five times. This ensures starting in the TLR
(Test-Logic-Reset) state. X 1 5
2. Move into the RTI state. X 0 1
3. Move into the SELECT-IR state. X 1 2
4. Enter the SHIFT-IR state. X 0 2
5. Start loading the CFG_IN instruction, LSB first: 000101 0 5
6. Load the MSB of CFG_IN instruction when exiting
SHIFT-IR, as defined in the IEEE standard. 0 1 1
7. Enter the SELECT-DR state. X 1 2
8. Enter the SHIFT-DR state. X 0 2
9. Shift in the Spartan-6 FPGA bitstream. Bitn (MSB) is
the first bit in the bitstream(1). bit1 ... bitn 0 (bits in bitstream)-1
10. Shift in the last bit of the bitstream. Bit0 (LSB) shifts
on the transition to EXIT1-DR. bit0 1 1
11. Enter UPDATE-DR state. X 1 1
12. Move into RTI state. X 1 1
13. Enter the SELECT-IR state. X 1 2
14. Move to the SHIFT-IR state X 0 2
15. Start loading the JSTART instruction. The JSTART
instruction initializes the startup sequence. 001100 0 5
16. Load the last bit of the JSTART instruction. 0 1 1
17. Move to the UPDATE-IR state. X 1 1
18. Move to the RTI state and clock the startup
sequence by applying a minimum of 16 clock cycles
to the TCK. X 0 16
19. Move to the TLR state. The device is now functional. X 1 3
Sorry some of the cols don't stay aligned when posted - hopefully you can still make sense of it.
So is Step 9 where you send in the whole file (or the bulk of it)? If so, that will be the most time consuming part of the operation (i.e. most data being sent) and it appears that TMS=0 for that entire part of the sequence. So what you could do is bit bang steps 1-8 and then use the super-duper SPI mode for step 9 and then bit bang the rest. What's the maximum TCK speed the FPGA can support? Basically I envision that your GPIO will be kind of slow for steps 1-8 but then you'll be able to blast in the data in step 9.
Yes, step 9 is the bulk of the transfer.
Can the spi pins be manually done/toggled while in spi mode?
Or, will the pins mode have to be changed to gpio to do the bit twiddle?
Is it possible to change the mode and not affect the pins?
I think 99+% fast and <1% slow is just fine.
Max jtck is specified at 25Mhz.
You would change the pin muxing at run time to switch between GPIO mode and SPI mode. Sounds like it should create a HUGE optimization!
I thought that might be the case.
I noticed that the word length in the spi cfg reg has reserved areas for 1,2,3 bit xfer lengths.
Any chance of those working? Especially the 1 bit? That would then make this a piece of cake.
But since that would be the case, I'm sure there is no chance of that working.
Any idea of what would happen if any of those three modes are selected?
Using a 1-bit mode would not speed anything up because then you would need to poll after every single bit to see if the word/bit had completed. It would actually become slower!
I don't understand why you say there is no chance of it working. Just use slow GPIO for everything but step 9. For step 6 you're just blasting in a huge bitstream right? If that's the case then I would anticipate using the largest word size, 32-bit.
No it probably wouldn't speed it up - even if it were slower, that would probably be better then going from gpio to spi and back to gpio and hoping there were no glitches on the i/o pins that would cause some problem.
The part I was referring to as no chance of working was the 1,2,or 3 WL bit transfer modes. I think either way (spi only or gpio/spi/gpio) has possibility and should be a vast improvement. I would probably prefer the spi only mode just because the flow would be easier for me to program and it seems like it would have the best chance of working, in my opinion. I'm not a sw guru by the stretch of anyone's imagination.
So if the 1-3 bit modes work, then each step just has its length set and go - could be a simple function for all of the xfers but the large 1.3Mb xfer. Step 9 uses 32bits to the last 32bit word and then would be split into 1-3 bytes and a 1 bit xfer.
I think that would work well if it can be done with the 1,2 & 3 bit xfers.
There are 7 1-bit xfers, 6 2-bit xfers and 1 3-bit xfer - every thing else is more than 4-bits, 3 5-bits, 1 16-bit.
So, I guess it's just up to if the 1 to 3-bit xfers work or not to determine the path to follow. Any thoughts on the 1,2, or 3 WL transfers?
MPopeSo, I guess it's just up to if the 1 to 3-bit xfers work or not to determine the path to follow. Any thoughts on the 1,2, or 3 WL transfers?
I'd just use GPIO. You just need to write to the PADCONF register to switch between GPIO mode and SPI mode. No big deal.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.