DEVICE_EMAC is defined only for boards with default Ethernet emac.
It is not defined for example for Realtek RTL8195AM board that
does not have Ethernet. Removed the check for device emac from emac
greentea tests.
The issue rose up when using ARMC6. A test case didn't initialize NetID
parameter for ABP while using connect(params) API. NetID is the first 7 bits
of the Device Address. It makes sense to actually remove the net-id parameter
from ABP settings as the stack can deduce it from device address. However, the ABP
structure is exposed in public APIs, so we can't really do that at the moment.
Simpler fix is to move the mask that helps us to extract first 7 bits of the device address
is exposed in lorawan_types.h and the user can use it to deduce correct net-id.
Decreased stack size from 24kB to 1kB (stack is used on boot-up/interrupt
handler). Increased heap size from 65kB to 89kB.
Change is related to issue https://github.com/ARMmbed/mbed-os/issues/7137
where UBLOX_EVK_ODIN_W2 runs out of heap on WLAN.
`handle_error` calls `MBED_CALLER_ADDR()`, but this is always a location from within platform/mbed_error.c. This is because `handle_error` is declared static. This does not cause the function to be inlined however. Instead, it is called by each function within mbed_error.c. For example, mbed_error yields this code:
```
000625c8 <mbed_error>:
625c8: b510 push {r4, lr}
625ca: 460c mov r4, r1
625cc: 4611 mov r1, r2
625ce: 461a mov r2, r3
625d0: 9b02 ldr r3, [sp, #8]
625d2: f7ff feff bl 623d4 <handle_error>
625d6: b968 cbnz r0, 625f4 <mbed_error+0x2c>
625d8: 4620 mov r0, r4
625da: f7ff ff67 bl 624ac <print_error_report.constprop.0>
625de: f7ff fea8 bl 62332 <core_util_is_isr_active>
625e2: b910 cbnz r0, 625ea <mbed_error+0x22>
625e4: f7ff fe9f bl 62326 <core_util_are_interrupts_enabled>
625e8: b908 cbnz r0, 625ee <mbed_error+0x26>
625ea: bf30 wfi
625ec: e7fd b.n 625ea <mbed_error+0x22>
625ee: 2001 movs r0, #1
625f0: f000 f948 bl 62884 <__wrap_exit>
625f4: 4800 ldr r0, [pc, #0] ; (625f8 <mbed_error+0x30>)
625f6: bd10 pop {r4, pc}
625f8: 80ff010f .word 0x80ff010f
```
Note that at `625d2` there is a bl to handle error. That replaces the LR, which means that ALL calls to mbed_error will report a location of 0x625d6 or 0x625d7 (user vs. supervisor). I do not expect that this was the intention of the code. The simplest fix is to change line 99:
```C
static inline mbed_error_status_t handle_error(mbed_error_status_t error_status, unsigned int error_value, const char *filename, int line_number)
```
Since `handle_error()` will be inlined, the link register will be kept the same, so `MBED_CALLER_ADDR()` will yield the expected result. However, there is no guarantee that the compiler will respect the `inline` keyword in all circumstances.
The result is that each function that wishes to report its caller must extract its caller. This code cannot be centralised.
I have modified `mbed_error.c` to report the caller of each error reporting function, rather than the error reporting function itself.
Made to prevent timeout if a single test case fails. The goal is that
each test case might wait only half of the remaining time reserved for
running TCP test cases.
I changed stack size because the deafult stack size may not be enough for
Ethernet of GR-PEACH(Cortex-A).
- Stack size is default size + 128 byte
In order to maximize the performance of Ethernet, I changed heap size to
below.
- Heap size is default size * 32 byte(send descriptor num is 16 and recv
descriptoer num is 16).
In mbed-os-tests-mbed_hal-common_tickers/Microsecond ticker overflow test, some targets
would fail to catch specified ticker value near overflow in time and so fail. This commit
alleviates the issue by checking ticker value range rather than one exact ticker value near
overflow.
51f92b0efd introduced
handling for connection attempts while a connection was already underway or have been
completed. Unfortunately a similar check slipped through and the stack was not able to continue
sending join requests if an error happened.