EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: helge on November 04, 2015, 05:57:15 pm
-
Hi there Lattice MachXO3 developers,
I've got a couple of XO3-1300E boards here for a project that I ported from the MachXO3L-6900C breakout board.
The design implements a SPI slave with SN used as chip select... and there's where the problem is: I need a way to deactivate the SPI configuration logic, free the SN sysConfig pin and make it available to the user mode Slave SPI als SCSN.
I may have missed the crucial point and here is why:
in the MachXO3 Programming and Configuration Usage Guide they say that in user mode, the SN pin is used for SSPI. The EFB is hardened SPI afterall and SCLK, SPISO, SPISI also have dedicated I/Os for improved performance... so SN could also have a prefered pad? Not really. It seems SN is the only one which can be connected via general routing routines and in turn cannot be mapped to a dedicated sysConfig pin of another slave SPI connected to the same pin.
The problem arises when my preferences collide with sysCONFIG or other configuration options:
(http://abload.de/img/xo3_configuration_spi7akca.png)
MachXO2 and MachXO3 devices offer multiple ports for configuration and programming, among these are JTAG (my prefered interface) and slave SPI. It appears that at least when the slave SPI configuration port is activated outside user mode the SN pin is reserved for the configuration interface (think SPI multiplexed with two individual chip selects). So we gather SN is a sysConfig dediacted pin and....
You must prevent external logic from interfering with device programming. Make sure that recovered sysCONFIG
pins are not asserted when the MachXO3L/LF is in Feature Row HW Default Mode state. One example is driving
PROGRAMN with an active low signal after the MachXO3L/LF is in Feature Row HW Default Mode state. Failure
to reprogram the Feature Row with PROGRAMN disabled prevents the FPGA from configuring and entering user
mode.
Ok so slave SPI configuration is activated once the slave SPI is used (or even by default with the EFB being inactive in user mode) and thus SN cannot be used as CSN for user mode slave SPI?
Can I then deactivate the slave SPI configuration option and still use slave SPI in user mode with the SN pin as general purpose I/O (which then incidentally would be used to route CSN) ?
Right now I just get
ERROR - The state of the assigned pin [E1] conflicts with the config mode and cannot be assigned to the port (SPI_CSN).
indicating that the intended mapping collides with the exclusive character of SN for slave SPI configuration purposes (note there is a separate box for "configuration master/slave" attached to the same interface).
In principle all interfaces except JTAG could be disabled:
The MUX_CONFIGURATION_PORTS is used in the event that all configuration ports are disabled. Disabling all of
the available configuration ports turns the MachXO3L/LF into a “write one time” device.
MUX_CONFIGURATION_PORTS confirms the removal of all configuration ports. The control is only active when
all of the other configuration ports are set to the DISABLE state. MUX_CONFIGURATION_PORTS set to the
ENABLE state enables the JTAGENB input pin, permitting the JTAG port pins to be multiplexed. Setting
MUX_CONFIGURATION_PORTS to the DISABLE state causes the Diamond build tools to honor the removal of all
other configuration ports, allowing the MachXO3L/LF to become a “write one time” device.
That section confuses me. I've tried the option without success.
So the warning
61061045 WARNING - The SN pin is not available for use as a general purpose I/O pin when the SLAVE_SPI_PORT attribute is enabled. The SN pin should be tied high with an external pull-up if you are not using the Slave SPI port for configuration.
really means SN cannot be used as user mode chip select when the EFB Slave SPI is in use? In a less stupid moment I routed the JTAGENB input to a test pad. Is there a way I can deactivate all configuration ports and re-activate JTAG on demand via JTAGENB, thereby making SN general purpose and available for user mode Slave SPI? Otherwise I'm looking at a new batch of PCBs :/
ps. feature row settings are applied to the jedec file (way too late for it to cover the error arising in the first step (synthesis)). It is well hidden: synthesize your project, then with the .xcf programmer brought up go to Design>Utilities>Programming File Utility, in that editor load the .jed file, go to tools > feature row editor. Even there it seems that the only options are
- no Slave SPI
- Slave SPI in config mode, deactivated in user mode
- Slave SPI in config mode and preserved in user mode
No fourth option? But then what's the point of a MachXO3 if you can only have deactivated programming interfaces when you remove I2C and SPI along with them? I don't get it |O
-
Update: I could not find a solution and Lattice Semiconductor rejected my ticket (support not available for my account, what? :-- )
Perhaps I'll have to revert to cutting traces and running wires, right? Before anyone wastes his/her time on this topic, here is my reasoning:
- I need Slave SPI in user mode
- using the EFB generic implicitly sets SLAVE_SPI_PORT=ENABLE
- which means that the SPI interface is enabled during configuration and persists in user mode
- there is no "user-mode-only" Slave SPI option
- SN repurposing and hardened Slave SPI are mutually exclusive
- so there is no way around the issue other than using a soft, larger and slower Slave SPI core with a Wishbone interface that behaves much like the real deal or rewrite part of the control logic to cater for the differences
so.. wires it is, I guess.
-
Not a nice way to treat people that use your products and put effort into resolving issues, dear Lattice Semiconductor people. I am not amused!
Here's the original text:
Dear ladies and gentlemen,
as a result of porting a design to the small XO3-1300 I misunderstood the purpose and capabilities of the SN sysConfig pin in a way that I thought it could be mapped to behave as a user mode chip select. As it turns out this would require it to be GPIO and subsequently be assigned to the EFB Slave SPI as CSN.
Please add a clear note that SN cannot be used as user mode slave SPI chip select (just calling it a chip select pin is misleading sometimes) because SN repurposing and user mode slave SPI are mutually exclusive due to implicit SLAVE_SPI_PORT=ENABLE.
Perhaps a "disable configuration via slave SPI" option would do the trick in future device implementations.
Best Regards,
Helge
ps. please don't delete this ticket without reading it. You can find my detailed discussion here:
https://www.eevblog.com/forum/microcontrollers/machxo3-sn-pin-i-think-i%27m-screwed/msg798238/#msg798238 (https://www.eevblog.com/forum/microcontrollers/machxo3-sn-pin-i-think-i%27m-screwed/msg798238/#msg798238)
-
Short follow-up: For a brief moment I've considered using Configuration Slave SPI for the initial programming of the device. However..
The SSPI port is active when the MachXO3L/LF is in Feature Row HW Default Mode state. Diamond’s default preference
for the SLAVE_SPI_PORT is to ENABLE the port.
Use the Spreadsheet View to DISABLE the
SLAVE_SPI_PORT preference in your design to keep the SSPI port to be used as general purpose I/O in user
mode. Lattice recommends you keep a secondary programming port active in the event the SSPI port is accidentally
disabled.
Programming the MachXO3L/LF using the SSPI port is complex. Lattice provides ‘C’ source code called SSPIEMbedded
to insulate you from the complexity of programming the MachXO3L/LF. It is recommended that SSPIEmbedded
be used when you want to reprogram the MachXO3L/LF NVCM (MachXO3L)/Flash(MachXO3LF) or
SRAM.
Accessing the status registers is less complex and does not require the use of the SSPIEmbedded code.
So JTAG it is.
http://www.latticesemi.com/en/Support/AnswerDatabase/2/5/1/2510.aspx (http://www.latticesemi.com/en/Support/AnswerDatabase/2/5/1/2510.aspx)
On the up side: the SSPIEmbedded source code directly comes with the Lattice Diamond software. Maybe one day I'll implement something along those lines that works with FT2232H devices.
-
Since this thread is about programming and using MachXO3 devices I'll try to answer a quick "getting started" question in here:
- how do I implement a MachXO3L device, what pins are used and how is the programming interface implemented?
- MachXO3 supports programming and configuration loading over SPI. What are the catches and why is it better to just stick with JTAG?
- How to recover sysCONFIG pins in user mode
Please do not send me private messages and expect me to spend time on your personal one-off questions for your personal profit. If it's relevant, that warrants it to be discussed publicly. It may one day help others out too (and don't forget I might just be wrong :P). If it's not, well, try google instead.
Alright, here goes.
A complete overview over the MachXO3 programming features is given here.
http://www.latticesemi.com/~/media/LatticeSemi/Documents/ApplicationNotes/MO/MachXO3ProgrammingandConfigurationUsageGuide.pdf?document_id=50123 (http://www.latticesemi.com/~/media/LatticeSemi/Documents/ApplicationNotes/MO/MachXO3ProgrammingandConfigurationUsageGuide.pdf?document_id=50123)
In general, the Lattice Diamond programmer utility supports a multitude of (active) cables, among these are FT2232 JTAG since no fancy debugger is needed. MachXO3LF also supports an external SPI flash which can be programmed transparently all the time except when the MachXO3LF SPI master accesses the flash for startup.
The source of the configuration file as well as the interfaces through which access is granted are configured in a feature row non-volatile memory.
sysCONFIG I/Os like the JTAG pins may have different functions in configuration mode vs. user mode, JTAG pins can be recovered in user mode when pull-down is added to the JTAGEN pin and JTAG is disabled as a default. I did this with the WLCSP package and freed up the necessary I/Os but as mentioned the connected peripherals must not contend the JTAG lines.
The JTAG port, when set in the DISABLE state, enables the JTAGENB input. JTAGENB permits the JTAG pins to
be multiplexed. Asserting JTAGENB high causes the JTAG pins to take on the IEEE 1149.1 personality. De-asserting
JTAGENB (i.e. driven low) causes the JTAG port pins to become general purpose I/O.
The device also supports programming via the interfaces offered through the EFB (Master SPI, Slave SPI, I2C) but these are considered advanced in-circuit reprogramming features. Don't go there as a beginner. Additionally the Configuration Slave SPI has its own slave select which if I remember correctly is then not available as a user mode pin. SPI lines are special I/Os of which only the user mode slave select can be connected to via general routing. The "high speed" MISO, MOSI and SCLK signals must be connected to dedicated pins.
In the Slave SPI mode, the MCLK/CCLK pin becomes CCLK (i.e. Configuration clock). Input data is read into the
MachXO3L/LF device on the SI pin at the rising edge of CCLK. Output data is valid on the SO pin at the falling
edge of CCLK. The SN acts as the chip select signal. When SN is high, the SSPI interface is deselected and the
SO/SPISO pin is tri-stated. Commands can be written into and data read from the MachXO3L/LF when SN is
asserted.
http://www.latticesemi.com/~/media/LatticeSemi/Documents/ApplicationNotes/UZ/UsingHardenedControlFunctionsinMachXO3DevicesReferenceGuide.pdf?document_id=50512 (http://www.latticesemi.com/~/media/LatticeSemi/Documents/ApplicationNotes/UZ/UsingHardenedControlFunctionsinMachXO3DevicesReferenceGuide.pdf?document_id=50512)
So in a nut shell, use JTAG via an FTDI chip with MPSSE, mostly FT2232H - and if you really need the I/Os, disable JTAG per default and use a pull-down + jumper to control JTAGEN.
Leave INITN and PROGRAMN unconnected to route to test pads. Also route JTAGEN to a test pad or header.
Regarding the proper implementation, check out the MacHXO3-6900C starter board, it comes with complete and comprehensive schematics,
http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/MachXO3LStarterKit.aspx (http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/MachXO3LStarterKit.aspx)
-
These notes are for the XO2, but I'm pretty sure the XO3 is very very similar, particularly for the Flash parts.
Some of the Lattice software stuff is more complex than it need be. For starters, the JED file is more or less exactly what is needed to pump into the SPI/I2C/JTAG port.
Look at the software support for Bugblat's Raspberry Pi/FPGA board (http://www.bugblat.com/products/pif/ (http://www.bugblat.com/products/pif/)). The Python source code to load a JED file into an XO2 via SPI is in the software repo. Around 100 lines of Python and no other software required.
The feature bits can be set by SPI using the "Program FEABITs" command. In Lattice TN1246, search for 0xF8, it's on page 69 of my copy.
--
Tim
-
I don't want to steal this thread and in any case, it has been closed. I'm in a very similar situation: I want to use MachXO3 in SPI MASTER and I have only routed the SN pin to the SPI slave chip CS select. If I chose two master chip selects in the IP Express for the MachXO3 master (and slave) mode, am I being allowed to use the SN pin as CS1 or am I sc... with some re-wiring / new PCB iteration?
-
Please don't necropost. Start a new thread and link to the discussion in question.