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 :(
We need to refer to g_dfu as a pointer from all code. In DFU mode, it
gets assigned to the address of _g_dfu, which is placed by the linker
script at the start of RAM. In runtime mode, the pointer is statically
defined to point at the start of RAM. The linker script for the runtime
(dfu environment) is adjusted to save the first 32 bytes for the _g_dfu
structure.
* 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).
The signals are driving an external NPN transistor, so the default state
must be low at reset to en sure that !PERST on the modem input is
de-asserted by default.
It seems like a lot of modems have rather long (100ms!) minimum reset
durations. Makes me wonder if it's an actual reset line or rather juts
some GPIO that they poll/sample every so often. Then there are other
modems that state the reset *must not* be longer than 1s. So let's
choose 300ms as a value in-between.
The PLL setting doesn't depend on the 'qmod' board type but on the
combination of the BOARD_MAINOSC and BOARD_MCK #defines. So let's
remove the '#ifdef qmod' from the equation.
The only 'qmod' specific part is whether or not to use the internal xtal
oscillator or not.
Table 42-31 ofd DOC6500 states that the minimum output frequency of the
PLL is 60 MHz. The existing qmod code violated this by configuring the
PLL multiplier output to 12*4 = 48 MHz. Let's use 12*8 = 96 and then
divide that by two to get to the desired 48 MHz.
This might help to resolve the non-working USB on the qmod so far.
* move it out of the function so it actually is present in .rodata,
rather than having a long sequence of stores into a stack buffer
* use 16 bytes per line so it is easier to find + change bits in there
The firmware we used for testing contained some local changes which were
not committed. They primarily relate to the port re-ordering feature as
well as the amount of power (0x32 = 100mA) is now used consequently.
When we reset the hub, the hub will actively drvie the PRTPWR signal of
the SITMRACE12 low, resulting in the SAM3 being shut off. If we want to
"survive" this, we need to set the OVERRIDE before we go into reset.
Right now, we never release the signal again, keeping ST12 enabled
permanently, which is of course not what we want in general.
You can compile the firmware for this new target using 'make
BOARD=qmod'.
The QMOD differs from simtrace+owhw in terms of low-level
initialization, as it has an external 12MHz clock at XIN, thus bypasses
the main oscillator and needs different PLL configuration.
At higher speeds, it seems we are turning off the transmitter before we
are enabling the receiver. Unfortunately the TXEN bit in the uart mode
register is read-only, so we don't really know if the transmitter is
enabled or not. It seems we can simply keep transmitter + reciver
running at the same time, and use the TXEMPTY bit as reliable means to
determine if we're busy transmtting.
We can now enable CARDEMU_SECOND_UART in owhw/board.h, as it no
longer interferes with operation of the first port (USIM1). Whether
the second port actuall works still remains to be tested at this point.
We now auto-discover the end-point addresses based on the interface
descriptor. The user can also use the new "--interface" command line
argument to set a non-zero intrerface. In combination, this should
enable support for the remote-sim functionality on the second UART
on OWHW.
UDP end-points are streams, so when we receive data on the OUT
endpoint callback, the buffer might contain several commands. When
dispatching the messages, split (segment) them again before dispatching
them to their respective handlers.
we want to ensure that the length of every (current or future) message
can be determined by looking at cardemu_usb_msg_hdr.msg_len, rather than
having a length that is relative to the respective specific command.
Harald Welte