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 avoids
ERROR: osmo_log_info == NULL! You must call log_init() before using logging in log_check_level()
Change-Id: Id355ef33e10164f8e8eb40c2fd0b606bc8e9b6f7
This code already calls osmo_libusb_init further above in the top
of the main() function, so there's no use of calling libusb_init()
directly in the same function lines below.
Change-Id: I2e0c7446aaa644c5aae1059ce91ff9f729903cbc
We use other osmo_libusb_* functions later in the code, so it is best
to initialize the library via libosmousb, and not directly.
Change-Id: I2fd981935e1420e529f5dd8a98edd347c317284c
Let's create and publish binary builds for 'trace' on BOARD=ngff_carde.
According to SYS#5525 this is verified working since two months ago, so
there's no reason to withhold the binary builds for it.
Change-Id: I8a98002ef5aa58e5a3d49627323fe11505508bc8
Related: SYS#5525
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
It does fit with some compiler versions, while others overflow the bl region,
so just reduce the trace level a bit to make it fits all the time.
Change-Id: I168a847da8dfc585aaeef0030f95fc225a713147
This makes sure downloads.osmocom.org will get cardem images
for the new ngff_cardem board.
The dfu loader was not enabled as it currently overflows the ROM
region by 200 bytes, see OS#5210.
Change-Id: Id2b7925c823fb19f880e06a205764d2b19de4ad4
Related: OS#5210
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
There is no obvious reason why the st should be stuck in cardem mode
without a working running util on the host side since there is no state
that is being kept, so switch back to using the local sim upon reset.
Change-Id: Ib622af0027d40b4e8afbb0fa0d3689f0dbfcac92
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 simtrace-tool is a command line tool which can be used to e.g.
manually request a modem reset.
Change-Id: I3a8896ac2b3caef7590b51118359e5caed820a40
we shouldn't use a local copy of the device id list, which is already
outdated now that OCTSIMTEST support has been added to libosmo-st2
Change-Id: I2231006b94c33fe3b28ce37b0d54c67206751058
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
See Help->About Wireshark->Folders tab,the usual place this should go is
~/.local/lib/wireshark/plugins
Hot reload possible after editing using Analyze->Reload Lua Plugins
Change-Id: I360ab522dabc3a378969df36efd3b48fc4cade3c
Back in I8c9b0c3d862a967832134b24252577739182da62 we added support
for enabling the card_insert signal, but not for explicit disable
of it. Let's fix that.
Change-Id: I6f32bde60674119c9912e51059a53b5ee74d074a
The octsimtest board can control the card-insert contact of the OCTSIM
under test via an external I2C gpio multiplexer; let's add support for
that.
Change-Id: I8c9b0c3d862a967832134b24252577739182da62
* driver should not have hard-coded understanding about I/O directions
* board code should pass the I/O direction to driver
* board code should use the correct I/O directions (A0..7, B0: output)
Change-Id: Id4a8e012a33cee01bb489e612e17920760b9be59
octsimtest has a resistive voltage divider in front of the VCC ADC
in order to also detect 5V. We must make the thresholds board-specific
and adjust them for octsimtest.
Change-Id: I9e4adb4f349d2d838ea4100eb49271f3a0e7a2a5