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
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 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
The stack size is fixed. The linker script puts the stack section
after the bss section. The initial stack pointer is not at the
end of the RAM (as often seen).
Thus the initial stack pointer address of the main application
is different than the one from DFU. When starting the main
application the stack pointer needs to be set to the new value.
If this is not done the main application stack may overwrite the
data in bss, even without exceeding the fixed stack size.
Change-Id: Ie354d603fe302d3d5bdfa9c31575411de722323b
In the SIMtrace and QMOD schematics the LEDs are connected to +3.3V.
Thus to switch the LED on we need to set the pin low.
Change-Id: Id8cc27e6f0b6556ba5e7ea4d254dd0fe59042a0c
don't wait for space to be available in the buffer since since would
prevent from processing non-console (e.g. debug) more important data
Change-Id: Ia625b09eb30bb7b43edd3989f697d8ef33200f28
fixes following warning:
libboard/common/source/board_cstartup_gnu.c:137:11: warning: assignment to 'void (*)(void)' from 'unsigned int' makes pointer from integer without a cast [-Wint-conversion]
appReset = pSrc[1];
The original board startup script is provided by Atmel.
It has been modified to handle application or DFU booting.
The copyright notice has been updated to reflect this change.
The logic to detect if the respective module is already initialized
or not was broken. When performing initialization, we of course need
to set initialized=1.
Using the USBDFU_OverrideEnterDFU() function, a board/application can
define extra conditions when the system should boot in DFU mode, even if
it was not explicitly switched to DFU mode from the application.
The app/dfu/main.c uses this mechanism to boot into DFU mode if the
stack + reset vector addresses are not plausible (i.e. some random junk
appears to be flashed in the application partition) or if the user
places a jumper accross the RxD+TxD lines of the debug UART. The idea
is that the system can be recovered by placing this jumper and then
re-installing the application from DFU.
Sometimes there is some leakage current via some I/O that's sufficient
to power up the SAM3S. Use the supply monitor to make sure the CPU
will be reset (and kept in reset) if the supply voltage is below 3.0V.
It is utterly unacceptable that Atmel is shipping example code in 2011,
which doesn't support parts that are shipped still in 2016. They would
have had five years to fix their code to implement the chip errata :(
This way we can easily check with 'diff' for differences in our code and
Atmel softpack. Also, this layout is more suitable for building various
different firmware images (e.g. factory-test, dfu-loader, main
application) for a variety of different boards (simtrace, owhw, qmod).
