Negative Feedback

Things to do...

1. Today, 1st order of business is to debug Darryl's negative-pulse-detection configuration code - it wasn't working yesterday when I tested it.  It occurred to me that possibly he used the wrong bit - need to check.
2. In other matters, I need to test the wireless communication - yesterday I verified both halves of this (communication from the FPGA board to a UwTerminal on the PC over the serial port, and communication from the server to the Wi-Fi board over the serial port), and then I plugged the FPGA board into the Wi-Fi board via a null modem adapter (since the level shifters at both ends are configured as DCEs; they both use pin 2 of the DE9 to transmit and pin 3 to receive), and so it is ready to test.
3. It also occurred to me that the Wi-Fi board ought to generate a "WIFI_READY" message to the FEDM after it finishes powering up & connecting to the server and is ready to relay messages.  Need to add that to the autorun script...  And add a command handler to the firmware to recognize that change of state (since there's no point in sending stuff out the serial port before then).
4. After that, I can just continue going through the list of bullet points from Friday, adding new features...

Let's get to work...

(1) Debug NEG_INPUT:

Checking top-level schematic... Darryl used bit 2 from the icdp_ctrl PIO bus to control the input-capture datapath.  This was not a good choice, since bit 2 (on the input side) is already allocated to the HAVE_DATA input.  Although it is perhaps possible to use a given PIO bit for both input and output, for different purposes, it seems to me to be unnecessarily confusing.  And it might conceivably cause problems.
 
Checking the C code (icdp_driver.h)...  He does define NEG_INPUT_MASK as (1<<2), so at least that is consistent with his choice in the schematic.

Changed the NEG_INPUT signal from bit 2 to bit 4.

Let's modify the schematic to check the output of the XOR gates as well, so we can make sure that is working.

OK, the input pulses are getting negated properly, but we're not capturing them for some reason... It could be that during startup the datapath is getting corrupted.

This is a good reason to go ahead and add the RESET control signal to all the input-capture datapath modules.  That way in icdp_init(), we can ensure that the IC datapath is all cleared out and ready before we turn on the pulse generator for testing (with everything properly configured).

Aha, we are having stack overflow problems again.  Fixed that by moving the stack from the 6K extra_RAM (M512 blocks) to the 64K working_memory (M-RAM block).

Now we are having apparent timing issues; recompiling at 400 MHz.  That fixed it.  Revisit performance later.  Seems like fmax changes a lot (up or down!) every time we make any little tweak to the design.

(2) & (3) - Wi-Fi stuff.

Wi-Fi communication with the server.  is working fine.  I set up the Wi-Fi script to send the FEDM a "WIFI_READY" message when it is about to enter its main loop, and likewise the FEDM sends a "FEDM_READY" message when it is about to enter its main loop.  For some reason, the FEDM isn't picking up the WIFI_READY.

First thing tomorrow:  Re-burn the script.