Review Materials

Home
Members
Schedule
Project Elements
Verification
Reference
Contact Information
What's New

This page provides a centralized collection of links for you our reviewer.  From here you should be able to get to any supporting material you need to accomplish this review.  We really appreciate your efforts in reviewing our work. This project will be a greater success due to your help.  Thank you!

Errata since v1.02

I'm continuing to review and test the latest version of code. While doing so, I'm finding small things that need to be corrected.  I'm noting these here so you, our reviewer, can be aware of what I've found.

Latest news (cause determination, fixing in progress - issues found or still existing in latest f/w)
  1. It appears that unused RAM is being modified during startup and during a WD reset. I'm still looking into this. (Sadly, it looks like an indication of something not good.  This is now being carried as current TODO needing to be fixed before flight.  As far as I can tell this is only affecting pipe-mode operation!)
  2. (Not for flight, but...) Fixes for Jump2ISP dysfunction are still pending, if can be done...
  3. (PipeMode) one or more (still looking into this) of the pipe-mode counters are not being reset. This affects state diagnosis only, not functionality.
Update: 25 October 2006 (fixes in v3.04)
  1. Fixed: Read from CAN device occasionally found packets of 0x0A's.  This turned out to be an initialization issue which is fixed in this version.  We found this problem during code simulation (inspection of behavior of each instruction as it is being simulated.)
  2. Fixed: Stack was being initialized one byte off from planned location. This is now fixed. (Likely was not causing any runtime issues. But found during simulation and now fixed.)
  3. Verification in progress: So, Not yet flight-candidate status as new "full performance" testing has proven that there are problems affecting full speed operation. This has to be fixed before we again achieve flight-candidate status.
Update: 02 May 2006 (fixes in v3.02)
  1. Fixed: (flight, pipe-mode only) Handling of PIPE-READ messages was not a fast as desired. The PIPE-READ processing has been rewritten from a two-stage receiver (RAM to CAN Device to transmit) to now utilize twin buffering and writing directly to the ATMEL CAN controller (no longer staging in RAM). The Widget can now be transmitting one PIPE-READ over CAN while receiving the 2nd PIPE-READ into the other transmit buffer from the attached Module.  This change yielded a 20% performance improvement. (now 30,800 Bytes/Second)
  2. Correct a couple mis-routed pipe-state transitions (affecting only error recovery).
  3. Reduced time spent in Transmit Complete interrupt.
  4. Not yet flight-candidate status as new "full performance" testing has proven that there are problems affecting full speed operation. This has to be fixed before we again achieve flight-candidate status.
Update: 27 March 2006 (fixes in v3.00)
  1. Fixed: (flight, pipe-mode only) Handling of PIPE-WRITE messages was dropping CAN Messages without any indication of error. The PIPE-WRITE processing has been rewritten from a two-stage receiver to now utilize the multi-buffer receive capability of the ATMEL CAN controller. The Widget can now stage up to 7 CAN PIPE-WRITE Messages and then handshake them to the attached Module.
  2. We've removed the flight-candidate status as new "full performance" testing has proven that there are problems affecting full speed operation. This has to be fixed before we again achieve flight-candidate status.
Update: 04 December 2005 (fixes in v2.14)
  1. Fixed: (flight, pipe-mode only) Adjusted priority so that when module was sending bytes to IHU this would be interrupted quickly when the IHU wanted to send to the module.  Prior to this fix the traffic would have to slow allowing the OUT message to be handled when there was a lull in IN traffic.  As of this adjustment an OUT message will interrupt the IN traffic allowing, for instance, an "abort" command to be sent vie the pipe and it will get to the module despite it being in the midst of sending a long stream of data.
  2. This is flight-candidate #08
Update: 18 November 2005 (fixes in v2.12)
  1. Fixed: (flight, pipe-mode only) Adjusted priority so that if an OUT byte and an IN byte needed service at the same time the OUT side would get serviced first.  This ensures that commands can be sent to the module despite it being in the midst of sending data.
  2. Fixed (flight, pipe-mode only) in the event that either the IN or OUT side of the pipe stalled and timed-out the other side was then ignored while recovery took place.  This is no longer the case.  While recovery takes place the other side is now able to function at full speed. This is now fixed.
  3. Fixed: (flight, pipe-mode only) fixed cases where internal semaphores were not set correctly after some of the recovery events. This caused the handshake to not resume correctly after these recovery events. This is now fixed.
  4. This is flight-candidate #07
Update: 22 August 2005 (fixes in v2.10)
  1. Fixed: (flight, pipe-mode only) In the event that a 3rd pipe-write packet arrived at the Widget while the first was still being handshaked to the Module electronics, the resulting interrupt would not be acknowledged causing a flurry of interrupts overwhelming the processor and eventually causing (we suspect) the loss of context confusing the pipe-state machine.  This would result in a handshake lockup (both OUTREQ and OUTACK asserted) and would ignore further message handling such as pipe-abort delivered in configure message or even power down.  The only means to clear this was to allow the hardware watchdog to reset everything.  This has been corrected so that interrupts are correctly handled or are disabled.
  2. Fixed (flight, pipe-mode only) in the event of a pipe-output timer expiration a 2nd packet which was awaiting handshake would be lost.  This is fixed.
  3. Fixed: (flight, pipe-mode only) in the extremely rare event that both the pipe-in and pipe-out timers expired together one of the two interrupts would be lost.  The PCA ISR has been adjusted to process the 2nd interrupt if this should occur.  Both interrupts are handled correctly now.
  4. This is flight-candidate #06
Update: 06 August 2005 (fixes in v2.08)
  1. Fixed: (flight, pipe-mode only) In the event of a pipe-output-timer expiration (transfer of 8-bytes took too long) the OUTREQ line was not de-asserted.  This prevented the module electronics from ever recovering until the Hardware Watchdog was allowed to expire and hard reset the device.  OUTREQ is now correctly de-asserted.
  2. This is flight-candidate #05
Update: 23 July 2005 (fixes in v2.06)
  1. Fixed: (flight, pipe-mode only) by transmitting PIPE-WRITEs faster than could be handshaked out to the Module electronics the internal message store of the Widget was being overrun.
  2. After deeply reviewing the code and running tests we have not been able to find any hint of overrun happening on the Module->Widget->IHU path. This is no longer a concern.'
  3. Fixed: there was a remote possibility that power could be removed during initial handshake synchronization of the Widget with the Module electronics. If this should happen it is now correctly handled.
  4. This is flight-candidate #04
Update: 21 July 2005 (fixes in v2.04)
  1. Corrected behavior of Watchdog restart code which is supposed to restore output power and OUTx bit values.  This is now working for all three modes.  This is 1st time it is really working for pipe-mode.
  2. Fix transmit interrupt block (flawed move into ISR).
  3. This is flight-candidate #03
Update: 05 July 2005 (fixes in v2.02)
  1. Fixed false pipe-timer expirations during configure-message processing.
  2. Moved TX-complete interrupt handling to CAN ISR for better pipe performance.
  3. This is flight-candidate #02
Update: 26 June 2005 (fixes in v2.00)
  1. Fixed the logging of watchdog events which was overwriting the log data structure control fields. Log also now wraps correctly.
  2. Adjusted how memory regions checks are being done and how they are reported.
  3. All three operating modes are considered working as of this release.
  4. Jump2isp is removed from this version as it is flight-candidate #01
Update: 18 June 2005 (fixes in v1.14)
  1. Byte-pipe in-pipe-timer expiration caused single-byte messages to be sent every 2-ms effectively low-velocity-flooding the CAN bus. This was due to missing I/F resync. code in 5 locations within the pipe-state machine. Now when a timeout occurs the Widget will wait for handshake requests to be withdrawn before considering it a new request.  There existed in the code an un-demonstrated failure on the output side as well.  Both of these are fixed in this version.
Update: 13 June 2005 (fixes in v1.12)
  1. Byte-pipe Module to IHU data was occasionally dropping bytes on packet boundaries (first 1 to 6 bytes of a packet) only when both directions were active at the same time. When either direction (Module to IHU or IHU to Module) was active by itself no data loss was occurring.
    NOTE: the bytes were being correctly handshaked to the Widget from the Module. They just were not being sent to the IHU when this failure occurred.
Update: 20 May 2005 (fixes in v1.10)
  1. Byte pipe initialization (code detecting when to assert/deassert INACK in response to Widget being ready) was incorrect.
  2. EEK! Debug code was left in the byte-pipe routines which caused any byte read from the inputs to be written to the outputs.  This has been removed.
  3. Jump2isp still not working but just received more clues which I now need to test.
Update: 04 Mar 2005 (fixes in v1.08)
  1. Counters were not incrementing. The problem was due to where the counter initialization took place. I've moved the counter-init call to cold-start initialization verses every-start (oops ;-).
  2. The jump2isp is not working after awakening the H/W Watch-dog. It turns out that this is known behavior [Errata] with this part. I'm experimenting with code that will allow this function to work again based on ATMEL's suggested workaround.

 

Home

 CAN-Do! Website copyright 2007, Stephen Moraco, KZ0Q  (formerly KC0FTQ).
For problems or questions regarding this Web site contact kz0q@amsat.org.
Last updated: 21-Oct-2007 12:40:48 -0600.