The previous way of finding group names found the encompassing directory of each file. If the project is exported from the online compiler, this resulted in temporary folder names like tmpyKKWv_ showing up as group names.
I propose defaulting to the project name if the file is in the project root.
Build jobs are failing due build error "arm_hal_timer.cpp:50:5:
error: reference to 'callback' is ambiguous".
Fix the build error by renaming callback to arm_hal_callback to
avoid collision with callback defined in ./mbed-os/hal/api/Callback.h
This patch disables the fcache stats into mbed_sdk_init if uvisor is
defined in order to prevent MEMMANAGEMENT faults during boot.
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
This patch backports the virtual NVIC mechanish from CMSIS 5 for the
Cortex M3 architecture in order to support uvisor in this MCU class.
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
This patch modifies:
* the Beetle GCC ARM linker script
* the Beetle startup code
in order to define the memory regions that enable uvisor.
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
- Add support of cortex-M7 for cthunk.
- Change the cthunk trampoline implementation to safer and quicker
solutions:
* thumb2, the behaviour was undefined. new implementation use now 2
instructions
* thumb, The new implementation use 3 instructions instead of 6.
In rtos/rtx/TARGET_CORTEX_M/RTX_CM_lib.h, Image$$ARM_LIB_HEAP$$Base/Image$$ARM_LIB_HEAP$$Length will cause zero memory allocation.
Fix it with Image$$ARM_LIB_HEAP$$ZI$$Base/Image$$ARM_LIB_HEAP$$ZI$$Length. This is to place heap at external SRAM.
- Avoid a call to the protected method `get_stack()` which cause a build fail.
- Remove the constructor definition `TCPServer(NetworkStack *stack)`
because it has no implementation.
With respect to issues 17 and 23:
- A code defect existed for correctly updating cfstore_file_t data structures
under the following conditions:
-- the KV memory area contained some KV's.
-- cfstore calls realloc() to increase the size of the KV area in
memory because:
* A new KV was being added to the KV area, or
* the size of a pre-existing KV was being increased.
-- The returned address from realloc() has changed from before the
call (i.e. the location in memory of the KV area has changed)
e.g. the presence of heap memory objects directly above the KV memory
area in the memory address space causes realloc() to move the KV area
so the newly increased area can be accommodated at contiguous addresses.
-- In this scenario, the cfstore_file_t (structures for open files) head pointers
do not get correctly updated.
-- The defect was fixed by correctly updating the cfstore_file_t:: head pointer.
-- A new add_del test case was added to the scenario where a new KV is being added
to the KV area.
-- A new create test case was added to the scenario where the size of a
pre-existing KV is being increased in size.
- A code defect for suppling a NULL handle as the previous argument to the Find() method
(issue 24).
-- Supply a null handle is valid, but it was being used to check for a valid hkey,
which was incorrect.
-- A new test case was added to check the case of supplying a NULL previous argument
works correctly.
- A code defect for a memory leak under the following conditions (issue 25):
-- When realloc() fails to perform a requested change to the size of the KV area, the
error handling sometimes incorrectly sets cfstore_context_t::area_0_head to NULL.
Cfstore returns a suitable error to the client. If memory had previously been held
at area_0_head, realloc(area_0_head, size) returning NULL means the memory
at area_0_head is still retained.
-- On receiving the error code, the client cleans up including a call to Uninitialize().
This should free the retained but as area_0_head == NULL this is not possible. Hence
a memory leak occurred.
-- This was fixed by not setting area_0_head = NULL on the realloc() failure.
-- A create test case was modified to detect the leaking of memory in this way.