This change adds the following improvements:
- Increase the allowed SPI-Frequency from 20 to 40 MHz.
- Correct and rename the "VARSELECT" option This option was included in the code as "CONFIG_SPI_VARSELECT" but nowhere defined in a Kconfig file. The patch renames it to "CONFIG_SAMV7_SPI_VARSELECT" and corrects the implementation according the datasheet of Atmel. In short, this option switches the processor from "fixed peripheral selection" (single device) to "variable peripheral selection" (multiple devices on the bus).
- Add a new Function to the interface to control the timing and delays of the chip according the ChipSelect lines. This function can control the delay between the assertion of the ChipSelect and the first bit, between the last bit and the de-assertion of the ChipSelect and between two ChipSelects. This is needed to tune the transfer according the specification of the connected devices.
- Add three "hw-features" for the SAMV7, which controls the behavior of the ChipSelect:
1. force CS inactive after transfer: this forces a (short) de-assertion of the CS after a transfer, even if more data is
available in time
2. force CS active after transfer: this forces the CS to stay active after a transfer, even if the chip runs out of data. Btw.: this is a prerequisit to make the LASTXFER bit working at all.
- escape LASTXFER: this suppresses the LASTXFER bit at the end of the next transfer. The "escape"-Flag is reset automatically.
The High Gain bit in MCG_C1 was preventing teensy from booting
except after a programming session. The second change doesn't appear
to change any functionality, but complies with restrictions in the k20
family reference manual on FEI -> FBE clock transiions.
"This is a fix to a problem in the handling of the oneshot timer. Due to a wrong assumption concerning the behavior directly after the start of the timer/counter the function sam_oneshot_cancel(…) calculates the wrong remaining time. The code assumes that the counter register is zero directly after the start of the timer, but this is not true. To start the time/counter a software trigger is invoked, this trigger starts the timer/count and sets the counter register to zero, but the reset of the counter register is not performed instantly. According to the datasheet: “The counter can be reset by a trigger. In this case, the counter value passes to zero on the next valid edge of the selected clock.” Thus the counter is set to zero between 0 and USEC_PER_TICK microseconds after the clock was started.
"In my fix I use the freerun count value to determine if at least one tick passed since the start of the timer and thus if the value of the oneshot counter is correct. I also tried to use the function up_timer_gettime(…) to achieve this but, at least if compiled with no optimization the problem vanishes without using the value of the function, the function call takes too long.
"Another problem treated in the fix is that if the oneshot timer/counter is canceled, we only know the remaining time with a precision of USEC_PER_TICK microseconds. This means the calculated remaining time is between 0 and USEC_PER_TICK microseconds too long. To fix this I subtract one tick if the calculated remaining time is greater than one tick and otherwise set the remaining time to zero. By doing so the measured times are much more precise as without it."
"This is a fix to a problem in the handling of the oneshot timer. Due to a wrong assumption concerning the behavior directly after the start of the timer/counter the function sam_oneshot_cancel(…) calculates the wrong remaining time. The code assumes that the counter register is zero directly after the start of the timer, but this is not true. To start the time/counter a software trigger is invoked, this trigger starts the timer/count and sets the counter register to zero, but the reset of the counter register is not performed instantly. According to the datasheet: “The counter can be reset by a trigger. In this case, the counter value passes to zero on the next valid edge of the selected clock.” Thus the counter is set to zero between 0 and USEC_PER_TICK microseconds after the clock was started.
"In my fix I use the freerun count value to determine if at least one tick passed since the start of the timer and thus if the value of the oneshot counter is correct. I also tried to use the function up_timer_gettime(…) to achieve this but, at least if compiled with no optimization the problem vanishes without using the value of the function, the function call takes too long.
"Another problem treated in the fix is that if the oneshot timer/counter is canceled, we only know the remaining time with a precision of USEC_PER_TICK microseconds. This means the calculated remaining time is between 0 and USEC_PER_TICK microseconds too long. To fix this I subtract one tick if the calculated remaining time is greater than one tick and otherwise set the remaining time to zero. By doing so the measured times are much more precise as without it."
In my fix I use the freerun count value to determine if at least one tick passed since the start of the timer and thus if the value of the oneshot counter is correct. I also tried to use the function up_timer_gettime(…) to achieve this but, at least if compiled with no optimization the problem vanishes without using the value of the function, the function call takes too long.
Another problem treated in the fix is that if the oneshot timer/counter is canceled, we only know the remaining time with a precision of USEC_PER_TICK microseconds. This means the calculated remaining time is between 0 and USEC_PER_TICK microseconds too long. To fix this I subtract one tick if the calculated remaining time is greater than one tick and otherwise set the remaining time to zero. By doing so the measured times are much more precise as without it.
This fix removes the disabling of the whole USB peripheral on suspend
interrupt. Its enough to freeze the clock instead.
When disabling the whole peripheral, the next wakeup-interrupt comes
up with an disabled clocking. The unfreeze clock has no effect, because
the master clock is disabled. This makes all registers, including the
IDR unwriteable and the IRQ falls in an endless loop blocking the whole
system.
Furthermore the disabling of the peripheral clock prevents hotplugging
or reconnecting the USB.
sam_i2cbus_initialize
sam_i2cbus_uninitialize
sam_i2cbus_initialize
Or twi_reset is called.
I found this a while back in the stm32 family, so there may be more arch-es with this sort of bug. I suppose any driver that has the notion of "do not set the freq if it is already set" could be suspect.
-------
This patch enhances networking support for the simulation under Linux.
Includes updated support for Linux TUN/TAP, and the addition of support for
Linux bridge devices.
CHANGES
-------
o Check to see if the d_txavail callback is present before calling it in
the arp send code. This prevents a segfault when simulating the telnetd
daemon with arp send enabled.
o Adjust the simulation's netdriver_loop() so it will detect and respond to
ARP requests.
o Do not attempt to take the tap device's hardware address for use by the
simulation. That hardware address belongs to the host end of the link,
not the simulation end. Generate a randomized MAC address instead.
o Do not assign an IP address to the interface on the host side of the TAP
link.
+ Provide two modes: "host route" and "bridge".
+ In host route mode, maintain a host route that points any traffic for the
simulation's IP address to the tap device. In this mode, so long as the
simulation's IP is a free address in the same subnet as the host, no
additional configuration will be required to talk to it from the host.
Note that address changes are handled automatically if they follow the
rule of if-down/set-address/if-up, which everything seems to.
+ In bridge mode, add the tap device to the specified bridge instance. See
configs/sim/NETWORK-LINUX.txt for information and usage examples. This
enables much more flexible configurations (with fewer headaches), such as
running multiple simulations on a single host, all of which can access
the network the host is connected to.
o Refresh configurations in configs/sim where CONFIG_NET=y. They default
to "host route" mode.
o Add configs/sim/NETWORK-LINUX.txt
CAVEATS
-------
- The MAC address generation code is extremely simplistic, and does not
check for potential conflicts on the network. Probably not an issue, but
something to be aware of.
- I was careful to leave it in a state where Cygwin/pcap should still work,
but I don't have a Windows environment to test in. This should be
checked.
- I don't know if this was ever intended to work with OS X. I didn't even
try to test it there.
NOTES
-----
- Was able to get telnetd working and simulate nsh over telnet, but only so
long as listen backlogs were disabled.
There appears to be a bug in the backlog code where sockets are being
returned in SYN_RCVD state instead of waiting until they're ESTABLISHED;
if you perform an immediate send after accepting the connection, it will
confuse the stack and the send will hang; additionally, the connection
will never reach ESTABLISHED state.
Can be worked around by adding a sleep(1) after the accept in telnetd. I
don't have the necessary knowledge of the IP stack to know what the
correct fix is.
• SYSIO4: PB4 or TDI Assignment
0: TDI function selected.
1: PB4 function selected.
• SYSIO5: PB5 or TDO/TRACESWO Assignment
0: TDO/TRACESWO function selected.
1: PB5 function selected.
• SYSIO6: PB6 or TMS/SWDIO Assignment
0: TMS/SWDIO function selected.
1: PB6 function selected.
• SYSIO7: PB7 or TCK/SWCLK Assignment
0: TCK/SWCLK function selected.
1: PB7 function selected.
• SYSIO12: PB12 or ERASE Assignment
0: ERASE function selected.
1: PB12 function selected.
The thing I did not add is warning or compilation failure, (to save the next guy the hassle), at ALL the driver points that uses the these pins.
I did remove this
/* To use the USART1 as an USART, the SYSIO Pin4 must be bound to PB4
* instead of TDI
*/
uint32_t sysioreg = getreg32(SAM_MATRIX_CCFG_SYSIO);
sysioreg |= MATRIX_CCFG_SYSIO_SYSIO4;
putreg32(sysioreg, SAM_MATRIX_CCFG_SYSIO);
in sam_lowputc.c in favor of an #error - because the default is an input TDI and driving it blindly to an output TXD1, would be a contention.
use INITS flag to avoid magic reg value to detect power up reset state of rtc
correct a problem clearing interrupt flags (they weren't) which prevented an alarm from ever being used more than once per reset cycle
Error is only triggered if the global variable g_mcan0_msgram is located in RAM at an address beyond 0x20400000 + 0x0000ffff. In this case all send CAN messages have the length zero and the CAN-ID is zero as well.
