Use USART 0 connected to the SIM card side to sniff the communication.
The card side can also measure ETU times.
Do proper pin initialization.
This code can already capture the ATR communication between phone and card.
fixes following warning:
libboard/common/source/board_cstartup_gnu.c:137:11: warning: assignment to 'void (*)(void)' from 'unsigned int' makes pointer from integer without a cast [-Wint-conversion]
appReset = pSrc[1];
adc2uv is not used in boardver_adc.c.
a FIXME comment says it should be shared with mode_cardemu.c.
the exact same code is already available in mode_cardemu.c
The original board startup script is provided by Atmel.
It has been modified to handle application or DFU booting.
The copyright notice has been updated to reflect this change.
Each board can define its own conditions on which the controller should
boot into DFU mode rather than normal application mode. Let's move the
"UART loopback jumper" to QMOD specific part. For SIMtrace we have an
actual button and can use that in a future patch.
The logic to detect if the respective module is already initialized
or not was broken. When performing initialization, we of course need
to set initialized=1.
We now generalize the USB communiction and abandon the 'req_ctx'
structure inherited from openpcd. Instead we use the libosmocore 'msgb'
structure to handle incoming and outgoing USB tranfers. We also use
linuxlist-based msgb-queues for each endpoint.
This was introduced for interoperability with operating systems that
might prefer such setup (I heard that Windows prefers this about a
decade ago, but I don't have any personal experience with it).
However, using different VID/PID between DFU and RT breaks usability of
dfu-util, and I really think this matters much more to our users and
developers.
the default boot state should be to use the local SIM, until the user
changes it (currently only possible via entering '!' or '@' on the
serial console). The code so far had this completely inverted.
The port mapping is now as follows:
* port 1: ST12
* port 2: modem 1
* port 3: modem 2
* port 4: ST34
* port 5: modem 3
* port 6: modem 4
* port 7: daisy-chaining port
Using the USBDFU_OverrideEnterDFU() function, a board/application can
define extra conditions when the system should boot in DFU mode, even if
it was not explicitly switched to DFU mode from the application.
The app/dfu/main.c uses this mechanism to boot into DFU mode if the
stack + reset vector addresses are not plausible (i.e. some random junk
appears to be flashed in the application partition) or if the user
places a jumper accross the RxD+TxD lines of the debug UART. The idea
is that the system can be recovered by placing this jumper and then
re-installing the application from DFU.
Sometimes there is some leakage current via some I/O that's sufficient
to power up the SAM3S. Use the supply monitor to make sure the CPU
will be reset (and kept in reset) if the supply voltage is below 3.0V.
This makes sure that we'll re-enumerate on the USB, as a CPU reset
apparently doesn't automatically release the pull-up and notify the hub
that we were gone?
