A Scheme Interpreter for ARM Microcontrollers: Bugs and "Features" (050)

Known Bugs and "Features"

• Interrupts on Cortex-M3:
  Versions: 00.0250 and prior (corrected in 050).
  On these MCUs, an internal bug was present in code of 00.0250 and earlier whereby some interrupts were not disabled and re-enabled around a garbage collection occuring within an ISR. This bug may have affected i2c-based multiprocessing, only, on these MCUs, and has been corrected in version 050.
• User Files on STM32:
  Versions: 00.0250 and prior (corrected in 050).
  Erasing a user file on flash was unreliable on some of these MCUs in versions 00.0250 and prior as the erased file marker (scheme integer zero) contained a non-zero bit. This has been fixed in 050 by modifying the marker to binary zero. This affected only the file pseudo-erasing that occurs when a new file is created with the same name as an existing on-chip flash file (at which time the old file is pseudo-erased).
• On-chip flash on TI-EvalBot:
  Versions: 050.
  The on-board flash on the TI-EvalBot is not as durable as that of other MCUs according to the TI Errata. It may withstand of the order of 100's of erase-write cycles rather than tens of thousands. For this reason, user files should preferrably be stored on an attached SD-card on this board (except possibly for an on-chip "boot" file that would load a secondary boot file from SD card) and on-chip library use should possibly be limited, somewhat, as well.
• Samsung flash on SAM9-L9261:
  Versions: 050.
  The on-board Samsung flash chip used to store user files on the SAM9-L9261 is not guaranteed defect free by the manufacturer. Samsung however places indicator bits in on-chip flash sectors to indicate whether a given bank tested ok or not. This release of Armpit Scheme does not check these indicator bits and its (erase) command erases them. For this reason (and others), Armpit Scheme is restricted to using only the upper 1 MB of this 16 MB chip, such that potential erasure of defect indicators is limited to that area (the rest of the chip could still be used for Linux, for example).
• SD-card compatibility:
  Versions: 050, 00.0250, 00.0241.
  Brand-name SD-cards have been found more reliable that generic SD-cards in Armpit Scheme. Some generic 2GB SD-cards have been observed to work on MCUs with an SPI interface but not with an MMC/MCI interface, whereby, in the latter case, (sd-init) would always return #f. Brands that have worked so far include Kingston, PNY, RiDATA and SanDisk.
• First Use:
  Versions: 050, 00.0250, 00.0241.
  On MCUs supporting flash libraries, it may be necessary to erase all library flash on first use after this release has been installed (before adding new libraries to the system). This can be done with the command (erase -536870912) or (erase-libs) if available. If the system was used before, with a previous version of ArmPit Scheme, it may also be necessary to erase all file flash, with: (erase) if those files encroached into the top of the library space (for systems where files and libraries share a single flash space).
• Erasing Flash Libraries:
  Versions: 050, 00.0250, 00.0241.
  When erasing flash libraries using (erase -1), (erase -2) ... (erase -536870912) on a running system (on MCUs supporting such libraries), it is recommended to first de-import all imported libraries by using: (import). The remaining (non-erased) libraries can then be re-imported, preferrably after a system reset.
• On-board flash writing on SAM7-H256 and STR-H711:
  Versions: 050, 00.0250 (and possibly prior versions).
  Writing large files to flash on the SAM7-H256 and STR-H711 is unreliable (possibly due to the age of the chips used in developing the system). For example, loading the ARMSchembler form SD-card on these boards frequently leads to the onboard flash controller freezing. Small sized writes, or writes with ample wait between pages (256 bytes) appear unaffected.
• Parsing expressions that are not separated by a space or newline:
  Versions: 050, 00.0250 (and possibly prior versions).
  The ARMPit Scheme parser requires top-level expressions to be separated by spaces or newlines (newlines at the rep, spaces or newlines in files). An error is now returned when this is not the case, for example: (+ 1 2)(+ 3 4) ; without spaces -> (parse throw ?exp). A lack of space is however ok within (i.e. inside) top-level expressions, for example: (* (+ 1 2)(+ 3 4)) ; -> 21. This is important since 00.0250, where spaces are no longer automatically written between tokens. The programmer has to explicitly add spaces or newlines between top-level expressions written to file or they won't be read back properly.
• Quoted library forms:
  Versions: 050, 00.0250 (and possibly prior versions).
  Reading a quoted library form (eg. '(library (wawa) ...)) leaves the system in library-parse-eval mode (i.e. non-null value on (_GLV) at index 14). Subsequent evaluations take place in a reduced library environment. The item at index 14 in (_GLV) has to be reset to null manually in this case, if possible (otherwise, reset the chip). It is recommended to not quote library forms. To write a library form to an on-chip file, if needed, use a sequence of operations such as: (write-char #\( port) (write 'library port) (display #\space port) (write '(lib name) port) ... (write-char #\) port).
• General:
  Versions: 050.
  There are no other known new Bugs and "Features" (or corrected bugs) in this release relative to release 00.0250. Please consult the Change Log to identify other bugs that may have been fixed.

Last updated January 14, 2012