Set CFLAGS on top of the Makefile, to avoid using the distribution's
default CFLAGS. In debian testing and unstable, -fcf-protection was
recently added to the default CFLAGS, but it cannot be used with the
cross compiler:
[COMPILING libosmocore/source/backtrace.c]
cc1: error: '-fcf-protection=full' is not supported for this target
make[2]: *** [Makefile:270: obj/simtrace/flash_backtrace.o] Error 1
Change-Id: I5f7cd0402f9bb85dd600204fdf8855773ddbeb70
* Fix UTF-8 encoding. This caused the endianness check to fail, which
reads all .c and .h files.
* Add .checkpatch.conf to skip linting for:
firmware/atmel_softpack_libraries
Change-Id: Ibb2e42e9b4307275a33e4000c201847a6bd60137
We so far didn't have interrupts enabled for those, and just caught
them "by accident" if a byte was received or if a timeout happened.
Let's explicitly enable those interrupts so we also catch those
conditions by themselves.
Change-Id: Ia27f537706b9a6252dd18175545c6f27a7d17d0e
Before this patch, all UART characters went through a fifo/ringbuffer
of depth 512, while events like timeout were delivered directly via
a global flags variable from ISR to main code. This means that one or
more correct/complete TPDUs could theoretically still be in the FIFO,
but the "Fast path" of the timeout handling is pre-empting that and
messing with the state machines.
All events from the UART should be delivered via the ring-buffer to make
sure they arrive in order at the main function.
The old "report timeout via change flags in separate USB message" code
is left in place. On the USB protocol we should keep it for
compatibility. Internally we should probably also migrate that over
to the new ring-buffer method in a second step.
Change-Id: I4434c6fcd59d1a425e9ded734bbc8b0411a0a0d8
those kind of errors should be passed to the main loop for further
processing, in-order together with the byte stream received from the
USART.
Change-Id: Iebd9bbc97c2a5a0c402e7a2711520299a1ade568
So far, we use a uint8_t ring buffer as "FIFO" between USART Rx
interrupt and main context. That's fine for expressing the bytes we
receive. However, if we also want to report USART errors synchronously
in that stream, we actually need more bits to express those.
Reporting USART errors via the ring buffer is the only way how the
sniffer code can know in which TPDU the error occurred. Reporting them
any other way (global variable, ...) would loose the timing relationship
where in the received stream the error occurred.
This change just changes the ringbuffer from 1024-entry 8bit to
512-entry 16bit and doesn't add any error reporting.
Change-Id: Ifde054fbfe7f753b61e7d3409c56eca6e0faeb4b
Not critical (we disable the USART interrupts in NVIC anyway), but
if Sniffer_init() enables this flag, it's good style for Sniffer_exit()
to disable it.
Change-Id: I92e16a160d60fcab33c81e0cf074088b9f20b9ae
It's a bad idea to have a two-character global variable which might
easily clash with local variable names.
Change-Id: Ic2fac64129d2772a1923f35e48582be3b130a0f2
This is a purely cosmetic change that groups PPS, TPDU and ATR related
global variables into structs. The structs get g_ prefixes to indicate
a global variable. This avoids confusion between very short/generic
variable names that might clash with local variables.
Change-Id: I3e02f6c6b063ebc860b7a2a54dfc6051f1ea584f
process_byte_pps() would never enter the error path in which the
first byte would be != 0xff. However, the caller already verified
this before calling process_byte_pps() so the error path should
never be hit anyway.
Change-Id: Ia74b6338219a6965e6bd35a6efcf369890e02d81
rbuf_write() will tell us in the return value if the buffer was full
(error) or not (success). Let's use that return value rather than a
theoretically race-y call to rbuf_is_full() before.
It's theoretical as the write happens from IRQ context and the read from
normal process context, so the fill-level cannot really change while
we're in the USART interrupt. So it doesn't fix a bug, just improves
coding style and also avoids an extra function call + irq-disable/re-enable.
Change-Id: Icf570d0aa48d67a19e63c6e2b6caa14438fe88e3
In low-level debugging it might be useful to trace the TPDU state
changes, so let's factor-out the state-setting as a function that
can be amended with printf() or GPIO toggles or the like.
No logical change is introduced here, just assignments replaced with
calling a function that does the assignment. compiler should inline
that.
Change-Id: Ie61321404f3686234c61c68a07d6cb9f5830ddc1
Reading of code + datasheet showed that we did enable parity checking
but never actually checked if the USART has the PARE bit in CSR set.
Let's change that. Plus also avoid possible race conditions due to
multiple status resets via US_CR_RSTSTA. Let's only reset that once
per interrupt handler.
TODO: actually do something useful at that point. We currently don't
report those to the host, nor do we attempt to recover in any way. The
data sheet also doesn't tell us what it actually does in such
situations; it appears the character is *not* returned from the USART,
so we're missing one byte in the stream at that point.
Change-Id: I5f012d86c61a2377d355396e7b95d078952bee7c
Related: OS#5464
In the function set_tpdu_state(), there is a missing transition to
WAIT_TX state. This is fine if you are coming from the WAIT_PB state,
which has already restarted the waiting timer via
card_emu_uart_update_wt(), but if you are coming from the WAIT_RX
state, then card_emu_uart_update_wt() is never called and the USART
timer is never restarted. (Because the transmitter is left enabled in
WAIT_RX, the response is still sent to the modem; it is just the
half-wait timeouts that are missing).
Change-Id: Ib4eb964c073192e8f067004625af818ba2caf003
- improves trace diagnostic output by moving cursor back over the
the rotor before a diagnostic message has a chance to be printed.
there is still a race condition, but it is much better.
Change-Id: Iad7767f2a5dbbd67b0f33b9bfc2c3864ce308990
This fixes the firmware USB interface somehow getting stuck
after a USB disconnect/reconnect without power cycle.
Right now there are a number of things we only execute the first time we
reach USBD_STATE_CONFIGURED, but not at any subsequent such event.
It's also rather clear that this doesn't really show in simtrace2 as it
is bus-powered. And it doesn't show on OWHW as we don't have any USB
unplug situations of the USB between the on-board traces of USB host and
SAM3S. So this really only is relevant to QMOD.
A cheap and dirty work-around is to simply reset the entire uC every
time a USB unplug happens.
Change-Id: I6678bb2192c1419ed388b46c4ae7aa1ce18dc7ee
Related: OS#5578
This change prevents contention on the ISO7816 bus by disabling the card emulation state machine when the SIM switch is in the local mode. Without this change, the card emulation firmware can clobber ISO7816 communications and cause contention with certain (but not all) SIM cards.
Changes:
- Add 'enabled' flag to cardemu instance that is set/cleared by usb_command_sim_select() (the only place where sim switch occurs).
- Flag is initialized as false (disabled) by default, to match local SIM mode default.
- When card emulation is disabled, force SIM VCC to be "OFF", SIM RESET as "not in RESET", and drop bytes bytes received on the ISO7816 interface (but do service buffers).
Change-Id: I4010f988712eac4a6af8568ccd60062f9de62449
The firmware doesn't recover from a OSMO_ASSERT() which direct reset the board.
After the reset the firmware will waits forever for the USBD state USBD_STATE_CONFIGURED.
By adding the explicit USBD_HAL_DISCONNECT the board always recovers.
Fixes: OS#5478
Related: SYS#5752
Change-Id: I600a26025166d20b6b27c191f24e4023efdaadf6
Particularly the VCC/RST/CLK changes can happen quite frequent, and
we were seeing quite a number of overflows of the usb_buf queue for EP06
(interrupt endpoint) in cardem.
I first tried increasing the maximum queue size to up to 10, but that
still didn't resolve those EP06 overflow error log messages.
Reducing the bInterval from 16 to 1 made them go away in all my
tests.
Change-Id: I5c272c31983de7201cfbd445c4484f6832d878ab
the ISO7816 UARTs have highest priority, while console has lowest.
remaining sources (USB, ADC, GPIO) are in between.
Change-Id: Ie6c97d61d8da3990b6e44144f36cb6d37d194307
This is what we do in all other functions, not sure why this one
wants to silently ignore any such programming errors.
Change-Id: I022eee86a5a3b5077abe59897161578ed960f1b1
The SIMtrace2 protocol alwasy contained a field for the VCC voltage,
the cardem firmware just never populated that field, even on those
boards that use the ADC to determine its voltage.
Change-Id: Idcecad553fb36380e916378e1420488acbbfa8e3
Add new board.h definition BOARD_MAINOSC_BYPASS to configure the clock module to use an external oscillator rather than a crystal. The qmod board is one such board.
Change-Id: If62f55cd4c8b0cf758534f09d25a9bcb028814a7
DFU flashing of apps sometimes aborts, and although rare this leads to
broken devices if no boot button or serial/jtag access exists, because
the bootloader will keep trying to start a half-flashed app that then
crashes at some point.
The easiest fix that works with existing bootloaders is to prepend a
small 512 byte stub that calculcates the crc and compares it with the
crc calculated at build time, and then either starts the actual app, or
sets the dfu flag and resets. This ensures we either have a working,
running app, or end up in the bootloader, ready to flash again.
For obvious reasons this only applies to dfu apps, and not to flash
targets like the actual bootloader itself.
Change-Id: Id6df0486c8b779889d21800dc2441b3aa9af8a5f
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: Ie0a3b2273383adbb3303faffd6ff96be7f4cae99
The previous value was way too low and led to reenumeration issues when
switching from app to bl because the hosts are fairly lenient and
feature long delays until they accept disappearing devices as gone for
good instead of ignoring a presuambly flaky usb cable or connection.
Related: SYS5061
Change-Id: I9b8c8bf794ad5b94fc7ea2a01d1ebf4e36862c36
All the parts are DNP and never existed on the simtrace2 with sam3; the
sam3 has internal pullups that are part of the usb peripheral.
Change-Id: I04a703a2eba6ff1dc64692c089213389d0c1066d
This bl updater can be flashed as app and will update the bootloader and
then
delete itself before resetting the sam3, so the device will end up in
the newly
updated dfu bootloader afterwards, without having to press the
bootloader button
or requring any other manual interaction, ready to receive a new
application image.
Building the blupdater requires a previously built dfu-flash bootloader
bin file that
will then be embedded into the app during building.
Related: OS#1704
Related: SYS5061
Change-Id: I53dea57bba790a2ab3245d9483e0ff1c8d19d5e3
This led to occasional crashes for targets with leds since it was
introduced 3 years ago
The interesting thing is that most of the time it didn't crash...
Change-Id: Ia6a1b1fc0e44a301b4fb1d9c9fdbc27d61dcab97
Supposed to be used with https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm
+ distro provided binutils-arm-none-eabi package, might provide better and more reliable
binary sizes, especially for the bootloader.
Just run USE_CLANG=1 make
Change-Id: I1a19f40d44797efad5c46121e73115ed738a095b
This reverts commit e6a76c7bf4.
Might or might not cause weird issues depending on gcc and binutils
versions, let's see if this helps.
Change-Id: I2f593fd5e0f1494aae6b9fcfb2160a6c9168f5b8
We keep running out of rom space, so reduce tracing to nothing for alle
dfu targets, and let's hope newer gcc versions stop producing more
code...
Change-Id: I7d2947c84097035bed00ad489a175d614b4c388e
The "wait time extension timer" was apparently not being reset during
normal tx operations, which led to occasional NULL (0x60) bytes getting
injected into transfers, which in turn led to more tx bytes than what
the reader side expects...
The odd thing is that this was only noticeable with high baud rates,
probably due to the very long default WT of 9600 ETU, and even then only
because it led to weird ngff modem resets after benign transfers.
Change-Id: I15b0b83b7d93b8e5589f3640bd6eb2fc82f93394
Related: SYS#5553
Single threaded evaluation is (assumed to be!) left to right, depth
first - but with concurrent make using -j this breaks, because the
actual usb string header is generated after the attempt to concurrently
compile the code that needs it, since there is no explicit order among
the all: dependencies.
This is fixed by properly adding a dependency on that header.
Change-Id: I0bdf915deabeda861f6398e654764918e58a64c2
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
The tester has shifters, while the original simtrace relies upon the
reader restarting the powerup attempt with > 1v8 after not respondig due
to a lack of shifters and therefore 1v8 support.
Change-Id: I520aa26c6e0fb34568a4f632943efa59a0da831c
Oliver Smith
Harald Welte
James Tavares
Eric Wild