This adds an unconditional endpoint reset procedure to every SET_FEATURE(UnHalt).
It doesn't really make sense that this is required, *particularly* as
we *MUST NOT* set bEndpoint->bank to 0 here.
Without this patch, I'm observing the following problem:
Every first OUT transfer after a SET_INTERFACE + UNHALT on a bulk endpoint
is lost. "lost" means that it completes successfully on the host, can
be seen completing successfully with an ACK on a USB bus analyzer,
but still doesn't show up in the firmware. No Endpoint Interrupt
is generated.
This can be reproduced by calling libusb_set_interface_alt_setting()
from the host and then submitting a single OUT transfer.
Change-Id: I18ed530e617baddf76e8f9829512443ce2a76e0d
This should help debug watchdog triggers. Also reduce the timer to 1s
to hopefully increase the chance of triggering it.
Change-Id: Ie3f47e5612cdf501abff8cb6954600b785b3a3fa
When the uC firmware starts, assert the (high-active) _RESET GPIOs,
which will cause the transistors to drive the mPCIe slot !PERST
low.
There is of course a short instance of time between the uC reset
until it executes wwan_perst_init(). To avoid this, a hardware
pull-up would have to be re-worked onto the _RESET[1..4] signals
on the PCBA
Change-Id: I8742fefa4bf02e728e34d5d8cbc0fda771e78ffb
SIMtrace should reject any card activation at 1.8V as it is a 3[.3]V device
without level shifters. For this, we must include the ADC in
determining the VCC voltage.
Change-Id: Ic76f06037590ff1c0dae818d5eb2c2019dd75f2d
FIXME: reporting uses raw ADC voltage, not the voltage before divider
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
this provides an esy way to understand more without looking at the
detailed decode for each packet.
Change-Id: I0aa3d68172022907fbe8371aaca6538df0649dfe
Sometimes I get LIBUSB_TRANSFER_ERROR particularly when the USB bus
is very busy. We shouldn't terminate the program, but simply resubmit
it. That's what we have multiple transfers for...
Change-Id: I77d7bc636c21171fcff7e70e87c0109cbaee9b51
We initialize a local variable to -1, and if the user specifies
no address from the command line, we use this in the interface match
struct, which uses a uint8_t. This means 255 ends up in there, and
as a result no usb interface ever matches unless the user explicitly
specifies the -A command line argument.
With this patch any absent -A argument will result in ifm.addr == 0,
which means "don't match on address", and which is what we want here.
Change-Id: Iffb5fa406ddef00c7c15570ffca2c109b98d7a2d
In some readers (at least CardMan 3121), the simtrace2-cardem firmware
claims there are power-up sequences where RESET is released before VCC
becomes active. Let's detect such spec-incompliant power-up sequences
and use them to trigger a cold reset of the card.
Change-Id: I682ac3d0c2b98749a6ed44f9a73e4b39354a4284
Closes: OS#5421
* drop log statements that are already in libosmo-simtrace2
* don't printf directly, but go via LOGCI
* make LOGCI use libosmocore logging
* configure libosmocore logging in a 'convenient' way
Change-Id: I6fa0da966e6d8e723c187404c17e90cfb3f3dd9f
This avoids related ASSERTs or error messages in case any of the
libosmocore / libosmousb API functions internally tries to log
something.
Change-Id: I611c435516856c5c8928d7810fd9a9b831adc199
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
this is redundant. We care about *which* message type, and not about
wasting horizontal screen real-estate.
Change-Id: I98f90561b39401f1c2339f79a3cb40574bb03b2d
This can lead to some fields not properly zero-initialized, fooling
our matching code into the application having requested certain
fields to match ('0' is usually assumed to be unspecified).
Change-Id: I304d55b584e37d9dccb75b24057bb682f799beb2
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
Add a new command to request that the simtrace2 firmware manipulate the
card detect signal, causing the downstream cellular modem to believe
that the SIM card has been inserted or removed, respectfully.
Change-Id: I8c79eb29379a789d9d0d21495e30d66ddbdfb022
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
Apply various improvements from Martin Hauke, thanks!
* Put sover into a variable
* Sync BuildRequires with configure.ac
* Update libosmo-simtrace2 summary
* Use %make_build instead of make %{?_smp_mflags}
Change-Id: I35ce3865702f72365b38b0eaa8b28f332dabcd1f
Adjust the soname in the rpm recipe too, to fix:
error: File not found: /home/abuild/rpmbuild/BUILDROOT/simtrace2-0.8.0.202112100026-1.1.x86_64/usr/lib64/libosmo-simtrace2.so.0*
Change-Id: I748f44409ac736abbd5c18e31ae02d025dee2c77
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
Harald Welte
Eric Wild
James Tavares
Oliver Smith