Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes to LiveLogTick function, memory bounds checking, and optimizations to save memory space requirements in the firmware #285

Merged
merged 2 commits into from
Oct 19, 2020

Conversation

maxieds
Copy link
Contributor

@maxieds maxieds commented Oct 15, 2020

After some discussion with @ceres-c summarized in #284 (with possible build configuration solutions in #283), the standard firmware binary that resulted before used too much memory. This seems to be the cause of several recent issues and unpredictable crashes running the firmware. I looked at this today and found some fixes that help. Note that with these changes the newly compiled binary yields:

$ avr-size -t Chameleon-Mini.elf
   text	   data	    bss	    dec	    hex	filename
  56424	   1288	   4716	  62428	   f3dc	Chameleon-Mini.elf
  56424	   1288	   4716	  62428	   f3dc	(TOTALS)

The last numeric column is noted to not exceed 0x10000.

A complete summary of all the changes contained in this pull request are given below:

  • Change in the implementation of LiveLogTick: In Enhancements to LOGMODE=LIVE logging functionality #279, this functionality was merged. It included small numbers of dynamic allocation of memory space via malloc/free. This is typically not good practice on memory constrained devices, and pulls in extra memory requirements. I rewrote the core of the LiveLogTick.h sources to store the linked list node structures in the LogMem buffer (along with the temporary contents of logs). The solution removes the need for the dynamic memory alloc/dealloc functions from GLibC. It also seems to fix some oversights in the original code based on testing. Notice that every position for the structure pointer addresses needs to be an even multiple of four.
  • A couple of new FRAM memory R/W functions: Added MemoryReadBlockInSetting and MemoryWriteBlockInSetting that tag implementations can call to safely write to the FRAM space for their slot. These check an upper bound on the size of the block address, and add an offset into FRAM based on the slot index. In contrast, the original two functions do not ignore unintentional memory boundary errors and do not shift the block address by the slot index offset.
  • Makefile changes: The added flags, and the change of value of the FLASH_DATA_SIZE option reflects the noise and discussion from yesterday. Nothing fancy, just compiler optimizations to make the memory imposed on the AVR less bloated.

…iting to FRAM within a setting, and elf binary file space reducing modifications to the Makefile
@fptrs fptrs merged commit 60d5744 into emsec:master Oct 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants