LLKernel validation issues with implementation similar to the VEE Port STM32F7508J-DK

,
1

Hello MicroEJ team,

I worked on an implementation of LLKERNEL to load features in RAM.
The implementation resembles what is done on the STM32F7508 in the sense that some natives are stubbed :

I’ve integrated the sources to run the LLKERNEL C testsuite available here:

Instead of getting the expected result (see link above), I get the following result:

LLKERNEL resource allocate
LLKERNEL tests.T_LLKERNEL_resource_allocate (x\validation\tests\llkernel\c\src\t_llkernel.c 100) exp 1 was 0

LLKERNEL resource allocate and free
LLKERNEL tests.T_LLKERNEL_resource_allocate_and_free (x\validation\tests\llkernel\c\src\t_llkernel.c 161) exp 1 was 0

LLKERNEL resource allocate overflow
OK

LLKERNEL resource install overflow
OK

LLKERNEL resource install out of bounds
LLKERNEL tests.T_LLKERNEL_resource_install_out_of_bounds (x\validation\tests\llkernel\c\src\t_llkernel.c 266) exp 1 was 0
INFINITE_LOOP_ASSERT_FAILED

Every failed assertion in the above traces is due to the function LLKERNEL_IMPL_getAllocatedFeaturesCount which is stubbed as follows:

int32_t LLKERNEL_IMPL_getAllocatedFeaturesCount(void) {
    // No persistence support
    return 0;
}

If I try to implement the function LLKERNEL_IMPL_getAllocatedFeaturesCount with a global variable that increments on a successful call to LLKERNEL_IMPL_allocateFeature and decrements on a successful call to LLKERNEL_IMPL_freeFeature, the VM’s behavior changes and makes a call to the native LLKERNEL_IMPL_freeFeature.
decrements on a successful call to LLKERNEL_IMPL_freeFeature, the VM’s behavior changes and makes a call to the native LLKERNEL_IMPL_getFeatureHandle stubbed as follows:

int32_t LLKERNEL_IMPL_getFeatureHandle(int32_t allocation_index) {
   // No persistence support
   MEJ_LOG_ERROR_KERNEL("%s : No persistence support, code stopped.",__func__);
   KERNEL_ASSERT_FAIL();
}

If I implement LLKERNEL_IMPL_getFeatureHandle so that it returns 0 all the time, I have an infinite loop of calls to the native LLKERNEL_IMPL_getFeatureHandle.
If I implement LLKERNEL_IMPL_getFeatureHandle so that it returns 1 all the time, in order to see if I’m out of the infinite loop, I get a hardfault.

So I have the following 2 questions:

  1. What LLKERNEL tests are supposed to pass with an implementation similar to STM32F7508?
  2. How should the implementation be modified to pass all the tests? For example, with LLKERNEL_IMPL_getFeatureHandle, does the VM expect an address to a pointer of type installed_feature_t?

Thanks in advance for your help,
S.

2

Hello s.connor,

The LLKernel TCK (VEEPortQualificationTools/tests/llkernel at master · MicroEJ/VEEPortQualificationTools · GitHub) is used to validate LLKernel implementation on architecture 8.1.0 or higher.
This STM32F7508 LLKERNEL implementation (MicroEJ/VEEPort-STMicroelectronics-STM32F7508-DK/blob/master/stm32f7508_freertos-bsp/projects/microej/kf/src/LLKERNEL_SDRAM.c)
is based on architecture 8.0.0, so the LLKernel TCK is not applicable to this implementation.

The function LLKERNEL_IMPL_getFeatureHandle() returns a handle to the feature installed in memory.
This handle can be an address or a simple identifier, depending on your implementation. Essentially, it is used in the functions LLKERNEL_IMPL_getFeatureAddressROM() and LLKERNEL_IMPL_getFeatureAddressRAM() to retrieve the ROM and RAM memory areas allocated for the feature (refer to the documentation in LLKERNEL_impl.h).
Therefore, It is up to the developer to associate the handle with the corresponding memory areas.