# HG changeset patch # User Mychaela Falconia # Date 1578170887 0 # Node ID 6edd9be81b94b10d2a4294615b3a8fbd52843390 # Parent f760e858098bedb0bc0a5bf0dc4ab91a5384df10 doc/Leonardo-target: update for Tango and Caramel diff -r f760e858098b -r 6edd9be81b94 doc/Leonardo-target --- a/doc/Leonardo-target Sat Jan 04 20:12:07 2020 +0000 +++ b/doc/Leonardo-target Sat Jan 04 20:48:07 2020 +0000 @@ -20,11 +20,14 @@ arrangement became trivial once our reconstruction of tpudrv12.c from disassembly of tpudrv12.obj reached production quality. -2) We are currently evaluating a certain third-party (non-TI) development board - which strongly appears to be a very close derivative of Leonardo, even closer - than Openmoko. We are hoping to get one of these boards into Mother - Mychaela's lab some time in 2020-01, at which time we will try running our - Magnetite-Leonardo fw on it. +2) At the end of 2019 we discovered a certain modem module which we call Tango, + and this Tango module is essentially a mass-produced version of TI's Leonardo + core. Tango is just the core of Leonardo, without any peripherals, thus a + proper fw build target for any given Tango-based platform is going to be a + little different from Leonardo in terms of GPIO and other peripheral config + (see our tangomdm target), but initially we ran our Magnetite-Leonardo fw + (built for target leonardo) on our Caramel board - it runs just fine except + for GPIO config being slightly wrong, leaving a few GPIO lines floating. Supported Leonardo variants =========================== @@ -101,6 +104,11 @@ UARTFAX_CLASSIC_DTR_DCD to 0 on this target, disabling that code in the uartfax.c driver. +This peculiar GPIO 2 situation applies only to real Leonardo boards, not to +Tango modems: a custom design using a Tango module can use this GPIO line for +anything, but on Caramel boards it drives RS-232 DCD like on D-Sample and thus +should be configured as a Calypso output. + Other GPIO and multifunction pins ================================= @@ -113,3 +121,15 @@ non-existent hw, and given the unknown of what other Leonardo variants may have existed once beyond our known schematics, we would rather leave a few floating inputs than risk causing a driver conflict on some unknown board. + +In the case of Tango these 3 just-mentioned Calypso signals are contained inside +the module (not brought out), and it is currently unknown if they are simply +unconnected or if perhaps they are tied to either GND or V-IO inside the module. +The Tango manuf's original fw leaves these signals in their power-up default as +Calypso inputs, hence we do the same currently in order to not risk causing a +short. At some later time when our finances allow doing so, we may send a +sacrificial Tango module for destructive PCB reverse eng and see what is really +done with these Calypso signals - if they are really unconnected, then we can +change the code to switch them to outputs, just like we have done for the +gtamodem target where the original manuf's official fw also left a bunch of +floating inputs.