Potential /OE timing issues on 29MHz products with 55ns flash

[tomlogic]

Due to the obsolescence of the previously qualified 45ns flash memory for select SKUs in the Rabbit family’s product line, Digi qualified 55ns flash from the same supplier and started manufacturing boards with that flash in 2020 Q4.

Calculations from the Rabbit 3000 data sheet and scope captures of flash memory reads show the processor timing meeting the flash memory's timing requirements with a narrow margin. In typical operation, the BIOS startup code enables an "early output enable (/OE)" feature that provides a wider timing margin.

There are two instances when that is not the case, and products are operating with the narrow margin:

• If the spectrum spreader is disabled (macro ENABLE_SPREADER set to 0).
• A brief moment (less than 10 opcodes) between enabling the clock doubler and enabling the spectrum spreader.

[tomlogic]

Products possibly affected (29MHz and 55ns flash) that might benefit from this patch include:

• RCM3000 Rev F (and later)
• RCM3010 Rev F (and later)
• RCM3100 Rev D (and later)
• RCM3110 Rev D (and later)
• RCM3400 Rev D (and later)

[tomlogic]

Also, please note the following information that was included in the PCN (Part Change Notification):

We have received reports of customers using 29MHz products and experiencing problems related to the change. In all instances, we determined that their firmware was crashing due to the undefined behavior of writing to a memory address mapped to the flash device when not in flash programming mode. This typically happened when running code from flash and dereferencing an uninitialized or NULL pointer. On products with a 45ns flash, the write was silently ignored, but with the 55ns flash it would prevent the next opcode from reading properly, resulting in the program crashing. Note that in the case of a bug dereferencing an uninitialized pointer, it could end up writing to a random address mapped to RAM, potentially overwriting other data and causing intermittent failures that would be difficult to reproduce. If you start experiencing failures with updated hardware, we recommend using the Dynamic C debugger to identify possibly coding errors causing the failures.