Yesterday David was copying the Quartus SP2 install file to the VirtualBox on the center iMac, to try to fix some compile errors he was getting. When he gets here he can do the install and then try compiling again.
Yesterday Aarmondas was working on stripping the slow-speed stuff from the timing-sync datapath; he can continue that today.
If all goes well, we will hopefully get to the point today of compiling all the high-speed components together by themselves. If that gets over 500 MHz, then assign them to the root logic-lock region and compile again (should give the same speed). Finally, the slow-speed components then need to be reconnected, and a final recompile done with them in place. In theory, the 500 MHz speed for the high-speed components should be retained, with the full functionality of the system in place. Then the whole thing will still need to be tested, to demonstrate proper functionality and that the desired speed has been attained.
Meanwhile, I can continue finishing up the implementation of the automatic server-driven warm-start of the GPS, and test it. If that is insufficient to get the GPS to acquire satellites, then I can also try a cold-start, and also try initializing the date/time properly, and see if that helps. More coding needed for that though.
When I left off yesterday, I was about to implement wifi.WiFi_Module._uartSrvConnected(), etc. in wifi.py. These methods allow us to figure out which connections from the node are currently up & running, so we'll know which of them we can use to send a message to the node. Normally, all of them should be active once the node has started up, but in case one of the connections goes down for some reason, it would be nice to be able to detect this, and gracefully fall back on an alternate connection. However, for now we'll just assume that if the corresponding attribute of the .wifi_module object model is non-null, the connection is still active.
Archived log files. Made those changes. Starting server. Fixing some more minor bugs.
OK, now finally we are not getting Python errors, and we are getting the following transactions on the UART connection:
----------------------------------------------------------------------
At Tue Feb 28 15:07:34 2012 + 203 ms opened node0.uart.trnscr transcript...
Tue Feb 28 15:07:45 2012 + 239 ms: <
Tue Feb 28 15:07:45 2012 + 240 ms: < HOST_STARTING,CTU_GPS,1.9
Tue Feb 28 15:07:45 2012 + 247 ms: < HOST_READY
Tue Feb 28 15:07:45 2012 + 256 ms: > HOST GPS $PDME,1
Tue Feb 28 15:07:45 2012 + 836 ms: < $ACK,GPS $PDME,1*24
Tue Feb 28 15:07:45 2012 + 837 ms: < $ERR,UNK_CMD,GPS*44
And the server console dutifully reports:
ERROR: SensorHost._handleHostMsg(): Sensor host reports a UNK_CMD error with data [GPS].
So, the command is getting sent, but generates an UNK_CMD error response from the embedded host. Guess I didn't yet update the firmware to support the new "GPS" command? Or didn't yet load the new firmware onto the DE3 board? Anyway, let's check. I might also have to turn on firmware debugging - fortunately this can be done via a simple slider switch.
Oops, Eclipse is complaining that I upgraded Quartus to SP2 but didn't upgrade the Nios2 tools yet. Downloading ftp://ftp.altera.com/outgoing/release/91sp2_nios2eds_windows.exe... Installing...
I think I want to get rid of the bad-checksum errors when the GPS module boots - have it no longer complain if the checksum is missing. OK, did that.
System startup sequence is still very finicky about the order in which the boards are powered up. For example, here I powered up the DE3 as the Wi-Fi board was opening its windows:
Console messages:
|------------------------------------------------------------|
| Node 0 log started. |
|VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV|
Node 0 reports its MAC address is 00:1E:3D:33:ED:CF.
Node 0 turned on at Tue Feb 28 17:09:59 2012 + 875 ms.
Starting AUXIO server for node 0 on port 52737...
Starting UART server for node 0 on port 63766...
Node 0 reports that its bridging mode has changed to NONE.
Node 0's bridge mode is now NONE.
Node #0's host (type CTU_GPS, firmware version 1.9) is starting up...
Node #0's host is ready to accept commands.
ERROR: WiFi_Module.sendHost(): I don't know any way to communicate with the sensor host in the present briding mode. Giving up.
Node 0 reports that its bridging mode has changed to TREFOIL.
Node 0's bridge mode is now TREFOIL.
ERROR: SensorHost._parseMsg(): Checksum failed on line [$ERR,BAD_CHK,[Œ$PDMEHEADER1: DeLORME GPS2058_HW_1.0.1]*A7]; ignoring line...
WARNING: GPS_Module.sentMessage(): The GPS module sent a message of a type [PDMEHEADER2: DeLORME GPS2058_FW_2.0.1] which I don't know how to handle. Ignoring...
Heartbeat #1 received from node 0 at Tue Feb 28 17:11:04 2012 + 827 ms.
Heartbeat #2 received from node 0 at Tue Feb 28 17:12:04 2012 + 210 ms.
When I left off yesterday, I was about to implement wifi.WiFi_Module._uartSrvConnected(), etc. in wifi.py. These methods allow us to figure out which connections from the node are currently up & running, so we'll know which of them we can use to send a message to the node. Normally, all of them should be active once the node has started up, but in case one of the connections goes down for some reason, it would be nice to be able to detect this, and gracefully fall back on an alternate connection. However, for now we'll just assume that if the corresponding attribute of the .wifi_module object model is non-null, the connection is still active.
Archived log files. Made those changes. Starting server. Fixing some more minor bugs.
OK, now finally we are not getting Python errors, and we are getting the following transactions on the UART connection:
----------------------------------------------------------------------
At Tue Feb 28 15:07:34 2012 + 203 ms opened node0.uart.trnscr transcript...
Tue Feb 28 15:07:45 2012 + 239 ms: <
Tue Feb 28 15:07:45 2012 + 240 ms: < HOST_STARTING,CTU_GPS,1.9
Tue Feb 28 15:07:45 2012 + 247 ms: < HOST_READY
Tue Feb 28 15:07:45 2012 + 256 ms: > HOST GPS $PDME,1
Tue Feb 28 15:07:45 2012 + 836 ms: < $ACK,GPS $PDME,1*24
Tue Feb 28 15:07:45 2012 + 837 ms: < $ERR,UNK_CMD,GPS*44
ERROR: SensorHost._handleHostMsg(): Sensor host reports a UNK_CMD error with data [GPS].
Oops, Eclipse is complaining that I upgraded Quartus to SP2 but didn't upgrade the Nios2 tools yet. Downloading ftp://ftp.altera.com/outgoing/release/91sp2_nios2eds_windows.exe... Installing...
I think I want to get rid of the bad-checksum errors when the GPS module boots - have it no longer complain if the checksum is missing. OK, did that.
System startup sequence is still very finicky about the order in which the boards are powered up. For example, here I powered up the DE3 as the Wi-Fi board was opening its windows:
Console messages:
|------------------------------------------------------------|
| Node 0 log started. |
|VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV|
Node 0 reports its MAC address is 00:1E:3D:33:ED:CF.
Node 0 turned on at Tue Feb 28 17:09:59 2012 + 875 ms.
Starting AUXIO server for node 0 on port 52737...
Starting UART server for node 0 on port 63766...
Node 0 reports that its bridging mode has changed to NONE.
Node 0's bridge mode is now NONE.
Node #0's host (type CTU_GPS, firmware version 1.9) is starting up...
Node #0's host is ready to accept commands.
ERROR: WiFi_Module.sendHost(): I don't know any way to communicate with the sensor host in the present briding mode. Giving up.
Node 0 reports that its bridging mode has changed to TREFOIL.
Node 0's bridge mode is now TREFOIL.
ERROR: SensorHost._parseMsg(): Checksum failed on line [$ERR,BAD_CHK,[Œ$PDMEHEADER1: DeLORME GPS2058_HW_1.0.1]*A7]; ignoring line...
WARNING: GPS_Module.sentMessage(): The GPS module sent a message of a type [PDMEHEADER2: DeLORME GPS2058_FW_2.0.1] which I don't know how to handle. Ignoring...
Heartbeat #1 received from node 0 at Tue Feb 28 17:11:04 2012 + 827 ms.
Heartbeat #2 received from node 0 at Tue Feb 28 17:12:04 2012 + 210 ms.
UART transcript:
Tue Feb 28 17:05:38 2012 + 774 ms: < HOST_STARTING,CTU_GPS,1.9
Tue Feb 28 17:05:38 2012 + 782 ms: < HOST_READY
Tue Feb 28 17:05:40 2012 + 222 ms: < $ACK,WIFI_READY*60
Tue Feb 28 17:05:46 2012 + 127 ms: < $ERR,BAD_CHK,[Œ$PDMEHEADER1: DeLORME GPS2058_HW_1.0.1]*A7
Tue Feb 28 17:05:46 2012 + 131 ms: < $PDMEHEADER2: DeLORME GPS2058_FW_2.0.1
Tue Feb 28 17:05:46 2012 + 137 ms: < $GPTXT,COSMICi Custom_Config_0.0.3
And we never got the GPS Manager sending the warm-start message.
Let's do a test where we power things up with substantial delays in between. Here we get:
UART transcript:
----------------------------------------------------------------------
At Tue Feb 28 17:18:34 2012 + 439 ms opened node0.uart.trnscr transcript...
Tue Feb 28 17:18:47 2012 + 736 ms: <
Tue Feb 28 17:18:47 2012 + 737 ms: < HOST_STARTING,CTU_GPS,1.9
Tue Feb 28 17:18:47 2012 + 744 ms: < HOST_READY
Tue Feb 28 17:18:47 2012 + 753 ms: > HOST GPS $PDME,1
Tue Feb 28 17:18:48 2012 + 330 ms: < $ACK,GPS $PDME,1*24
Tue Feb 28 17:18:54 2012 + 969 ms: < $ERR,BAD_CHK,[Œ$PDMEHEADER1: DeLORME GPS2058_HW_1.0.1]*A7
Some console output:
Node #0's host (type CTU_GPS, firmware version 1.9) is starting up...
Node #0's host is ready to accept commands.
ERROR: SensorHost._parseMsg(): Checksum failed on line [$ERR,BAD_CHK,[Œ$PDMEHEADER1: DeLORME GPS2058_HW_1.0.1]*A7]; ignoring line...
I don't know why the first line from the GPS always has this garbage character "Œ" at the start. Maybe we should strip it off somehow? Wrote some code for that in the CTU firmware; compiled; still need to burn & test.
No comments:
Post a Comment