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.
