FreeCalypso > hg > fc-magnetite
diff doc/FCDEV3B-V1-issues @ 569:29c0be5a1962
doc update for the arrival of correctly working FCDEV3B V2 hardware
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sat, 12 Jan 2019 19:46:58 +0000 |
parents | |
children |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/FCDEV3B-V1-issues Sat Jan 12 19:46:58 2019 +0000 @@ -0,0 +1,73 @@ +Our early FCDEV3B boards (the first two batches made in 2017, now retroactively +called FCDEV3B V1) had a hardware design defect that affected sleep modes; this +defect has been fixed on our current FCDEV3B V2 boards. The design defect on +FCDEV3B V1 was as follows: the reset input to the flash chip was 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. Calypso always drives its FDP output low during all sleep +periods, including small sleep which can be arbitrarily short, and while TI may +have thought it was a good idea to plunge the flash chip into reset during all +sleeps, even ultra-short ones, newer flash chips like our current Spansion part +are not happy with such reset timing. The datasheet for S29PL-N flash (the +flash part of S71PL-N MCPs) says that the minimum reset pulse width must be +30 us, and the "dance" put out on FDP by the Calypso during certain rapid +sleep-wake sequences appears to violate this timing requirement. Furthermore, +with our current flash chips (both our chosen Spansion part and OM's original +Samsung K5A32xx) there is no power saving advantage to putting the flash chip +into reset (in fact, with Spansion flash it is the opposite according to the +datasheet!), hence the solution is straightforward: on our current FCDEV3B V2 +boards we have disconnected FDP from the flash chip, and we use a different +circuit to provide our flash chip with the reset which it requires. + +The practical effect of the just-described hw defect on FCDEV3B V1 boards is +that all sleep modes must be disabled when the firmware is running from flash +(run-from-RAM firmwares are not affected), otherwise the firmware will +erratically hang or self-reboot on certain sleep-wake sequences. If you have +an FCDEV3B V1 board and you would like to run our current FC Magnetite firmware +on it, you have two options for disabling sleep: + +Option 1: You can flash a regular sleep-enabled fw build, and then on every +boot, before doing anything else, issue an AT%SLEEP=0 command to disable all +sleep modes. + +Option 2: You can compile a special fw build that boots with all sleep modes +disabled: + +./configure.sh fcdev3b hybrid DISABLE_SLEEP=1 SUFFIX=-nosleep + +Additionally, there was one (only one) FCDEV3B V1 board from the very first +batch (kept by the Mother and not sold or given away to anyone) that had +trouble booting from flash on normal power-up. By Murphy's law, it just +happened to be the one board on which our very initial bring-up work was done. +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, but +regular flash boot exhibited erratic behaviour. 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. + +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 without a hardware respin 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. + +Just to reiterate, none of these hacks are needed for our current FCDEV3B V2 +boards - instead I am merely preserving our development history here.