Is there a clash between the connectivity framework and FlexNVM?

[stephenlangstaf]

I'm looking at using the connectivity framework for some development on KW36, with FlexNVM used for some EEPROM emulation.

It appears from the KW36 reference manual that when the memory is partitioned for FlexNVM use then the EEPROM backup pages will be allocated from the top of DFLASH. Will this clash with the memory used for the hardwareParameters data structure?

Also, the OTAP boot loader documentation states that:

The OTAP Bootloader does not overwrite the last flash sector which contains the hardware-dependent data

If FlexNVM is in use then would the bootloader need to protect an area larger than the last flash sector?

Is the connectivity framework going to be updated to be aware of FlexNVM when partitioned for EEPROM emulation?

[estephania_mart]

Hello,

Please consider that the GNU linker cannot automatically place code or data across two separate memory regions, so it must analyzed and manually you will need to choose what sections will be placed at which memory (P-Flash or FlexNVM) to get the most efficient way to use the total memory size as it is stated in this post.

Still, as the project you are using is the OTA one, it is most likely that you will run out of memory due to the footprint of the example and bootloader, so u will need to configure and use an external memory to achieve what you are trying to do.

Sorry for the inconveniences this might cause you.

Regards,

Estephania

[stephenlangstaf]

Hello Estephania,

Leaving aside the issue of OTA support for the moment...

I'm not intending to use the FlexNVM as a program code store, but as an EEPROM emulation for the application to store some data.

Since allocation of FlexNVM pages are done from the top of memory then it appears that there is a clash between FlexNVM memory allocation and FREESCALE_PROD_DATA that needs to be accounted for in the connectivity framework.

Now, going back to the issue of OTA support, are you telling me that by the time we get the bootloader and OTA client into the memory map, along-side any primary functionality, it is unlikely that we will fit into the bottom 256K of FLASH and so will require an external FLASH device (and hence lead to an increase in the BOM, PCB size and power consumption)?

[estephania_mart]

Hello,

OK, yes there are some variables that are needed like the BD address, bonding information, etc. Nonetheless, for further details you can check and locate it in the linker and maybe decrease the pools in the stack.

In the Bluetooth Low Energy Release Notes, you can check some of the footprints of the device and stack. You can find that information in the following path.

<installation path>\docs\wireless\Bluetooth

Still, it will depend on how big your application is. If your applications is not that big you can use it without any external memory, but in the OTA example there is a different bootloader plus the application code and the stack code. I can't guarantee that you will need an external memory but it appears that you will need to due to those elements.

Sorry for the inconveniences this might cause you.

Regards,

Estrephania