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
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
Each board can define its own conditions on which the controller should
boot into DFU mode rather than normal application mode. Let's move the
"UART loopback jumper" to QMOD specific part. For SIMtrace we have an
actual button and can use that in a future patch.
This was introduced for interoperability with operating systems that
might prefer such setup (I heard that Windows prefers this about a
decade ago, but I don't have any personal experience with it).
However, using different VID/PID between DFU and RT breaks usability of
dfu-util, and I really think this matters much more to our users and
developers.
* we now actually route the EP0 control requests in DFU mode to the
correct handler (weak linker symbols are tricky)
* we now actually call code to read/write data from/to RAM/FLASH
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).
