Create a dedicated header file with all the definitions for the flash lock bit
page and customer configuration area. This avoids duplicating those definitions
in the startup-gcc.c files of all CC2538-based platforms, and this also allows
to easily manipulate the CCA from outside startup-gcc.c (e.g. for on-the-air
firmware update).
The definitions are now complete contrary to what was in startup-gcc.c:
- Definitions have been added to select the bootloader backdoor pin and active
level if enabled.
- Definitions have been added to access the page and debug lock bits. The debug
lock bit can be used to prevent someone from reading back a programmed
firmware through JTAG if the firmware binary image has to be confidential,
which should be combined with a disabled bootloader backdoor.
- The application entry point is now tied to the beginning of the .text section
instead of to the beginning of the flash. This allows projects using custom
linker scripts to place the application entry point anywhere in the flash,
which can be useful e.g. for on-the-air firmware update.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
It cannot be ruled out that access to the address register triggers
an address auto-increment. Therefore a temporary address register
shadow is introduced to replace the access to the address regsiter.
Additionally there are several minor beautifications.
The pending GPIO power-up interrupts have to be cleared in the ISRs in order not
to re-trigger the interrupts and the wake-up events.
The power-up interrupts of all pins are cleared for each port in the
corresponding port ISR. This is done after calling the registered callbacks so
that the callbacks can know which pin woke up the SoC. This is done after
clearing the regular interrupt in order to avoid getting a new wake-up interrupt
without the regular interrupt in the case of a new wake-up edge occurring
between the two clears.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
The GPIO power-up interrupts have to be configured and enabled in order to be
able to wake-up the SoC from PM1+ upon a signal edge occurring on a GPIO input
pin.
This set of macros allows to:
- configure the signal edge triggering a power-up interrupt,
- enable and disable a power-up interrupt,
- clear a power-up interrupt flag.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
If PM2 is enabled with LPM_CONF_MAX_PM, but not active, the non-retention area
of the SRAM can be useful to place temporary data that does not fit in the
low-leakage SRAM, typically after having called lpm_set_max_pm(LPM_PM1). Hence,
give access to this non-retention area thanks to .nrdata* sections.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
The data sheet recommends that the USB pull-up resistor be driven by a GPIO so
that it can be controlled by software, but this is not mandatory. Hence, leave
the choice so that CC253-based boards not using this option can build and work
fine.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Homogenize port and pin definitions naming:
- PERIPHERAL_FUNCTION_PORT for the port ID,
- PERIPHERAL_FUNCTION_PIN for the pin ID,
- PERIPHERAL_FUNCTION_PORT_BASE for the port base,
- PERIPHERAL_FUNCTION_PIN_MASK for the pin mask.
Define only PERIPHERAL_FUNCTION_PORT and PERIPHERAL_FUNCTION_PIN in board.h, and
deduce PERIPHERAL_FUNCTION_PORT_BASE and PERIPHERAL_FUNCTION_PIN_MASK in the
driver from the former definitions.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Use the GPIO accessor macros instead of copying raw register access code all
over the place. This is cleaner and less error prone.
This fixes the setting of the USB pull-up resistor that worked only by chance on
the CC2538DK because it is controlled by the pin 0 of the used GPIO port.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Introduce new useful GPIO macros to:
- read the levels of some port pins,
- write the levels of some port pins (pass bit-field value to be set),
- clear the interrupt flags for some port pins.
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@advansee.com>
The parameters in the GPIO macros were used without being parenthesized. This
could generate wrong values for register assignments in the case of expressions
passed as arguments to these macros.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
lpm_enter() must not enter PM1+ if the UART TX FIFO is not empty. Otherwise, the
UART clock gets disabled, and its TX is broken.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Some peripherals have their clocks automatically gated in PM1+ modes, so they
cannot operate. This new mechanism gives peripherals a way to prohibit PM1+
modes so that they can properly complete their current operations before
entering PM1+.
This mechanism is implemented with peripheral functions registered to the LPM
module. These functions return whether the associated peripheral permits or not
PM1+ modes. They are called by the LPM module each time PM1+ might be possible.
If any of the peripherals wants to block PM1+, then the system is only dropped
to PM0.
Partly from: George Oikonomou
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
spi-arch.h configures dev/spi.h, so it must be #included first. Luckily, this
mistake did not have any consequence here, but fix it in order to avoid possible
future issues.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
If the SSI has never been used and spi_init() is called, then the SSI receive
FIFO is empty and remains so, so calling SPI_WAITFOREORx() at the end of
spi_init() waits endlessly for SSI_SR.RNE to be set. Hence, this call must be
removed in order to avoid a deadlock.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
ELF files generated by GCC make SmartRF Flash Programmer 2 crash (only the TI
format is supported by this tool for ELFs), and binary files are not very
appropriate because they are gapless, so generate Intel HEX files since these
are very well supported by most programming tools while still flexible.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
