In order to be fast, the reset_handler() function uses word accesses to
initialize the .data output section. However, most toolchains do not
automatically force the alignment of an output section LMA to use the
maximum alignment of all its input sections. Because of that, assuming
that .data contains some words, the LMA of the .data output section was
not word-aligned in some cases, resulting in an initialization performed
using slow unaligned word accesses.
This commit forces the alignment of the LMA of the .data output section
with a word boundary in order to always use fast aligned word accesses
to read the .data load area.
Note that this solution is better than using ALIGN_WITH_INPUT, both
because the latter is a new feature incompatible with older toolchains,
and because it could create a big gap between _etext and the LMA of
.data if strongly-aligned data were added to .data, although only a word
alignment is required here.
The same considerations apply to the VMA of .data. However, it is
already automatically word-aligned, both because .data contains words,
and because the end VMA of the previous output section (.socdata) is
word-aligned. Moreover, if the VMA of .data were forcibly word-aligned,
then a filled gap could appear at the beginning of this section if
strongly-aligned data were added to it, thus wasting flash memory.
Consequently, it's better not to change anything for the VMA of .data,
all the more it's very unlikely that it does not contain any word and
that the end VMA of .socdata becomes non-word-aligned, and this would
only result in a slower initialization.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Some toolchains, like Sourcery CodeBench Lite 2013.05-23 arm-none-eabi
(http://sourcery.mentor.com/public/gnu_toolchain/arm-none-eabi/)
automatically force the alignment of an output section LMA to use the
maximum alignment of all its input sections. This toolchain uses GNU
binutils 2.23, and this automatic behavior is the same as the manual
behavior of the ALIGN_WITH_INPUT feature of GNU binutils 2.24+.
This behavior is not an issue per se, but it creates a gap between
_etext and the LMA of the .data output section if _etext does not have
the same alignment, while reset_handler() initialized this section by
copying the data from _etext to its VMA, hence an offset in the
addresses of loaded data, and missing data.
This commit fixes this issue by making reset_handler() directly use the
LMA of the .data section using LOADADDR(.data), rather than assuming
that _etext is this LMA.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
* Only enable TX by default.
* Add some magic for RX handling. When an input handler is registered:
* Automatically enable RX-related and interrupts
* Automatically lock the SERIAL PD on under all power modes
* Automatically enable the UART clock under sleep and deep sleep
* Automatically undo all of the above when the input handler becomes NULL
* As a result, modules / examples that need UART RX no longer need to clock the UART and manipulate the SERIAL PD. They simply have to specify an input handler
* Don't automatically power on the UART whenever the CM3 is active
* Before accessing the UART, make sure it is powered and clocked
* Avoid falling edge glitches
* Fix garbage characters / Explicitly wait for UART TX to complete
* Implement new style of PD locks
* Use our own shutdown sequence rather than the one provided by cc26xxware
* Shutdown from within the interrupt that requested it. This allows shutdown to take place even if the code is stuck in a loop somewhere else
* Improve DCDC/GLDO/uLDO switching logic
* Explicitly handle oscillators and retentions
Instead of using a separate data structure to request that a PD remain powered during deep sleep,
we do the same within the main LPM data structure through an additional field.
This allows us to maintain only one linked list of LPM modules and overall improves code clarity
This tutorial was written for the older implementation of CoAP, and
while it may be possible to update it, the directions include URLs and
repos that no longer exist, so it's better to just remove it.
Only the interrupt flags that have been handled must be cleared.
Otherwise, if a new interrupt occurs after the interrupt statuses are
read and before they are cleared, then it is discarded without having
been handled. This issue was particularly likely with two interrupt
trigger conditions occurring on different pins of the same port in a
short period of time.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Power-up interrupts do not always update the regular interrupt status.
Because of that, in order not to miss power-up interrupts, the ISR must
handle both the regular and the power-up interrupt statuses.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Introduce new useful GPIO macros to:
- get the raw interrupt status of a port,
- get the masked interrupt status of a port,
- get the power-up interrupt status of a port.
These macros are cleaner and less error-prone than raw register access
code copied all over the place.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Behave just like the CS8900A driver: Both the CS8900A and the LAN91C96 dynamically share a buffer for received packets and packets to be send. If the chip is exposed to a network with a lot of broadcasts the shared buffer might fill quicker with received packets than the 6502 reads them (via polling). So we might need to drop some received packets in order to be able to send anything at all.
OR-ing an offset to a base address instead of adding it is dangerous
because it can only work if the base address is aligned enough for the
offset.
Moreover, if the base address or the offset has a value unknown at
compile time, then the assembly instructions dedicated to 'base +
offset' addressing on most CPUs can't be emitted by the compiler because
this would require the alignment of the base address against the offset
to be known in order to optimize 'base | offset' into 'base + offset'.
In that case, the compiler has to emit more instructions in order to
compute 'base | offset' on most CPUs, e.g. on ARM, which means larger
binary size and slower execution.
Hence, replace all occurrences of 'base | offset' with 'base + offset'.
This must become a coding rule.
Here are the results for the cc2538-demo example:
- Compilation of uart_init():
* before:
REG(regs->base | UART_CC) = 0;
200b78: f446 637c orr.w r3, r6, #4032 ; 0xfc0
200b7c: f043 0308 orr.w r3, r3, #8
200b80: 2200 movs r2, #0
200b82: 601a str r2, [r3, #0]
* now:
REG(regs->base + UART_CC) = 0;
200b7a: 2300 movs r3, #0
200b7c: f8c4 3fc8 str.w r3, [r4, #4040] ; 0xfc8
- Size of the .text section:
* before: 0x4c7c
* now: 0x4c28
* saved: 84 bytes
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Modified the if/elseif/elseif/.../else block in ISR into multiple if
blocks in order to handle multiple interrupts happening simultaneously.
Signed-off-by: Joakim Gebart <joakim.gebart@eistec.se>
Currently there is an linker error when compiling with debug information.
This is only the case for dwarf (the default). Everything is fine with
stabs, thus allowing to debug and use all the other nice tools like
"objdump -S".
Since avr-libc 1.8.0 MCUSR is marked as poison as it was replaced by the
correct name MCUCSR.
Thus code still using the old MCUSR name does not compile anymore.
This commit replaces usages of former MCUSR by its new name MCUCSR and
modifies the alias fallback accordingly.
The border-router tries to transmit and do other stuff after turning
the radio off, and the radio driver didn't handle that very well.
With this fix, it's no longer necessary to reset the border router
after starting tunslip6.
The previous chip detection was inspired by the old IP65 driver code. For some reason it didn't work as expected. The new code is simpler and based on this statement in the chip datasheet: "The upper byte always reads as 33h and can be used to help determine the I/O location of the LAN91C96."
The problem with the current version of the code was that the condition at the end of the do...while loop at Timer A1 interrupt:
while((TACCR1 - TAR) > INTERVAL);
evaluates to false whenever TACCR1 == TAR.
Not incrementing TACCR1 in this case leads to Timer A1 interrupt not being called for 2 seconds, until TAR counter reaches TACCR1 again after an overflow.
The patch avoids this problem by changing the condition of the loop, and using CLOCK_LT macro to compare between time values.
The patch also attempts to fix another problem: a read of TAR register while it is being updated may return a lower value than the actual contents. To avoid that, the "read twice and compare results" idiom should be used. As the TAR register is updated by the actual hardware, it is of no importance whether it is read with interrupts disabled or enabled; the problem can occur in both contexts.
Made Ethernet drivers easier to consume by assembly programs.
* Replaced function pointers with JMP instructions.
* Provide return values additionally via Carry flag.
Reset Ethernet chips on initialization.
Both for the CS8900A and the W5100 the data sheets just say that
the RESET bit is automatically cleared after the RESET. This may
be interpreted in two ways:
1) There's no need to be afraid of reading the RESET bit as 1 and
unintentionally trigger a RESET by writing it back after ORing in
some other bit.
2) The RESET process isn't complete before the RESET bit hasn't
become 0 again.
It's impossible for me to empirically falsify the latter option
as the drivers are supposed to work on faster machines than the
ones I have access to. And if the RESET process includes things
like oscillators then the time to complete the RESET could differ
even between multiple exemplars of the same chip. Therefore I
opted to presume the latter option.
However that means a non-exsistent chip may cause an infinite
loop while waiting for the RESET bit to be cleared so I finally
added code to detect the presence of the Ethernet chips. There's
a risk of a chip being locked up in a way that makes the detection
fail - and therefore the RESET not being performed. This catch-22
needs to be solved by the user doing a hard RESET.
