If building the projects in MPLAB fails with an "XC-16 toolchain missing" error, close MPLAB, install the C compiler (xc16-vx.xx-full-install-windows64.exe) and try again.
If you did install the C compiler but MPLAB was running, close and reopen MPLAB and try again.
Cyclone IV support (or Cyclone V) must be enabled for Quartus to run the project from Lab 1. If Quartus complains about "device support," uninstall, re-install and make sure these boxes are checked.
Don't put spaces in filenames. Keep path lengths reasonably short. Failure to adhere to these guidelines can cause mysterious bugs later.
Put pic24_code_examples and nsc_quartus in C:\ece3724, not OneDrive or My Documents folder. Even though you can look inside the archives in File Explorer, you need to extract them from the zip file.
Browser/anti-virus may block downloads (particularly with BullyCPP which is an .exe file). If clicking on a link opens a new tab and then immediately closes it, right-click and "Save Link As..." Then go to your downloads window (Ctrl-J in Firefox and Chrome) and keep the file, ignoring the warnings about malicious downloads.
If VirtualBench does not show up automatically when the scope is plugged in, try installing the drivers: VirtualBench USB Scope: ni-virtualbench_xx.x_online_repack.exe
If ModelSim won't run after the Quartus project is compiled, go to Tools > Options > EDA Tool Options. For "Directory Containing Tool Executable", ModelSim (3rd from bottom) and ModelSim-Altera (bottom) should contain C:\intelFPGA_lite\17.1\modelsim_ase\win32aloem
If ModelSim still doesn't run, go to Assignments > Settings > EDA Tool Settings. Be sure that ModelSim-Altera and Verilog HDL are selected as shown below:
If ModelSim still doesn't show up (this is most likely if you had Quartus Prime 23+ on your computer and are now reverting to 17.1 Lite) go to Assigments > Settings > EDA Tool Settings. It should look like this:
Near the bottom, under NativeLink Settings, if it does not say "nsc" in the "Compile test bench" box, click "Test Benches..."
Then click "New..." to create a test bench with the following settings:
Test bench name: nsc
Top level module in test bench: nsc_vlg_tst
Click the ... next to the "File name:" box and select: C:\ece3724\nsc_quartus\simulation\modelsim\nsc.vt
This is the one.
Select Open, then Add. Your Test Benches should now look like this:
OK out of everything, and recompile your design.
If the simulation fails to launch after correctly configuring the path to Modelsim (see text in yellow), there may be a permissions problem.
Double-click on modelsim.exe in C:\intelFPGA_lite\17.1\modelsim_ase\. If Windows asked you if it's OK to run this file, you have a permissions problem.
If this is the problem, exit Quartus, then run it as Administrator. Compile your design as usual and it should now work.
If your project compiles in Quartus, opens ModelSim, but then has an error like this:
Check that nsc.bdf is set as the top level entity in the Quartus project Hierarchy.
Wrong
What you should see
You can change it by going back to Files in the dropdown and right-clicking nsc.bdf, then selecting "Set as Top-Level Entity".
If your simulation looks funny (wrong number, addresses aren't 16-24, jumps from line to line erratically, bunch of Z's, etc):
Check myrom.v first.
Are your addresses (line numbers) 5 bits?
Are your instructions 7 bits?
The first two bits of the instruction is the opcode. 00 = JMP, 01 = JC, 10 = OUT. Check with your comments to make sure you're doing what you want.
Check the second five bits (operand) to make sure the address/numbers are correct.
Check that you start at line 0, jump immediately to line 8, execute your program and then jump back to line 8. The default case should never execute. You need to have specifically added a line to the program to jump to line 8.
Next, check your schematic (nsc.bdf). Did you widen all your buses? Pay particular attention to single control lines e.g. mem[#]. If they're supposed to represent bits from the opcode, do they?
Finally, check your other Verilog files. Besides myrom.v, you should have edited:
mycounter.v
myreg.v
nsc.vt
If the labels on your schematic are enormous and difficult to read:
Screenshot courtesy of Ethan Laird
Try changing the scale of your display. Hit the Windows key, then type in "Scaling". Select "Change the size of text, apps, and other items."
2. In Quartus, Tools > Options > Block/Symbol Editors > Fonts, then click Reset All Fonts. Close and reopen nsc.bdf.
3. Close Quartus entirely. Right-click the Quartus shortcut, and select Properties > Compatibility > Change high DPI settings. Tick "Override high DPI scaling behavior", and set "Scaling performed by" to Application. Launch Quartus from that shortcut.
3a. If it is no better, instead of Application, try the same setting at System (Enhanced).
3b. If it's still not better, try System.
4. In Windows, check Settings > Accessibility > Text size in Windows. It needs to be at 100%.
5. Close Quartus and rename %USERPROFILE%\quartus2.ini to quartus2.ini.bak. Then restart Quartus.
You want to get to a point where you can at least see that the text says mem[6...0] or whatever, so that you can edit it. If your screenshot is still a little jacked up, that's fine - we're never going to use Quartus in lab again. Let a TA know about your struggles so that you are not penalized on your lab report.
A common error is to be viewing/modifying a source code file from one project while actually debugging another project. When you are done working on a project, close it.
I am editing mptst_word but assembling mptst_byte. It's not going well.
If you suddenly receive an "Error 255 compilation error," exit and restart MPLAB. If you continue to receive this error, close MPLAB again, hit Ctrl-Alt-Delete, and select Task Manager. Close any MPLAB tasks or processes, and restart MPLAB.
Do not paste code from Outlook or PDFs directly into MPLAB. It often contains invisible characters that will cause mysterious errors.
1. Finish Debugger Session (Shift-F5).
2. Right click on your project name in the Project window. Select Properties (all the way at the bottom of the context menu in MPLAB X 6.15).
3. Under Categories on the left, select Simulator:
4. In the dropdown under Options for Simulator/ Option categories, select "Uart1 IO Options":
5. Check the "Enable Uart1 IO" box
6. Click Apply and debug the project. Check your output tab. If you get errors and can't debug, you won't be able to see if these steps worked or not.
7. If the above does not work, you can try, in increasing order of difficulty/time/annoyance:
Opening and closing MPLAB
If your UART tab shows up for another case, copy the contents (Ctrl-A, Ctrl-C, Ctrl-V) of your case file and the C check file over top of the contents of the other case's two files. Explain to the TA what you did, and be sure to rename the file before submitting it.
Uninstalling and reinstalling MPLAB X IDE 6.20
Uninstalling and installing MPLAB X IDE 6.15
If you get this popup when trying to debug/run assembly code:
Go to Tools > Packs and open the Tool Packs tab.
2. Scroll down through Tool Packs until you get to Simulator_TP. Click the box for 1.9.946.
How it should look when you're done.
3. Close the project and close MPLAB. Then reopen MPLAB and the project. Your project should run/debug normally. In the Dashboard under Packs, you should see 1.9.946 as the Simulator.
If the issue is that you're trying to program your board and it's not working, see the Bully CPP and PIC Circuit sections further down instead.
If debugging your project throws errors or causes weird behavior (opening files that aren't part of the project, program memory is not what it should be, vague cryptic warning messages) but you haven't done anything to cause this (haven't touched the code and/or it used to run just fine, other projects work):
Make sure you're using MPLAB 6.20.
Check that you're not doing something wrong:
Have only the project and file(s) you need open?
Project is in the place the lab directions specify (C:\ece3724\) and not OneDrive?
Project is not inside a zip file?
Delete all breakpoints and watches and reset them if needed.
Close the file(s), project and MPLAB, then reopen everything and try again. Open the project the "normal" way, not File > Recent Projects, to double check.
Try the Simulator Not Found steps above to install the toolpack even if you're not getting that particular message. Close and reopen everything.
Still getting the bad behavior?
Close everything again.
Go to the project directory.
Delete the build and dist subdirectories.
Example from Lab 5.
Go into nbproject and delete the private folder as well.
Reopen MPLAB.
Production > Clean and Build Main Project
Delete any old breakpoints/watches and reset them as needed. Debug and everything should work.
NOTE FOR TAs: If this happens to multiple students, you need to perform these steps on your own computer to rebuild the projects and replace the zip file on Canvas. Ideally this should be done each semester when testing each lab prior to release.
In the ebook and lecture slides, variable names are prefaced with underscores. In the lab we do not do this for reasons of compatibility with existing code.
You can't move a literal (number) right into data memory (variable). You have to move it into a register and then move it from the register to the variable. If you want to put it into a 16-bit variable (u16_something), you can use register W0-W7. If it's an 8-bit number, it has to go into WREG.
If you have confusion on the usage of WREG and W0, refer to the PIC24 Assembly Primer. In short, if you're using byte-sized quantities and a variable in the same instruction, it's WREG, otherwise it's W0.
Note that the bitwise inclusive or operation, |, is performed as IOR, not OR
A prefix of 0 indicates an octal number. If part of your student ID number that you need to use in a program starts with a 0, omit it or you'll experience odd results or compilation errors. For example, for decimal #0123, just use #123 instead. For hex #0x0123 use #0x123.
Do not use the variable names a or b - they are reserved names for the 40 bit accumulators used by DSP instructions. Using them will give errors.
Some computers seem to read CTRL+V as two distinct keypresses. If pasting strings does not give you an UART overflow, try installing an older version of BullyCPP.
If Bully CPP returns the following error "The application failed to initialize properly (0xc0000135)" in a pop-up window, this may indicate that your .NET runtime is missing or not installed. You need to install at least up to .NET runtime 2.0, go to Microsoft Downloads and search for ".NET framework".
In the Bully CPP window, always select the port from dropped down list. Do not type/edit to change the COM port.
If the 'USB serial ports' with manufacturer name as FTDI is not listed in the device manager under ports, you probably do not have the drivers for the cable. Get the drivers from FTDI by clicking on the "setup executable" link.
FTDI USB to Serial Cable drivers: CDMxxxxx_Setup.zip
To download, scroll down to "VCP Drivers". Find "Windows (Desktop)" and "Available as a setup executable". Download from this link. (Currently here, but it could move).
Download this anywhere, extract the CDMxxxxx_Setup.exe file, and doubleclick to install it.
Check Bully CPP.
Verify that the COM port you've selected is correct.
Verify that the "Program config bits" checkbox is not checked and that the "MCLR before programming" checkbox is checked.
Verify that the lock symbol next to the MCLR button is unlocked.
Check your wiring.
Make sure the round "can" capacitor, which has a large stripe with minus signs next to one pin, is connected to ground.
Make sure the little plus sign on the capacitor placed between pins 19 and 20 is above the wire which connects to pin 20.
Make sure your PIC is fully inserted into the breadboard -- it's easy to not seat it fully.
Make sure you connected a wire between the MCLR pin (pin 1) and the FTDI USB-to-serial cable.
Check power and ground.
Use a DMM to measure the voltage coming from your USB cable; it should be 5 V.
Use a DMM to measure the voltage on your Vcc rails -- it should be 3.3 V.
Use a DMM to measure the voltage on pins 13 and 28 -- it should be 3.3 V.
Use a DMM to measure the voltage on pin 20 -- it should be 1.8 V.
Check your reset.
Use a DMM to measure the voltage on pin 1 -- it should be 3.3 V.
Press the reset pushbutton and hold it. Use a DMM to measure the voltage on pin 1 -- it should be 0 V. Release the reset button; the voltage should return to 3.3 V.
Check your PIC.
Before programming your PIC, the heartbeat LED should flash rapidly as soon as you turn power on. If not, something is wrong with your PIC or your board.
Swap the PIC from your board with your buddy's PIC. (Assuming their board works, they gave you permission, and it's not during the practicum.)
If your board now works, the problem is your PIC. Ask a TA to re-flash it and try again.
If your buddy's board still works, the problem is your wiring. Check it carefully.
If you are getting too high a current for 'sleep' mode (greater than a milliamp) then make sure that your heartbeat LED is out of the circuit and is not drawing current. For all current measurements, the heatbeat LED should be removed from the board.