Level shifter state during reconfiguraiton? #96
Comments
whitequark
added
revC
|
Pull-downs are plausible on the back side. It won't be fun but I think it's doable. We already have a couple of resistors back there. Our only static load on VIO is the feedback divider, which is 83kΩ. We have about 6µF of capacitance on that bus, so not considering any external capacitance, that's a tRC of half a second. Not terrible, not great. The easiest change to improve this would be to dump a 1kΩ discharge resistor on there (easy to retrofit to revC0 units), which would add a worst-case load of 5mA and reduce the tRC to 6ms. This is probably a good idea anyway, we'd want level changes on that rail to be responsive. |
|
I couldn't find a proper threshold for the shifters to shut down, but I'm guessing 3tRC will probably do it in all cases (that's 5V to 0.23V). |
|
Discharge resistor sounds great, and we need that regardless of this issue--I think I've hit the problem with rails changing too slowly before. We can qualify the level shifter threshold easily, at least the ballpark. |
|
Let's call this closed for revC1. Discharge resistors are there, we can revisit and add pull-downs if it becomes a problem. |
Fixes GlasgowEmbedded#552, previously reported as GlasgowEmbedded#96 but not fully addressed. The minimum delay (3×t_RC for onboard bulk capacitance) is 18 ms, the actual delay implemented is 250 ms, to account for capacitance in the device under test as well. RevAB devices are not affected. In addition to the primary issue, another issue was discovered, where turning off the FIFO bus was causing phantom zero bytes to be received by applets, which could then exhibit undesired operation. This was addressed as well by disabling the FIFO bus after and not before reset. The code size does not change because some code was moved to improve sdcc codegen.
Fixes GlasgowEmbedded#552, previously reported as GlasgowEmbedded#96 but not fully addressed. The minimum delay (3×t_RC for onboard bulk capacitance) is 18 ms, the actual delay implemented is 250 ms, to account for capacitance in the device under test as well. RevAB devices are not affected. In addition to the primary issue, another issue was discovered, where turning off the FIFO bus was causing phantom zero bytes to be received by applets, which could then exhibit undesired operation. This was addressed as well by disabling the FIFO bus after and not before reset. The API level was incremented to ensure devices are reflashed with the new firmware including this safety critical change as soon as possible. The code size does not change because some code was moved to improve sdcc codegen.
Fixes #552, previously reported as #96 but not fully addressed. The minimum delay (3×t_RC for onboard bulk capacitance) is 18 ms, the actual delay implemented is 250 ms, to account for capacitance in the device under test as well. RevAB devices are not affected. In addition to the primary issue, another issue was discovered, where turning off the FIFO bus was causing phantom zero bytes to be received by applets, which could then exhibit undesired operation. This was addressed as well by disabling the FIFO bus after and not before reset. The API level was incremented to ensure devices are reflashed with the new firmware including this safety critical change as soon as possible. The code size does not change because some code was moved to improve sdcc codegen.
Fixes #552, previously reported as #96 but not fully addressed. The minimum delay (3×t_RC for onboard bulk capacitance) is 18 ms, the actual delay implemented is 250 ms, to account for capacitance in the device under test as well. RevAB devices are not affected. In addition to the primary issue, another issue was discovered, where turning off the FIFO bus was causing phantom zero bytes to be received by applets, which could then exhibit undesired operation. This was addressed as well by disabling the FIFO bus after and not before reset. The API level was incremented to ensure devices are reflashed with the new firmware including this safety critical change as soon as possible. The code size does not change because some code was moved to improve sdcc codegen.
It looks like we are constrained in level shifter routing: the DIR input is referenced to VCCA. When DIR is low, B is an input. Ideally, we would have this as the state of the tool when the FPGA is reconfigured, but AFAIK the FPGA pins are all set to be weak pullups.
Should we add external pulldowns? This seems... basically impossible placement-wise.
The alternative is to force the entire level shifter into a high impedance state by disabling the voltage regulators. (Good thinking, @marcan--if we powered level shifters directly from Vsense this would not be possible.) The problem is that discharging the output capacitor below the cutoff level may take a while and we cannot directly determine when this happens. So it would be a hardcoded worst-case delay in the FPGA reconfiguration code.
Thoughts?
The text was updated successfully, but these errors were encountered: