the EEPROM byte output was causing data loss on the serial output,
resulting is automatic tests failing.
instead an end text will be output to detect the end of the procedure.
Change-Id: Ib8d3cbd01d0e34432d424355f4fafb24bc5273a1
the error code returned by vsnprintf was ignored,
resulting in printing the string from a previous print.
Change-Id: I8506b05d56da55d1357a1234917adf341b46e1db
Wformat requires uint32_t to be used in format string with the 'l'
qualifier (l = long = at least 32 bits).
this qualifier was not handled before.
since on ARM 32-bit int == long we can simply ignore it (stdio
already does not support 64-bit data).
Change-Id: Ib506a66f68712c6b3eeb5129a39abf47ec86a2a7
the higher baud rate allows for more debugging (without dropping
data) and is well supported by USB for UART adapters (this
standard baud rate is 8 x 115200).
the closest matching integer value is calculated for UART CR.
no floating point calculation can be used since this would
increase the size of the resulting binary by ~ 2kB (for the
softfp). this is not possible for the DFU since it already is
close to the maximum size of 16 kB.
Change-Id: I82b74f697342d580ccb79ada4715f35f4e8cca86
UART baud rate is main clock (MCK) divided by CR*16.
The MCK values are chosen >= 48 MHz and <= 64 MHz to have a near
integer value CR for a baud rate of 921600 bps.
The end MCK frequency between simtrace and qmod differ slightly
but are close to 58 MHz.
Change-Id: Iaa4a97fc68494c93b9d128503515d88049de506c
There's still no released libosmocore defining the GSMTAP_TYPE_SIM
sub-types (Change-Id: I5bd0dff5a4a90cfe96d9c4f3dec6657e1d85bf7a
dated Jul 26, 2018).
Let's make sure users don't need an unreleased version of the library
if it's only about a few #defines that we can just copy here for
backwards compatibility.
Change-Id: I2fd9e14873711d60f194bb404420bbfbb0a00f48
This reverts commit 77ff745cca.
libosmocore 0.12.1 is not recent enough, I misread the 'gitk' output.
Change-Id: I87a8e5bbb4aea0c991abe5372f840d76f17378eb
This fixes a bug, identified by the below compiler warning:
libboard/owhw/source/owhw.c: In function 'cardsim_gpio_init':
libboard/owhw/source/owhw.c:39:16: warning: passing argument 1 of 'PIO_Configure' from incompatible pointer type [-Wincompatible-pointer-types]
PIO_Configure(&pins_cardsim, ARRAY_SIZE(pins_cardsim));
^
In file included from ./atmel_softpack_libraries/libchip_sam3s/chip.h:45:0,
from libboard/owhw/source/owhw.c:20:
./atmel_softpack_libraries/libchip_sam3s/include/pio.h:189:16: note: expected 'const Pin * {aka const struct _Pin *}' but argument is of type 'const Pin (*)[2] {aka const struct _Pin (*)[2]}'
extern uint8_t PIO_Configure( const Pin *list, uint32_t size ) ;
^~~~~~~~~~~~~
Change-Id: I4c1de66c0b8475bb355b1d128f6ec88b2f2a7fcf
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
the upload failed because after the firmware were built (make),
they where removed (make clean).
now they are removed only after the upload.
Change-Id: Ie4421a6fa9207eb541107de9c14f265626f6be96
repeating the EEPROM erase (byte write) in case of byte write failure
could lead in an infinite loop.
log the error an return error code instead.
Change-Id: Id6f3654d877ca772ba04237da91a6e86e3f441ec
the script argument was not saved in the publish variable used later
to decide if publishing/uploading is needed.
Change-Id: Ic768a8e96e5e4d72acf3979da1412d683f79ec55
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
moving the define after the header fixes the following warning:
from ./atmel_softpack_libraries/libchip_sam3s/source/exceptions.c:46:
libcommon/include/stdio.h:63:12: warning: redundant redeclaration of 'printf_sync' [-Wredundant-decls]
signed int printf_sync(const char *pFormat, ...);
^~~~~~~~~~~
./atmel_softpack_libraries/libchip_sam3s/source/exceptions.c:45:16: note: previous declaration of 'printf_sync' was here
#define printf printf_sync
^~~~~~~~~~~
libcommon/include/stdio.h:51:12: note: in expansion of macro 'printf'
signed int printf(const char *pFormat, ...);
Change-Id: I21a8de325e8f8b91297dd157f2d6a0f64434bb28
firmware binaries should be uploaded to
https://ftp.osmocom.org/binaries/simtrace2/firmware/
this directory wiki be documented in the SIMtrace 2 wiki for users
to get the latest firmware images without having to cross-compile
themselves.
Change-Id: I589531f59e54a0997b012bdd91e3bef9f847f517
After a couple of seconds of USB data exchange between remsim and
cardem, the USB transfer hangs.
On host side (remsim) I can see the USB BULK IN request.
On device side (cardem) I see that data has been submitted and
"sent" over USB, but on wireshark with USBmon I don't see the
corresponding USB BULK IN response.
When exiting remsim or just after powering of qmod (causing an
error in remsim) the USB BULK IN is show in wireshark. Thus it
must have been in a buffer, but not read by libusb_bulk_transfer.
By shortening the timeout a new libusb_bulk_transfer is made more
frequently, and the data gets read successfully.
T;his change also fixes the URB data display.
Change-Id: I1d124a41cc90893506933f6d76dc7331e52a74f9
osmo_hexdump is particularly useful.
previously it was only defined, but not implemented.
this cause random behaviour upon call, often resulting in
memory corruption.
Change-Id: Ifd9120fa951f41693903fb657d10826959f1599f
The default ISR (particularly the HardFault handler) print information,
but this information was not displayed on the console because the UART
IRQ is lower than some default blocking IRQ.
Allowing to set synchronous transfer corrects this.
The underlying Atmel exception library had to be modified to use the
synchronous output.
Making UART_PutChar always synchronous when called from an ISR is not
desired because we use TRACE_ macros is some ISR. The synchronous
output must be set explicitly.
Change-Id: I1b4ace5185cf2dc32684934ed12bf6a8682e9bad
The slot number is in the header, and correctly set in st_push_hdr.
Setting the slot in st_slot_tx_msg will overwrite the payload data.
This caused bytes three of the ATR to be changed from 0x96 to 0x00,
corrupting the ATR. This corruption is caught by the ATR checksum,
and the modem would reset the card (2 additional times) to try to
get correct ATR.
Change-Id: If971699993617fc50557d20582c344ea06645a3f
this changes how ATR is handled.
the ATR is also printed when set (as important debug information).
the test is also updated to correspond to the new mechanism (
simulating the timeout before sending the ATR)
Change-Id: I69df797e2feadffa9f5f977cb71b69386cee7cd0
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
In case of error it also ensures the returned value is NULL.
Else a segfault would occur because the caller (e.g. remsim)
continued on with a free handler.
Change-Id: Ie7f20e3eff03acf77eb08283747ca8e032b9b4c8
The previous mechanism of retrying a failed write could become a
infinite blocking loop (until watchdog tiemout).
Also the array size is used to know how much data to write and verify
instead of a constant.
Change-Id: I8d2d090c5f4d1195f4c7eb29b3958a7bb05f56ec
The Atmel AT24C02 defines a maximum tWR waiting time after a byte
write of 5 ms before a next write.
Enforcing this wait time also fixed the failed verification in qmod,
where it was reading 0xffff instead of the written value.
Change-Id: I42c90b8d0329e425f275067e87d584212a43a90b
Kevin Redon
Harald Welte