Earlier I emailed Samad some suggestions for improvements in his design for the power distribution board. He showed me his layout yesterday; it is looking pretty good. I suggested he add some bypass capacitors for low-pass filtering, and make sure that all same-voltage nodes are tied together.
For myself, I have two goals for today:
- [ ] Get set up to run the demo for Michael D. Do a practice run first.
- [ ] Continue working on the server-side code to remotely initialize the GPS. Since ongoing development work might interfere with the functionality of the demo, M.D. should probably make a snapshot of the server code before I start making changes. He can then run the server on his laptop.
- I am plugging the GPS kit and the Wi-Fi board into COSMICi (Dell PC) via USB to supply power. I will leave their power switches off until we are ready to run the demo. This is because powering them through the DE3 board currently doesn't work reliably. Once Samad finishes his new power distribution board, we can power all components from that.
- Archiving current log files to new folder "Dropbox/COSMICi_devel/Server Code/data/logs 2012-02-21."
- Starting server. Minimizing the Python process's Windows console window.
- Going to quickly power-on the DE3 board, GPS module, and Wi-Fi board at close to the same time (to simulate them all being powered on at the same time through the power distribution board). Something went wrong; we never got the critical HOST_STARTING message that identifies this as the CTU. I think I powered up the boards in the wrong order. Should perhaps power on the Wi-Fi board first, then the DE3, then the GPS. Let's try again... Restarting server...
- Now I am getting a BadChecksum exception on the $PDMEHEADER1 line which the GPS generates on powerup... It starts with a garbage character (Œ) so that is probably why. The exception is then causing the whole UART bridge connection request handler instance to crash. Need to catch this exception somewhere
Tue Feb 21 14:53:49 2012 + 769 ms: < HOST_STARTING,CTU_GPS,1.9
Tue Feb 21 14:53:49 2012 + 774 ms: < HOST_READY
Tue Feb 21 14:53:49 2012 + 779 ms: < $ERR,BAD_CHK,[Œ$PDMEHEADER1: DeLORME GPS2058_HW_1.0.1]*A7
The Python stack trace is:
Traceback (most recent call last):
File "C:\Users\Mike\Documents\My Dropbox\COSMICi_devel\Server Code\src\communicator.py", line 1795, in handle
msg = Message(data, self.conn, thetime)
File "C:\Users\Mike\Documents\My Dropbox\COSMICi_devel\Server Code\src\communicator.py", line 397, in __init__
if (conn != None): conn._announce(self)
File "C:\Users\Mike\Documents\My Dropbox\COSMICi_devel\Server Code\src\communicator.py", line 823, in _announce
h.handle(msg) # Tell it to handle the message.
File "C:\Users\Mike\Documents\My Dropbox\COSMICi_devel\Server Code\src\model.py", line 1238, in handle
this.wifi_module.node.sensor_host.sentMessage(msg)
File "C:\Users\Mike\Documents\My Dropbox\COSMICi_devel\Server Code\src\model.py", line 2268, in sentMessage
this._handleMsg(msg) # Dispatch to message handler.
File "C:\Users\Mike\Documents\My Dropbox\COSMICi_devel\Server Code\src\model.py", line 2574, in _handleMsg
msgWords = this._parseMsg(msg) # Parse the message into fields.
File "C:\Users\Mike\Documents\My Dropbox\COSMICi_devel\Server Code\src\model.py", line 2471, in _parseMsg
msgStr = nmea.stripNMEA(msgStr) # Warning: This may throw an nmea.BadChecksum exception.
File "C:\Users\Mike\Documents\My Dropbox\COSMICi_devel\Server Code\src\nmea.py", line 100, in stripNMEA
raise BadChecksum # Raise a "bad checksum" exception.
nmea.BadChecksum
OK, that's fixed; now we get:
HOST_STARTING,CTU_GPS,1.9
HOST_READY
$ERR,BAD_CHK,[Œ$PDMEHEADER1: DeLORME GPS2058_HW_1.0.1]*A7
$ERR,BAD_CHK,[$PDMEHEADER2: DeLORME GPS2058_FW_2.0.1]*25
$ERR,BAD_CHK,[$GPTXT,COSMICi Custom_Config_0.0.3]*27
$ACK,WIFI_READY*60
$GPRMC,212148.005,V,3025.676,N,08417.112,W,0.0,0.0,161211,4.1,W*7C
$GPGGA,212148.005,3025.67587,N,08417.11218,W,0,00,99.0,051.73,M,-29.7,M,,*69
$PDMETRAIM,2,0,0.000000000,0,0,0,0,0,0,0,0,0,0,0,0,0*43
$PDMEPOSHOLD,0,0000.000,N,00000.000,E,000.00*4A
...
But we also get the following errors:
ERROR: SensorHost._parseMsg(): Checksum failed on line [$ERR,BAD_CHK,[Œ$PDMEHEADER1: DeLORME GPS2058_HW_1.0.1]*A7]; ignoring line...
ERROR: SensorHost._handleHostMsg(): Unknown host message type [$ERR]. Ignoring...
ERROR: SensorHost._handleHostMsg(): Unknown host message type [ERR]. Ignoring...
ERROR: SensorHost._handleHostMsg(): Unknown host message type [ERR]. Ignoring...
Damn, I just realized that everyone has been using a screwed-up version of the overall Quartus FEDM_code project with "AUTO" device selected instead of the actual device part number. This might have got screwed up on Dropbox after someone migrated to SP2, since it is screwed up in my machine now too (now that I upgraded and rewrote the database). I reset the device selection to the correct one (EP2S30F484C3N) & re-imported the pin assignments from my backup copy of the project (pre-SP2-migration) of Feb. 15th. Now I am recompiling the design to make sure everything still fits. Then I am going to re-upload the project to Dropbox. Everyone needs to make sure they are doing their LogicLock experiments with the actual device selected! AUTO results are not necessarily applicable to our real chip! (Although they may be close, since we have the fastest speed grade.) But fitting-related results definitely are not applicable to the actual chip, since the Stratix II that we have isn't the largest one.
Also: You can't use Web Edition because it does not have support for the specific Stratix II part numbers.
This time we got:
HOST_STARTING,CTU_GPS,1.9
HOST_READY
$ERR,BAD_CHK,[Œ$PDMEHEADER1: DeLORME GPS2058_HW_1.0.1]*A7
$ERR,BAD_CHK,[$PDMEHEADER2: DeLORME GPS2058_FW_2.0.1]*25
$ERR,BAD_CHK,[$GPTXT,COSMICi Custom_Confi]*2C
$ACK,WIFI_STARTING,v0.19*67
$ACK,WIFI_READY*60
$GPRMC,212153.010,V,3025.676,N,08417.112,W,0.0,0.0,161211,4.1,W*72
$GPGGA,212153.010,3025.67587,N,08417.11218,W,0,00,99.0,051.73,M,-29.7,M,,*67
$PDMETRAIM,2,0,0.000000000,0,0,0,0,0,0,0,0,0,0,0,0,0*43
$PDMEPOSHOLD,0,0000.000,N,00000.000,E,000.00*4A
...
Not sure why the $GPTXT message got cut off. Oh well...
OK, got both boards working together, & went through the startup sequence with Michael Dean & Darryl. MD took notes. Basically, in summary, the sequence is:
1. Plug in detectors.
2. Start server app.
3. Power up CTU boards: (a) Wi-Fi, (b) DE3, (c) GPS.
4. Power up FEDM (make sure fan is present).
5. Type "HOST START" in the CTU's UART bridge window.
No comments:
Post a Comment