This adds support for the new ngff_cardem board, a board that
basically combines a ngff breakout board with a built-in SIMtrace2.
Cardem works, but depending on the modem it might need a adjusted ATR to
ensure a lower baud rate is used by the modem, high rates might lead
to weird power cycling of the card after a few transfers.
Trace was also tested and appears to work as expected.
Change-Id: Ia96124fbe8a752c98e7fd4096d542a3b2b9bc255
Instead of using the timer/counter peripheral to handle the waiting time
and corresponding timeout, the USART peripheral internal timeout
mechanism is used.
This is particularly important for the SIMtrace board since there
(contrary to other boards) the I/O signal is not wired to a TIO pin
of the timer/counter block, and hence Rx/Tx data cannot reset that
timer/counter.
As a result of this migration, cardem is now supported not only on
owhw + qmod, but also on the simtrace board.
The guts of this change have been lifted out of Change-Id
Ibcb2c8cace9137695adf5fb3de43566f7cfb93b5 by Kevin Redon, which was
unfortunately touching various different topics at the same time and
hence was split up. Some improvements are the introduction of the
ENABLE_TX_TIMER_ONLY mode, which avoids the USART interrupt handler
getting hammered with TXRDY between release of RST and start of the ATR.
Change-Id: Ibcb2c8cace9137695adf5fb3de43566f7cfb93b5
Related: OS#1704
This reverts commit 4a58c08d67.
The code replicates to a large extent what is already present in iso7816_fidi.c
and I have serious doubts about the correctness of the computation in
its iso7816_3_calculate_wt() function.
Change-Id: I3f26da4e9aa8d7b0f4b4b7992269cf365a643ec7
We are not using any PIO interrupts from DFU mode. It's only used in
the main application firmware (verified by "git grep PIO_ConfigureIt")
Change-Id: Id1447af519df3183061f3d3f156a8dd84789af16
this adds the DFU as application, allowing to flash the bootloader.
a USB DFU alternative is added to flash the bootloader partition.
when the DFU is started as bootloader, the partition/alternative
to flash the bootloader is marked as "not available", and
ineffective.
the same happens for the application partition when DFU is started
as application.
this distinction is make at compile time, not at runtime, because
of size restrictions (the bootloader was already close to the
16 kB limit).
*_dfu_flash.bin should not be mixed with *_dfu_dfu.bin.
*_dfu_dfu.bin should be flashed as application using the already
existing DFU bootloader.
once this images is started (as application), the *_dfu_flash.bin
should be flashed as bootloader using the DFU application.
once the DFU bootloader has been flashed, soft resetting
(not re-powering) will cause the bootloader to start, allowing to
flash the application with a normal image (e.g. not DFU),
replacing the DFU application.
this switch to DFU only happens after downloading (e.g. flashing).
it is planned to have the DFU application erase itself after
flashing, but this is currently not implemented.
Change-Id: Ic273bb593a7669111b0219fe301d7897419167c8
In the end we want to share most of this, irrespective of the "APP".
Let's avoid unnecessary differences.
Change-Id: Icf063d4ca79edf66ffbe8e87a915deb77dec478a
This unifies the printing of the welcome banner, and it also ensures
that all modes print all information (serial number, reset cause).
Furthermore the APP and BOARD #defines from the make environment are
also printed.
Change-Id: I7e6bc05cee4b9ec0fd9a05dc90ce0b26a5763e5a
the USB trace now respects the global setting.
the verbosity is also decreased, not showing USB activity unless
debugging.
this also saves some space.
the reset cause is now printed.
the strings increase the bootloader size, but it already exceeded
the 16 kB limit when trace level is set to info.
Change-Id: I9ba08d4bb4f188f6e7a202ea86acb7a42a2054f3
"SIMtrace 2 compatible device" is pretty generic. Let's have the
actual board name inside the string descriptors, giving a more
user friendly experience in case users are issuing 'lsusb' and the
like.
Change-Id: Ibcc338b504bd2a1605e31d7f5eadb7161f547c6a
This string dates back to some very early naming; let's reflect how
we have been calling this in reality for quite some time now.
Change-Id: I5a7497188385706a1e924784073c619fa9bfdd60
when starting the DFU bootloader, but USB configuration (e.g.
enumeration) failed, the MCU restarted in the main application.
this occured after a DFU detach and were the USB host missed the
USB reset.
now after MCU reset, the bootloader is started again, since this
is what was requested to begin with.
the bootloader will always restart in the bootloader until USB
enumeration succeeded.
this boot loop can be stopped by unplugging/removing power from
the device.
Change-Id: I4062a7d8a7934af2119c169759b614dc45990651
the specification requires a reset duration of at least 10 ms.
reset is indicated by the device to the host by removing the
pull-up on D+ (host to device reset is a USB packet).
we used 20 ms, but on some setups (USB host, stack, hub, and load
dependent), this does not seem to be enough (no USB enumeration
was performed afterward, at least for the DFU bootloader).
increasing to 50 ms solved the issue on the affected setups.
instead of USB suspend, the more proper USB disconnect is used.
this mainly disables the pull-up provided by the USB peripheral.
USB activate is not required since the follow up initialisation
takes care of it.
Change-Id: If5ceb3b8f7a8f134d4439fdd138dd12b46589f97
the longer output is to fast and often incomplete.
the shorter version is enough to view the progress when not
debugging.
Change-Id: I97bb84da68d1f3bc14fb7c05400edf1748f55460
The freq_ctr app is a small application that is implementing a
simplistic direct-mode frequency counter using the internal 32.768kHz
oscillator and two TC blocks. One of them is used to generate a 1Hz
signal, which is then subsequently used by the other TC to trigger
a counter read after exactly 1s.
This is in itself not something useful on a simtrace2 device. However,
it is a separate 'app' and I prefer to have the code here in master
over some obscure branch that's easy to forget about.
Change-Id: I2249bfb8dd6a88d85d406f3b33537377133d0939
There have been tons of format-string related bugs in our code which
we never discovered due to disabling -Wformat. Let's fix that.
Change-Id: I5ec466361bcc526fac1f4897673264ee5af3458b
USB reset can be signaled by pulling low USB D+ for at least 10 ms,
according to the USB specification. This force a re-enumeration.
This time is increased to 20 ms to work with more USB HUBs.
Some SAM3S based board have external D+ pull-up mechanism (such as
SIMtrace) which needs to be used to pull D+ low.
This is a legacy mechanism from SAM7S history.
This mechanism is not required anymore on the SAM3S, and the qmod
does not use it. When the USB HAL is suspended, the transceiver is
disabled, causing D+ and D- to be pulled low. Then the HAL is activated
again. This is particularly required when DFU is started (and
enumerated), and after flashing the SAM3S switched to the main
application (without reset), so it can properly re-enumerate.
This board difference is now defined on the board header.
Change-Id: I9b58d8101c2fcf5595026b675728826af26127a3
a lot of the procedures are done in ISRs, but the watchdog is only
reset in the main loop.
this causes frequent reset, particularly at the beginning were
states have to the initialized.
Change-Id: Iad364444fca9d18f9a8cf47d5e0840ccd7bac2ef
The red and green LEDs are now used as follows:
- red on = power (firmware is running)
- red blink = error detected (e.g. during ISO-7816 parsing)
- green on = running (sniffer mode is running)
- green blink = activity (e.g. USB message sent)
Change-Id: Ib1b6ff87fb92d6ed3ecae4bc89386206aaab508e
TRACE_INFO will also provide the DFU start reason, but TRACE_INFO
(TRACE_LEVEL >= 4) should only be used for debugging.
WARNING: With TRACE_LEVEL >= 4 the DFU binary is over the maximum of
16 kiB allocated for the DFU bootloader.
Thus make combined will not boot the main application because its
start if after the expecte 16 kiB address; and flashing using DFU
will overwrite the DFU bootloader itself.
Change-Id: I82323e0f76c03f67df7dc8f2b6783166cc25f3aa
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.
Change-Id: I0597ec723cb2225540c89c3821b91d8a45adfcd6
because the applications share the board capabilities defined in
libboard/*/include/board.h and USB configurations are enabled according
to the previously defined capabilities in libcommon/source.usb.c, all
applications actually offer the same functions.
thus creating the trace application is only mainly a cosmetic change, as the
sniffer function will also be present and enabled in the cardem application.
Change-Id: I24b3500a0905cbd622507722280b3c7e7f188bde
This is required to make python pexpect.fdexpect happy, as it
requires that all characters are echo-ed back in order to detect
when the output of a given command starts.
Change-Id: I73b24e43f6c8b86a2766aba67d8307c184448aa0
the curent local copies of libosmocore headers + source is a temporary
hack anyway. We should instead rely on a system-wide install of
libosmocore cross-compiled for arm-none-eabi. But leave that as a
second (later) step beyond this patch.
Change-Id: Ia63fd842d45a2b404233b4326050e7eda0604cf0
This fixes the following compile error:
apps/dfu/main.c:73:3: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
for (unsigned int i=0; i<len; i++) {
^
apps/dfu/main.c:73:3: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
which was recently introduced in b73f0a00bc
During DFU download the destination start address is checked to not exceed the
RAM or flash end address, but it is also necessary to check if the end of the
data to be downloaded is also within the allowed range.
When downloading to RAM it is also necessary to check if the data to be
downloaded does not overwrite (i.e. corrupt) the stack.