Coffee is placed by default at the beginning of the flash memory, right
before the firmware. This avoids the memory gaps that there could be
before and after Coffee if it were placed after the firmware, because it
is unlikely that the end of the firmware is aligned with a flash page
boundary, and the CCA is not flash-page-aligned. Thanks to that, Coffee
is also always in the same flash area if its size remains unchanged,
even if the firmware changes, which makes it possible to keep the Coffee
files when reprogramming the firmware after a partial flash erase
command.
The default configuration of Coffee is set to use sensible values for a
typical usage on this SoC, i.e. for sensor data logging.
The default size of Coffee is set to 0 in order not to waste flash if
Coffee is unused.
COFFEE_CONF_CUSTOM_PORT can be defined to a header file to be used with
"#include" in order to override the default CC2538 port of Coffee. This
makes it possible to use Coffee with an external memory device rather
than with the internal flash memory, without having to alter the Contiki
files.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
No entry point was defined, so it defaulted to the beginning of the
.text output section where the vector table is located by default in
Contiki. Actually, the vector table may be located elsewhere, and the
ROM-based boot loader first reads the CCA to find the vector table.
Consequently, this commit sets the entry point to the CCA, which fixes
both the entry point and the initial symbol reference, so this commit
also removes the now-unneeded "__used__" and "KEEP" keywords from the
CCA.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
The current CC2538 linker script in Contiki places the vector table at
the beginning of the flash memory / .text output section. However, this
location is arbitrary (the only requirement is that the vector table is
512-byte aligned), and custom linker scripts may be used with Contiki,
which means that Contiki may be used with a vector table placed
elsewhere. Thus, using the flash/.text start address in the CCA and as
the default NVIC VTABLE value was wrong.
This commit rather uses the address of the vectors[] array from
startup-gcc.c, which makes it possible to freely move around the vector
table without breaking anything or having to use a custom startup-gcc.c
and to configure the NVIC driver for that. Moreover, referencing the
vectors[] array naturally prevents it and its input section from being
garbage-collected by the linker, so this commit also removes the
now-unneeded "used" and "KEEP" keywords from the vector table.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
The only thing needed for VTABLE is the absolute address of the vector
table. Splitting it between code/SRAM base and offset complicates things
and brings nothing.
Consequently, this commit merges the NVIC VTABLE configurations into a
single one giving the vector table absolute address.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Define the flash memory page and word sizes. These definitions are
grouped with the flash lock bit page and CCA definitions, so flash-cca.h
is renamed to flash.h.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Define the available CC2538 devices and their features, and use them to
define the linker script memory regions. The .nrdata output section is
now always defined in order to trigger an error if it is used but no
memory is available for it. The CC2538 device used by Contiki is made a
configuration option, the CC2538SF53 device being the default.
This makes more sense than defining the flash memory address and size as
configuration options like previously, all the more not all values are
possible and all the features are linked by each device.
This change also makes it possible to:
- use the correct SRAM parameters for the CC2538NF11,
- know at build time if the AES, SHA, ECC and RSA hardware features are
available on the selected CC2538 device.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
CC_FASTCALL was introduced many years ago for the cc65 tool chain. It was never used for another tool chain. With a798b1d648 the cc65 tool chain doesn't need CC_FASTCALL anymore.
So far 80 column display was an attribute of a cc65 platform. Now each cc65 application can ask for 80 column display by defining WITH_80COL. Of course this is ignored by platforms incapable of 80 column display.
I see three types of application:
* Applications not benefitting from 80 column at all and in fact looking better with 40 column display. These are now using 40 column display. Examples: ethconfig, ipconfig
* Applications taking advantage of 80 column display if it is available without drawbacks. These stay as they were. Examples: Telnet server, web server, wget
* Applications needing 80 column display so urgently that it is likely desirable even if the display becomes harder to read. These come now in both flavors allowing the user to choose. Examples: IRC, web browser
Note: This change doesn't actually introduce any 80 column display with drawbacks. This if left to a subsequent change.
