The phy_speed_100mbs, phy_full_duplex, and phy_link_active fields of
PHY_STATUS_TYPE are 1 bit wide but lpc_phy_init() attempted to
initialize them to a value of 2. I switched the initializations to
be 0 instead and it still generated the same .bin image.
The first was a potential out of range index read in dhcp_handle_ack().
The (n < DNS_MAX_SERVERS) check should occur first. There is also a
documented lwIP bug for this issue here:
http://savannah.nongnu.org/bugs/?36170
In dhcp_bind() there is no need to perform the NULL check in
ip_addr_isany() for &gw_addr. Just check (gw_addr.addr == IPADDR_ANY)
instead.
I refactored the chaddr[] copy in dhcp_create_msg() to first copy all
of the valid bytes in hwaddr and then pad the rest of the bytes with 0.
Before it used to check on every destination byte if it should copy or
pad. GCC originally complained about an index out of range read from
the hwaddr[] array even though it was protected by a conditional
operator. The refactor makes the intent a bit clearer and saves the
extra comparison per loop iteration. It also stops GCC from
complaining :)
GCC will issue a warning when the ip_addr_isany() macro is used on
a pointer which can never be NULL since the macros NULL check will
always be false:
#define ip_addr_isany(addr1) ((addr1) == NULL || \
(addr1)->addr == IPADDR_ANY)
In these cases, it is probably clearer to just perform the
x.addr == IPADDR_ANY check inline.
The dn variable in lpc_low_level_output() was originally defined as a
u32_t but it is later compared to the s32_t return value from
lpc_tx_ready(). Since it is intialized to pbuf_clean() which returns
a u8_t, a s32_t type can safely hold the initial value and remains
consistent with the signed lpc_tx_ready() comparison.
I also modifed writtenLen in TCPSocketConnection::send_all() and
readLen in TCPSocketConnection::recieve_all() to be of type int instead
of size_t. This is more consistent with their usage within these
methods (they accumulate int ret values and are compared to the int
length value) and their use as a signed integer return values.
The original script assigned memory ranges to USB_RAM and ETH_RAM but
it never placed any section data in those regions. I added clauses
towards the bottom of the script to place data that the programmer
has marked for the AHBSRAM0 and AHBSRAM1 sections into these regions
of RAM. Previously the data destined for these sections was being
placed in the lower 32K RAM bank and overflowing it at link time.
I also added a few Image$$ linker symbols to mimic those used by the
online compiler. I have had samples in the past which took advantage
of these to display static memory statistics for each SRAM region.
I also changed LENGTH=0x7F38 to LENGTH=(32K - 0xC8) to make it more
consistent with the sizing of the other regions in this script which
use human readable K sizing information. The 0xC8 subtraction reflects
the starting offset of 0xC8 for this region.
i2c_frequency() compares a uint32_t ref variable to the int hz
function parameter passed in by the caller. I forced this to be an
uint32_t comparison.
i2c_slave_write() declared i and count variables to be of type uint32_t
but used them as int type throughout the code (in comparisons and
returns) so I switched them to be of signed int type.
spi_frequency() contains a change similar to that made in
i2c_frequency().
This commit targets the KL25Z code, whereas previous ones targetted
similar issues in the LPC1768 and LPC11U24 mbed HAL code.
These changes were made to silence GCC warnings and fix potential bugs
where they would never be equal when the enumeration wasn't a 32-bit
type.
For example, pinmap.c used to contain this code:
if (pin == (uint32_t)NC) return;
I switched it to:
if (pin == (PinName)NC) return;
I wonder why this casting to uint32_t was done in the first place?
Maybe another supported compiler requires it?
This commit targets the LPC11U24 code, whereas a previous one
targetted similar issues in the LPC1768 mbed HAL code.
These changes were made to silence GCC warnings and fix potential bugs
where they would never be equal when the enumeration wasn't a 32-bit
type.
For example, pinmap.c used to contain this code:
if (pin == (uint32_t)NC) return;
I switched it to:
if (pin == (PinName)NC) return;
I wonder why this casting to uint32_t was done in the first place?
Maybe another supported compiler requires it?
The original code was:
if(LPC_CAN1->IER | LPC_CAN2->IER != 0) {
This would actually be interpreted as:
if(LPC_CAN1->IER | (LPC_CAN2->IER != 0)) {
I simplified it to:
if(LPC_CAN1->IER | LPC_CAN2->IER) {
With the comparison removed, the GCC warning no longer fires since the
user's intent is no longer unclear. However, the end result should be
the same.
These were done to silence GCC warnings and fix potential bugs where
they would never be equal when the enumeration wasn't a 32-bit type.
For example, common/pinmap_common.c used to contain this code:
if (pin == (uint32_t)NC)
I switched it to:
if (pin == (PinName)NC)
I wonder why this casting to uint32_t was done in the first place?
Maybe another supported compiler requires it?
Bogdan Marinescu
Adam Green
pbrier
0xc0170
Emilio Monti
Toyomasa Watarai
Bogdan Marinescu
Andreas Rebert
Bogdan Marinescu
francois.berder@arm.com