this change is mainly relevant for the SIMtrace board, but also
affects the others.
First we ensure VCC_PHONE is not forwarded to VCC_SIM because the
card could affect the signal (card could draw too much current or
feed back current in).
next we disable VCC_SIM. the card slot does not need to be
powered, and the FPF2019 leaks current back to VCC_PHONE, even
with forwarding disabled (the reverse current protection only
kicks in when VCC_PHONE is briefly shorted to ground, but still
leaks 0.6V).
enable the ADC channels normally used to measure VCC, even if
not used. the dedicated ADC pins leak current when left
unconfigured. enabling them puts them in high impedance.
Change-Id: If1487c1c191838aaa08b654e49cd31c7180ffc19
XX pin reconfig
Change-Id: Ib261073e3779ae7d98de18ce78b34ff37eafeaa2
the reset/ATR handling has been heavily updated/fixed.
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 the
clock signal is not connected to the timer counter.
thus this change adds card emulation support for SIMtrace boards.
Fi and Di have been properly rename to F and D since the "i"
stands only for an "indicated" value, not the actual value.
this does not change the USB protocol (the variable have just been
renamed).
additional variables store more information about the card
capabilities
NOTE: it has only be tested for the SIMtrace board
Change-Id: Ibcb2c8cace9137695adf5fb3de43566f7cfb93b5
the simtrace board uses a bus switch not used on qmod and owhw to
switch the SIM between physical and virtual
Change-Id: Ieaf2ed4761fc3e04f33f9aac5c04a768c9a6f71e
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
This helps when debugging the firmware, as it shows the current
utliization of the 10-msgb-talloc pool.
Change-Id: Ib10c4396cd4c9c4a6257cf45886e367214787927
Related: OS#4251
As of Change-Id I1c8cca2f7f0f0070d7bf1ade676e035c45e4d5ab, a firmware
compiled without ALLOW_PEER_ERASE will not support resetting the hub or
writing to its EEPROM. Let's make sure to remove those options also
from the menu.
Change-Id: I3071332d85e6168947384ddc230298d3293e4668
now both partitions (bootloader and application) use a commonly
defined memory location to shared the DFU state (which includes
the magic value to know which part to start), instead of using
a hard coded value.
the bootloader size has now also been restricted to 16 kB.
this limitation is enforced so to not be able to create larger
images, which could be corrupted when flashing the application.
bootloader and application flashing have been successfully tested
on qmod st12 and st34.
Change-Id: I204bed7e9391602672ed894decec1fc12e879275
"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
The code in board_main_top() for QMOD blindly re-assigned some
members of the usb_strings[] array, writing to index 7 and 8.
However, that array only has those entries in the main firmware,
while in DFU that array has only 6 entries. Depending on whatever
the linker has decided to put in the next memory location after
that array, we would overwrite that very early during boot-up.
Change-Id: I59e4e1a54e819808d5a8259a6d14f4b970a90020
Related: OS#4302
monitoring the state changes of the VCC and nRST lines is required
to correctly detect warm and cold reset
Change-Id: I72099956332724f84226e1495fdc5a5b1a034695
in case flashing the main application firmware using DFU failed,
the main application might be broken and not allow to switch again
to DFU mode to re-flash it correctly.
the other board have a way to force entering (e.g. staying in) the
bootloader using an external signal (e.g. a switch on the SIMtrace
board).
the OWHW DFU firmware did not have this functionality implemented.
the design (e.g. schematic) already has the SIMTRACE_BOOTLOADER
signal (on PA31) for this purpose.
now the DFU bootloader will start the DFU mode when the
SIMTRACE_BOOTLOADER is high.
this change has been tested on OWHWv2.
Change-Id: Iefff51a811ad0f3bf3a46b8e256b905d11344bea
the OctSIM tester has only one amber LED.
this is now mapped to the normally green LED, used for activity.
because the LED is driven by an NPN transistor (as open collector)
instead of being directly connected to the pin (as open collector)
like on the other boards, the logic is inverted.
since normally the LED is on on idle and blinks during activity,
it will now be off on idle an only blink on activity (unless the
code is extended to cope with the possible inverted logic).
because there is no second LED but the current code requires one,
I mapped is to an unused pin.
the octosimtest target still does not compile completely, but at
least the LED issue is fixed.
Change-Id: I1296833bef2804c611640fcf4756e47905660e7b
the LEDs (2 of them) were connected to the same pins on all
boards, up to the octsim-tester.
to be able to have board specific LEDs the definitions have moved
from common to the each board.
at the same time I added a bit of documentation what the LEDs are
used for.
Change-Id: I3226a9187a8d0b657ccf5dcd8f3586b2578f96d2
SIM_PWEN and VCC_FWD are signals specific to the simtrace boards.
the corresponding pins PA5 and PA26 are used for other signal
on the octsim-tester.
Change-Id: I51f37dd112cf681f4b1dbb3d2320ff9a697eaa08
disabling the ERASE pin prevents accidental erase for the flash
memory while the board is powered on (e.g. in case the user
overcomes the weak 100 kOhm pull-down for more than 220 ms by
touching or shorting the pin).
the flash is still erasable using the ERASE pin during power up.
it is only disabled after boot completed.
Change-Id: Ic3332eb1d4247a07988b2fd841f40e79862d06a7
We recently introduced ALLOW_PEER_ERASE to control if the firmware
should contain code for the SAM3 to reset each other on QMOD.
Let's use the same define to also remove code for putting the USB
hub into reset as well as code for erasing + writing the hub EEPROM.
This is needed only during production, but it shouldn't be enabled
during normal operation of the product at the end user.
Change-Id: I1c8cca2f7f0f0070d7bf1ade676e035c45e4d5ab
adds command 'a' to allow setting/asserting the peer SAM3S ERASE
line on the next command.
this prevents against accidental erase since only the command 'y'
was required, without confirmation.
this could happen not only through accidental user input, but
noise on the serial line (noise would still cause other issues,
but at least now it will not "brick" the device).
now the sequence 'ay' is required, as any other command following
'a' would clear the permission again.
note: since ERASE is only setting a GPIO within this command
parsing function, not accidental function pointer problem calling
'board_exec_dbg_cmd' should cause accidental ERASE since it would
need to be called two times with the exact sequence
Change-Id: I06bfeaef09a397bd554bec84321e0dd64ccc3aac
This is a general purpose evaluation board, and it makes sense to
support it particularly for the DFU bootloader.
Change-Id: I85aea8f1441158f991493c5fc767fdcad405545e
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 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
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
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
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
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 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
when building the trace app for the simtrace board gcc was outputing
the following error:
libboard/common/source/boardver_adc.c:20:17: warning: 'adc2uv' defined but not used [-Wunused-function]
static uint32_t adc2uv(uint16_t adc)
adc2uv is used by qmod, and defined in two places:
in boardver_adc.c and mode_cardemu.c.
this change will have adc2uv only defined in boardver_adc.c and make
available in the header to be used by mode_cardemu.c.
Change-Id: I8a772638fa8dd02d8bc8b7631de5af5a22647c55
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
The qmod does not have a separate force button as simtrace has.
Instead it check is TX and RX of UART are shorted using PIO.
If the pins are not set back to the UART peripheral, the TRACE/debug
console output will not work anymore.
Change-Id: Id434b49909d6395a2f93a00f39d2d770a5725466
The DFU uses the UART peripheral (with IRQ/ISR) for the debug output
console. Before starting the main application we should make sure
this configuration is reset to avoid interference (particularly the
IRQ/ISR).
This is not too important though since the main application
reconfigures the UART for console output.
Other peripheral could also be disabled (e.g. all other PIO used
by DFU), but most of them also get configured by the main application.
Change-Id: I8234d1b85938ad6393094c08183f613ad09ee01b
