FreeCalypso > hg > fc-magnetite
view doc/FCDEV3B-hardware-bug @ 526:fbf0fabc5505
doc/Bootloader written
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sat, 22 Sep 2018 05:59:38 +0000 (2018-09-22) |
parents | 15c61c8f3166 |
children |
line wrap: on
line source
Our current FCDEV3B boards exhibit a hardware bug: the reset input to the flash chip is connected to Calypso's FDP output per both TI's Leonardo reference schematics and Openmoko's working design, but this arrangement turns out to be unsuitable for the high-capacity Spansion S71PL129NC0HFW4B flash+pSRAM chip we are using, copied from Pirelli DP-L10. This hardware bug has manifested itself in two different ways so far: * Out of the 20 boards we've built so far, on just one board there was an issue where our standard Magnetite fw would have trouble booting from flash, but RAM-loaded fw booted fine. Interrupting the boot process serially and having the serially loaded code jump to the image in flash also worked fine. Eventually it was found that the flash boot problem on that one board occurs only when flash boot mode 1 is used, whereas flash boot mode 0 works fine. I (Mychaela) suspect that the problem has something to do with the watchdog reset that happens as part of flash boot mode 1, the FDP output behaviour during that watchdog reset, and the flash chip's reaction to the latter. * On all of the boards there is a problem with sleep modes: when the firmware is running from flash as opposed to RAM, certain sleep-wake sequences cause an erratic self-reboot or a hang. Oscilloscope probing on a decased Pirelli DP-L10 motherboard on which Calypso's FDP output is accessible seems to confirm my (Mychaela's) suspicion that this FDP signal goes low during all sleep modes, and the current working hypothesis is that our Spansion flash chip gets unhappy with the reset timing it gets subjected to, and some flash reads (instruction fetches) don't work after wakeup. So far the only workable solution has been to disable all sleep modes in all FCDEV3B fw builds; nothing else has been successful. However, re-enabling all of these sleep modes with AT%SLEEP=4 works fine when the firmware image executes out of RAM instead of flash, further supporting our current working hypothesis as to the root cause. The fcdev3b-hacks directory contains two hacks that can be applied to FCDEV3B firmware images (fwimage.bin builds) as xxd binary patches: * The first hack dating from 2017-05 patches the fw to use flash boot mode 0 instead of TI's original flash boot mode 1, but after boot the FFFF:FB10 register is set to put the flash and not the internal ROM at address 0, so the interrupt and exception vectors go to the flash like in TI's original fw, not through the internal ROM. This hack was put together for the purpose of producing flashable fw images that boot without problems on that one board on which flash boot mode 1 didn't work, and worked successfully for that purpose. * The second hack dating from 2018-03 patches the fw to not only use flash boot mode 0, but also route the interrupt and exception vectors through Calypso's internal ROM. I was hoping that this hack would make the sleep mode problem go away by having the Calypso execute some cycles out of its internal ROM and RAM before hitting the flash after wakeup, but nope, bringing up the SIM interface with AT+CFUN=1 in the l1reconst config when running from flash with small sleep enabled still triggers erratic misbehaviour even with this patch. The proper fix will require a new PCB spin to change the flash reset wiring: instead of driving it with Calypso's FDP output, use the ON_nOFF master reset signal from Iota's VRPC block, fed through a logic voltage level translating buffer to change it from 1.5 V to 2.8 V logic. The flash chip we are using has lower power consumption when it is NOT held in reset, hence unlike TI's intent with FDP, we don't want our flash chip to go into reset during any sleep at all. The new PCB revision with this change is now in the process of being finalized, and we will soon need the funding to produce the new boards. Anyone who is interested in helping to make FCDEV3B V2 a reality should email Mychaela.