Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
tomlogic opened this issue Apr 6, 2021 · 3 comments
Open

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

tomlogic opened this issue Apr 6, 2021 · 3 comments

Comments

@tomlogic
Copy link
Contributor

tomlogic commented Apr 6, 2021

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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.

@tomlogic
Copy link
Contributor Author

tomlogic commented Dec 9, 2024

In 2024, Digi troubleshot a customer issue on RCM3365 hardware where boards failed to start up when warmed above room temperature. Boards would “cold” boot, but could only get through a reboot sequence if kept off long enough to return to room temperature.

The root cause was related to timing issues when executing code on the 10ns SRAM with 0 wait states and 22MHz clock doubled to 44MHz. When running above room temperature, memory reads would fail if early /OE wasn’t enabled.

Customers experiencing similar symptoms should try patching CPUPARAM.LIB and StdBios.c in Lib/BIOSLIB with the changes detailed in #8. Those updated files ensure that early /OE is enabled before the clock doubler, regardless of whether the firmware is using the spectrum spreader.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant