I am not sure if this is the right stack exchange website to post this on, but if it isn't please move it to the appropriate one.
I am facing a small problem in writing my constraints file for the spartan 3 starter kit.
I have read the documentation provided by Xilinx (the manufacturer) and ive been searching online for a few weeks without any luck.
What i am trying to do is link my Netlist interface to any of the 3 40-pin-headers on the board. (See image below)
Usually its very simple, if say i want to interface a button or a led on the board, i just read the connection name on the board, for example one of the buttons is M13 and write in the UCF file something like this :
NET "BTN0" LOC = "M13";
As you can see on the image the headers are named A1, A2 and B1 on the board, but oddly enough, none of the following worked :
NET "TestOutputLine" LOC = "A1(0)"; -- The (0) is to reference a single line on an array
NET "TestOutputBus" LOC = "A1"; -- The bus is of equal dimension of A1 (which is 40)
The errors i got meant that either the target (specified by LOC) does not exist or that the assignment is invalid.
I hope you have some ideas for me.
Thanks in advance
EDIT :
Here is the output from ISE :
ConstraintSystem:59 - Constraint <NET "TestOutputBus" LOC = "A1";>
[circuit.ucf(12)]: NET "TestOutputBus" not found. Please verify that:
1. The specified design element actually exists in the original design.
But i am pretty sure that TestOutputBus exists, as a matter of fact there is nothing else in my design right now, and the correct top level unit is being used.
EDIT2 :
I updated my UCF file, right now it's like this :
NET "TestOutputBus(0)" LOC = "A1(0)";
NET "TestOutputBus(1)" LOC = "A1(1)";
But i get a different error now in mapping :
MapLib:30 - LOC constraint A1:0 on TestOutputBus<0> is invalid: No such
site on the device. To bypass this error set the environment variable
'XIL_MAP_LOCWARN'.
MapLib:30 - LOC constraint A1:1 on TestOutputBus<1> is invalid: No such
site on the device. To bypass this error set the environment variable
'XIL_MAP_LOCWARN'.
Solution :
In order to get the pins 5 and 6 mapped to TestOutputBus(0) and TestOutputBus(1) respectively what i had to use was this :
NET "TestOutputBus(0)" LOC = "N7"; -- A1 pin 5
NET "TestOutputBus(1)" LOC = "L5"; -- A1 pin 6
Note that pins 0 are not mappable thats why i used pins 5 and 6, here are the tables that show the mappable pins for all headers and their LOCs.
As it turns out, there is an address for each usable pin of each header of the FPGA.
The datasheet (http://forums.xilinx.com/xlnx/attachments/xlnx/Spartan/3411/1/S3BOARD_RM.pdf) was helpful especially pages 49 - 51
I copied this from my earlier comment to your question so it would be an actual answer and not just a comment.
You should have LOC constraints in your UCF file for every port on your top-level module. So if you have a 40-bit-wide bus as an input or output at the top level then you should also have 40 separate LOC constraints in your UCF file to make sure that the logical bus in your top-level schematic actually gets mapped to the correct pins on your FPGA. If you are only using two pins, then you can declare the bus to be 2-bits wide and use 2 LOC constraints. The FPGA will treat all unused pins as inputs and ignore them.
I once got the original ConstraintSystem:59 net xyz not found error when i accidentally selected one of my modules as a top module. The pins declared in UCF could not be found in the port declaration of wrong module.
Also i get this error when i have some pin declared in UCF but ommit it in port declaration of top module.
Related
the #include isnt blue like it is in my lab manual for my class. I dont know if this is the issue or not. I have just installed the software according to the dirrections and restarted 3 times and I havent found any answers online
enter image description here
The format of an Assembly source line for the IAR Assembler is as follows:
[label [:]] [operation] [operands] [; comment ]
where the components are as follows:
label: A definition of a label, which is a symbol that represents an address. If the label starts in the first column - that is, at the far left on the line. The : (colon) is optional.
operation: An assembler instruction or directive. This must not start in the first column - there must be at least one (whitespace) or a → (TAB) character prior it.
operands: An assembler instruction or directive can have from zero up to several operands. The operands are separated by , (commas) or (whitespaces).
comment: Comment, preceded by a ; (semicolon) -or- by a C/C++ comment styles (/* ... */ or //).
I am having some issues getting stock code to compile for my 9 axes motion shield. I have a github repository with all of the motion libraries I have, the example code, and the error messages I am getting.
I am using Arduino 1.7.1 IDE on Windows 7 64-bit.
I have tried using sample code for the sensor instead of for the shield and could not get that to compile either. I have tested example code built into the IDE to ensure that I can compile something and I was even able to interface with my Arduino MEGA 2560 with said code.
I have searched Google and Stack exchange a fair bit and have not managed to come up with any solutions.
The main error I can not figure out is:
"
C:\Users\LJI_eric\Documents\Arduino\sketch_mar20a\sketch_mar20a.ino: In function 'void setup()':
sketch_mar20a:63: error: 'OPERATION_MODE_NDOF' was not declared in this scope
mySensor.setOperationMode(OPERATION_MODE_NDOF);"
OPERATION_MODE_NDOF is a mode that is defined in BNO055.h and is an array of operation modes. I tried several other modes to no avail.
I would appreciate any and all help.
On line 84, 87 and 91 you have made a new line inside a string. You can not do that on the Arduino. If you want to break a string up in more lines you should end the string where you would break it, and start the string again on the new line, like this.
Serial.println("Move the device around and then place it at one position.\n"
"Change the threshold and duration to increase the difficulty level.");
Then you should change OPERATION_MODE_NDOF to BNO055_OPERATION_MODE_NDOF
I tried to use the SoftI2CMaster library [http://playground.arduino.cc/Main/SoftwareI2CLibrary], the library works great in most cases, but it doesn't work on ports H through L, the compiler give me following message:
/SoftI2CMaster.h: In function 'boolean i2c_init()':
/SoftI2CMaster.h:265: error: impossible constraint in 'asm'
Basically the code that caused the problem is some assembly:
__asm__ __volatile__
(
...
: :
[SCLDDR] "I" (SCL_DDR), [SCLPIN] "I" (SCL_PIN),
[SCLIN] "I" (SCL_IN), [SCLOUT] "I" (SCL_OUT));
After some test, trial and error, I am pretty sure the problem is coming from SCL_DDR and those related variables, here's how they defined:
#define SDA_DDR (_SFR_IO_ADDR(SDA_PORT) - 1)
#define SCL_DDR (_SFR_IO_ADDR(SCL_PORT) - 1)
#define SDA_OUT _SFR_IO_ADDR(SDA_PORT)
#define SCL_OUT _SFR_IO_ADDR(SCL_PORT)
#define SDA_IN (_SFR_IO_ADDR(SDA_PORT) - 2)
#define SCL_IN (_SFR_IO_ADDR(SCL_PORT) - 2)
For the SXX_PORT, if I supply anything PORTA-PORTG will be fine, program compiles and execute without issue, but then if I supply PORTH-PORTK the error will come out. Can anyone point out what's the problem? Is the problem from _SFR_IO_ADDR()?
The constraint "I" requires a constant from 0 to 63. If you choose one of the higher ports, then the address (_SFR_IO_ADDR()) will be higher than 63.
You could try changing the modifier to "M", which requires a constant fitting in 8 bits. I don't know if this will work, or why the author chose to use "I".
If it works, you could send the author a bug report.
i got a problem with simple cobol call - returning test program.
I am using micro focus cobol.
here are my 2 codes.
***************** CALLING PROGRAM
IDENTIFICATION DIVISION.
PROGRAM-ID. callreturning.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 VA PIC S9(8) USAGE DISPLAY.
01 VB PIC S9(8) USAGE DISPLAY.
01 VC PIC 9(4) USAGE DISPLAY value 0.
PROCEDURE DIVISION.
MOVE 1 TO VA.
MOVE 2 TO VB.
move 3 to VC.
CALL "add_two" USING VA VB returning VC.
* DISPLAY VA VB VC.
EXIT PROGRAM.
END PROGRAM callreturning.
*********CALLED PROGRAM
IDENTIFICATION DIVISION.
PROGRAM-ID. add_two.
ENVIRONMENT DIVISION.
DATA DIVISION.
LINKAGE SECTION.
01 PARM_A PIC S9(8) USAGE DISPLAY.
01 PARM_B PIC S9(8) USAGE DISPLAY.
01 PARM_C PIC 9(4) USAGE DISPLAY value 0.
PROCEDURE DIVISION USING PARM_A PARM_B returning PARM_C.
move 3 to PARM_C.
* ADD PARM_A TO PARM_B GIVING PARM_C.
goback.
END PROGRAM add_two.
CALLING program simply calls the second program with using returing value.
But when i compile both program and run, error happens.
error code: 114, pc=0, call=1, seg=0
114 Attempt to access item beyond bounds of memory (Signal 11)
Did i make a wrong code? or other problem? please help me :)
I am testing 'RETURNING' phrase
Your program compiles and works just fine if you get rid of the returning statement.
Background
01 levels defined in the linkage section are more like pointers in a C program. For normal parameters they are set by the calling program. But returning parameters will be unassigned.
The error is probably caused by trying to use an unallocated pointer.
Solution
Do not use returning as it is for working with languages like java.
Allocate storage to the return-value before using it.
See:
Microfocus Manual, Look at the returning example
IBM Manual Look at the Returning Phrase Section
Finally, returning is for working with java. Anything "type" defined on returning should be java compatible (i.e. binary-long and not 9(4)). I strongly suggest not using Returning in Cobol unless you are calling other languages.
Old Question, so i try a short Answer:
First, there is nothing wrong with using returning in MF-COBOL.
So, this is native COBOL (NetExpress as IDE, i assume). To correct ist just change the second Program:
Move PARM_C from the linkage to the working-storage section
The Procedure Division doesn't get the returning Phrase in its opening declaration. Move it instead to the goback phrase:
PROCEDURE DIVISION USING PARM_A PARM_B.
*>...
goback returning PARM_C.
I'm new to the MSP430 and I am trying to better understand the clock bring-up process. For my current purpose I'm going to take PMMCOREV out of the equation by using a 4 MHz MCLK which is within the 0-8 MHz range for PMMCOREV = 0.
Will someone knowledgable about these parts please check my logic and assumptions:
When the part boots XT1 is selected as the FLL reference and DCOCLKDIV is selected as the MCLK input. DIVM is 0 so the MCLK source is not divided.
When the system boots the crystal is not yet stable so I'm assuming the UCS moves in to fail-safe mode and uses REFO (internal trimmed 32K) as the FLL reference.
Already I'm a bit confused. If the divided DCO is used for MCLK how are we assured that the FLL is stable? So how is the core functioning at all?
It seems to me that MCLK should be either VLO or REFO until you can bring things up gracefully.
Can someone clarify these details and steer me in the right direction to properly initialize these clocks?
Thanks!
Per your comment, yes.
At startup DCO will be the clock - so you just need to modify the UCSCTL registers and wait for the oscillators to settle and you are good to go.
Here are the steps in general:
Change the vcore level in steps (if necessary - in your case its not)
Enable XT1
Configure the drive strength
Select your clock sources for MCLK, SMCLK, and ACLK and do any source division that you need to do
Allow XT1, XT2 and DCO to stablize by checking for fault flags.
Your external crystal is 4Mhz - Are you wanting to use it as MCLK directly? Or is your angle to use it as a reference to the FLL for DCO, and use DCO for MCLK (to achieve a higher MCLK frequency)? The core volatage that you will need depends on whatever your MCLK frequency is, not your external crystal's frequency. So if you are wanting to use a MCLK rate of higher than 8Mhz you will need to consider stepping up PMMCOREV to 01.
For convenience, here is a reference for UCS registers from SLAU208M.
http://www.ti.com/lit/ug/slau208m/slau208m.pdf#page=172
Based on your OP, I think you should do the following if you want to use XT1 are your MCLK:
//1) Enable XT1 - XT1 will be off by default. You may not need to explicitly
// perform this step. According to pg. 162 in SLAU208M, XT1 will be
// enabled when you select it as the source for one of the clocks. But I
// like being explicit!
UCSCTL6 &= ~XT1OFF //XT1OFF= 0x0001u
//2) Clear the XT1DRIVE bits - it may not be necessary to clear these bits
// explicitly, but XT1's drive strength can be reduced to 0 w/ a 4MHz
// crystal. By default, this will be b11, full scale, which will consume
// more power, but result in a quicker settling time.
UCSCTL6 &= ~XT1DRIVE0; //XT1DRIVE0 = 0x0040u
UCSCTL6 &= ~XT1DRIVE1; //XT1DRIVE1 = 0x0080u
//3) Select XT1 as the clock source for XT1. UCSCTL4 defaults to 0x44 at
// power on - DCOCLKDIV (b100). SELM_XT1CLK = b000.
UCSCTL4 &= SELM__XT1CLK; //SELM__XT1CLK = 0x0000u
//4) Wait for XT1 to stabilize
do
{
//Explicitly clear the XT1 low and high frequency fault flasg, XT2 fault flag,
//and DCO fault flag. 0X0008u, 0x0002, 0x0004, 0x0001 respectively.
UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + XT1HFOFFG + DCOFFG);
//Clear the oscillator fault interrupt flag in the special function interrupt
//flags register.
SFRIFG1 &= ~OFIFG; //0X0002U
} while (SFRIFG1&OFIFG); //Test to see if any oscillator fault flags are asserted.
I am using IAR systems, not sure if you are using CCS if those definitions will be named differently. I went ahead and typed out the hex for each of the operands.
On the msp4305438A you do not have to do anything with bypass.
Does that answer your question?
Also, in your OP you mention wanting to use XT1 as a reference for an FLL. That is accomplished using UCSCTL3. SELFREF is the field you want to set to b000 to use XT1,
Here's the definitions for the MSP4305438A header in IAR:
#define SELREF0 (0x0010u) /* FLL Reference Clock Select Bit : 0 */
#define SELREF1 (0x0020u) /* FLL Reference Clock Select Bit : 1 */
#define SELREF2 (0x0040u) /* FLL Reference Clock Select Bit : 2 */