Originally the ethernet ISR would be linked in to all mbed-os based
firmware because it was named ENET_IRQHandler() so that it would be
automatically placed in the FLASH image's interrupt vector table. This
meant that programs which made no use of the lwIP stack still pulled in
this ISR.
This commit changes the name of the routine so that the ISR isn't
automatically placed in the interrupt vector table at link time but is
instead dynamically placed in the interrupt vector table at runtime
when the lwIP stack is initialized. Now the ethernet ISR is only linked
in when it is actually needed.
Example arm-none-eabi-size output for a simple LED blinking program
showing the before and after size results:
text data bss dec hex filename
13208 148 7784 21140 5294 LPC1768/HelloWorld.elf
text data bss dec hex filename
12700 148 7468 20316 4f5c LPC1768/HelloWorld.elf
ticker_insert_event() can crash on KLXX (and probably other platforms) if an event is inserted with a timestamp before the current real time.
The problem is easy to trigger: you just need to set up a Ticker object, and then disable interrupts for slightly longer than the Ticker object's interval. It's generally bad practice to disable interrupts for too long, but there are some cases where it's unavoidable, and anyway it would be better for the core library function not to crash. The case where I had an unavoidably long interrupts-off interval was writing flash with the FTFA. The FTFA hardware prohibits flash reads while an FTFA command is in progress, so interrupts must be disabled for the whole duration of each command to ensure that there are no instruction fetches from flash-resident ISRs in the course of the execution. An FTFA "erase sector" command takes a fairly long time (milliseconds), and I have a fairly high frequency Ticker (1ms).
The problem and the fix are pretty straightforward. ticker_insert_event() searches the linked list to figure out where to insert the new event, looking for a spot earlier than any event currently queued. If the event is in the past, it'll usually end up at the head of the list. When the routine sees that the new event belongs at the head of the list, it calls data->interface->set_interrupt() to schedule the interrupt for the event, since it's the new soonest event. The KLXX version of us_ticker_set_interrupt() then looks to see if the event is in the past, which we've stipulated that it is, so rather than actually setting the interrupt, it simply calls the handler directly. The first thing the Ticker interrupt handler does is re-schedule itself, so we re-enter ticker_insert_event() at this point. This is where the problem comes in: we didn't finish updating the linked list before we called set_interrupt() and thus before we recursed back into ticker_insert_event(). We set the head of the list to the new event but we didn't set the new event's 'next' pointer.
The fix is simply to finish updating the list before we call set_interrupt(), which we can do by moving the obj->next initialization ahead of the head pointer update.
The current implementation of semihost_disabledebug() hangs when used
with mbed interface firwmare revision 21164, the first version which
added support for this semihost call. I encountered this hang when
running a Release build on my mbed-LPC1768 board as the RTOS attempted
to disable the debugger before the idle thread put the CPU to sleep.
The 21164 interface firmware expects that R1 points to a valid argument
block but the current implementation passes in NULL. The fix was to
pass in a dummy block which is ignored by the newer 141212 revision of
the firmware and allows the 21164 version to proceeed without halting
the CPU until a manual reset.
Before this fix semihost_disabledebug() did work with the latest
mbed interface firmware revision 141212 but I rarely use this revision
of the interface firmware due to the instability issues I have
encountered in the past with its CDC and LocalFileSystem functionality.
With this proposed fix, the code now works with both the 21164 and
141212 revisions of the mbed interface firmware on the mbed-LPC1768.
The extra space between "--no_wrap_diagnostics" and "-e" is inconsistent with the development and release targets.
It bugs people (like me) that have little OCD tics 😉.
From opt.h:
IP_SOF_BROADCAST_RECV (requires IP_SOF_BROADCAST=1) enable the broadcast
filter on recv operations.
The IP_SOF_BROADCAST_RECV option does not enable or disable recieving
broadcast packets, it only enables a software filter.
If I2C slave support is included, then the I2C error handler would
always reset the I2C address, resulting in incorrectly changing the
I2C state to listen for a controller configured as I2C master. This
change conditionalizes the address setting to only occur if the
controller was in slave mode when the error occurred.
Before, the types were not checked and just expected. The old behavior
would cause lots of tracebacks, or, much worse, convert things like:
```
{
"target_overrides": {
"*": {
"target.macros_add": "CONFIG_GPIO_AS_PINRESET"
}
}
}
```
into a definition of each of the letters as macros that expand to
nothing, causing massive compilation problems.
I resolved this by adding some type checking to the config data. Now
there is a type check for most of the fields within a library and
application configurations.
This removes the duplicate header files from the build. We were getting
lucky on most invocations of `mbed compile` in that these headers were
searched for after some others, but not when exporting to uvision.
ccli8
Martin Kojtal
Anna Bridge
Jimmy Brisson
Adam Green
Rob Meades
mjrgh
Głąbek, Andrzej
jeromecoutant
Willie Walker
Seppe Stas
Christopher Haster
Mahadevan Mahesh
Tony Wu
Michel Jaouen
Bradley Scott
Seppe Stas
Brian Daniels
Andrzej Puzdrowski
Ron Eldor