FreeCalypso > hg > fc-magnetite
comparison 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 |
comparison
equal
deleted
inserted
replaced
| 568:69ffd7f2346d | 569:29c0be5a1962 |
|---|---|
| 1 Our early FCDEV3B boards (the first two batches made in 2017, now retroactively | |
| 2 called FCDEV3B V1) had a hardware design defect that affected sleep modes; this | |
| 3 defect has been fixed on our current FCDEV3B V2 boards. The design defect on | |
| 4 FCDEV3B V1 was as follows: the reset input to the flash chip was connected to | |
| 5 Calypso's FDP output per both TI's Leonardo reference schematics and Openmoko's | |
| 6 working design, but this arrangement turns out to be unsuitable for the high- | |
| 7 capacity Spansion S71PL129NC0HFW4B flash+pSRAM chip we are using, copied from | |
| 8 Pirelli DP-L10. Calypso always drives its FDP output low during all sleep | |
| 9 periods, including small sleep which can be arbitrarily short, and while TI may | |
| 10 have thought it was a good idea to plunge the flash chip into reset during all | |
| 11 sleeps, even ultra-short ones, newer flash chips like our current Spansion part | |
| 12 are not happy with such reset timing. The datasheet for S29PL-N flash (the | |
| 13 flash part of S71PL-N MCPs) says that the minimum reset pulse width must be | |
| 14 30 us, and the "dance" put out on FDP by the Calypso during certain rapid | |
| 15 sleep-wake sequences appears to violate this timing requirement. Furthermore, | |
| 16 with our current flash chips (both our chosen Spansion part and OM's original | |
| 17 Samsung K5A32xx) there is no power saving advantage to putting the flash chip | |
| 18 into reset (in fact, with Spansion flash it is the opposite according to the | |
| 19 datasheet!), hence the solution is straightforward: on our current FCDEV3B V2 | |
| 20 boards we have disconnected FDP from the flash chip, and we use a different | |
| 21 circuit to provide our flash chip with the reset which it requires. | |
| 22 | |
| 23 The practical effect of the just-described hw defect on FCDEV3B V1 boards is | |
| 24 that all sleep modes must be disabled when the firmware is running from flash | |
| 25 (run-from-RAM firmwares are not affected), otherwise the firmware will | |
| 26 erratically hang or self-reboot on certain sleep-wake sequences. If you have | |
| 27 an FCDEV3B V1 board and you would like to run our current FC Magnetite firmware | |
| 28 on it, you have two options for disabling sleep: | |
| 29 | |
| 30 Option 1: You can flash a regular sleep-enabled fw build, and then on every | |
| 31 boot, before doing anything else, issue an AT%SLEEP=0 command to disable all | |
| 32 sleep modes. | |
| 33 | |
| 34 Option 2: You can compile a special fw build that boots with all sleep modes | |
| 35 disabled: | |
| 36 | |
| 37 ./configure.sh fcdev3b hybrid DISABLE_SLEEP=1 SUFFIX=-nosleep | |
| 38 | |
| 39 Additionally, there was one (only one) FCDEV3B V1 board from the very first | |
| 40 batch (kept by the Mother and not sold or given away to anyone) that had | |
| 41 trouble booting from flash on normal power-up. By Murphy's law, it just | |
| 42 happened to be the one board on which our very initial bring-up work was done. | |
| 43 RAM-loaded fw booted fine, interrupting the boot process serially and having | |
| 44 the serially loaded code jump to the image in flash also worked fine, but | |
| 45 regular flash boot exhibited erratic behaviour. Eventually it was found that | |
| 46 the flash boot problem on that one board occurs only when flash boot mode 1 is | |
| 47 used, whereas flash boot mode 0 works fine. I (Mychaela) suspect that the | |
| 48 problem has something to do with the watchdog reset that happens as part of | |
| 49 flash boot mode 1, the FDP output behaviour during that watchdog reset, and the | |
| 50 flash chip's reaction to the latter. | |
| 51 | |
| 52 The fcdev3b-hacks directory contains two hacks that can be applied to FCDEV3B | |
| 53 firmware images (fwimage.bin builds) as xxd binary patches: | |
| 54 | |
| 55 * The first hack dating from 2017-05 patches the fw to use flash boot mode 0 | |
| 56 instead of TI's original flash boot mode 1, but after boot the FFFF:FB10 | |
| 57 register is set to put the flash and not the internal ROM at address 0, so | |
| 58 the interrupt and exception vectors go to the flash like in TI's original fw, | |
| 59 not through the internal ROM. This hack was put together for the purpose of | |
| 60 producing flashable fw images that boot without problems on that one board on | |
| 61 which flash boot mode 1 didn't work, and worked successfully for that purpose. | |
| 62 | |
| 63 * The second hack dating from 2018-03 patches the fw to not only use flash boot | |
| 64 mode 0, but also route the interrupt and exception vectors through Calypso's | |
| 65 internal ROM. I was hoping that this hack would make the sleep mode problem | |
| 66 go away without a hardware respin by having the Calypso execute some cycles | |
| 67 out of its internal ROM and RAM before hitting the flash after wakeup, but | |
| 68 nope, bringing up the SIM interface with AT+CFUN=1 in the l1reconst config | |
| 69 when running from flash with small sleep enabled still triggers erratic | |
| 70 misbehaviour even with this patch. | |
| 71 | |
| 72 Just to reiterate, none of these hacks are needed for our current FCDEV3B V2 | |
| 73 boards - instead I am merely preserving our development history here. |