Uno and ProMicro crashes after config upload once a stepper is defined

[elral]

Once a stepper is defined the Uno and ProMicro crashes after the next or overnext (depends on how many additional devices are defined) config upload. On the Mega it needs ~16 uploads w/o reset in between, so it will be very seldom.

To reproduce it on the ProMicro/Uno, define a stepper and e.g. a button. Upload this config and add an additional device. Upload this config again. Does the uplaod end w/o error, at least the next coming upload will not be successfull.

The reason is, steppers are initialized dynamically. During config upload all devices are resetted and for dynamically initialized devices the used memory (RAM) is freed. Unfortenutley this does not really work like we also saw for the 7Segements before.

Initializing the steppers statically will increase the required memory up to ~98%, but it seems to work stable until you define one LCD. The LCD device is also intialized dynamically so we are running into the same problem. The remaining RAM might not be sufficient to initialize the LCD statically, but needs some more tests.

The only solutions I can imagine for now is to free up the required RAM by e.g. dispensing the config buffer, reduce the number of devices or reduce the size of the config buffer.
Dispensing the config buffer would mean some (bigger?) changes on the connector side, but is the most effective for freeing up the RAM.

Any other proposels are welcome.

[neilenns]

I am able to reproduce this locally. I did some digging online and found code that can report the available memory and largest available memory block on an Arduino.

I added this to the firmware and made a new command called kMemory that reports the values. I updated the desktop app to call this command on GetInfo and after ActivateConfig. I used my pro micro with an LCD display, button, 5 LEDs, and one stepper configured.

At initial startup here's the memory report:

Total available memory: 467	Largest available block: 467	 Fragmentation: 0%.

I went into the modules dialog and re-uploaded the same config. This is the report:

Total available memory: 373	Largest available block: 373	 Fragmentation: 0%.

After that any future uploads result in the crash.

[neilenns]

For comparison here's what my Mega shows at startup when I have a bunch of devices and a stepper configured:

Total available memory: 3531	Largest available block: 3531	 Fragmentation: 0%.

And here's what it looks like after uploading the config again:

Total available memory: 3375	Largest available block: 3375	 Fragmentation: 0%.

[elral]

What I found so far:

1. if you are not using "delete" in the :detach() function, then they do not crash!? What is this??
2. moving the variables from the constructor to an additional :init() function helps also, no crashes anymore. BUT in this case only one stepper can be configured. After configuring the second one the Uno does not start anymore. Why is in this case more memory required than to have the variables in the constructor??

Sebastian proposed to make a reset after uploading the config. I think this would be the best way to have always a "clean" memory.

[elral]

@neilenns , seems that at your ProMicro 107 Bytes getting "lost". ~150 Bytes are required for each stepper if you declare them statically.

Could you send me the link for reporting the used memory? I have also somewhere some code from past days, but I have to search it.
And I added a kind of "debug print out" in the connector (will show up in the debug window) and firmware, maybe we can align this.

[neilenns]

I have an LCD display as well so that might account for the remaining 107 bytes?

I pushed two branches for you: Firmware that adds the kMemory command and desktop app that has a GetMemoryStats() method called on GetInfo and ActivateConfig.

[elral]

That's what I found from the past:
`*

• mem_check.h
• Created: 14.05.2014 12:57:21
  */
  #ifndef MEM_CHECK_H_
  #define MEM_CHECK_H_
  unsigned int get_mem_free (void);
  unsigned short get_mem_unused (void);

#endif /* MEM_CHECK_H_ */

/*
Dabei liefert get_mem_free() den derzeit freien Speicher zwischen Stack
und Heap.
get_mem_unused() liefert die Speichergröße, die noch nicht "angerührt"
wurde. Allerdings funktioniert dies dann aber nicht mehr, wenn man mal
malloc() aufgerufen hat, weil dann das initialisierte Pattern am
"Ram-Ende" überschrieben wird.
http://www.mikrocontroller.net/topic/238822#2424929
/ /

• mem_check.c
• Created: 14.05.2014 12:56:50
  */

#include <avr/io.h> // RAMEND
#include "mem_check.h"

// Mask to init SRAM and check against
#define MASK 0xaa

// From linker script
extern unsigned char __heap_start;

unsigned int get_mem_free (void)
{
return SP - (uint16_t) &__heap_start;
}

unsigned short get_mem_unused (void)
{
unsigned short unused = 0;
unsigned char *p = &__heap_start;

do
{
	if (*p++ != MASK)
	break;

	unused++;
} while (p <= (unsigned char*) RAMEND);

return unused;

}

/* !!! never call this function !!! */
void attribute ((naked, section(".init3"))) init_mem (void);
void init_mem (void)
{
__asm volatile (
"ldi r30, lo8 (__heap_start)" "\n\t"
"ldi r31, hi8 (__heap_start)" "\n\t"
"ldi r24, %0" "\n\t"
"ldi r25, hi8 (%1)" "\n"
"0:" "\n\t"
"st Z+, r24" "\n\t"
"cpi r30, lo8 (%1)" "\n\t"
"cpc r31, r25" "\n\t"
"brlo 0b"
:
: "i" (MASK), "i" (RAMEND+1)
);
}`
There is one important remark, get_mem_unused() reports the free memory which is untouched. This does not work after once malloc() was called. And malloc() is called by "new CLASS" what is used.

I will have a look into your branches, thanks!

[GioCC]

Another option, which could be the most sensible in an embedded environment like the Arduino, would be to get completely rid of dynamic allocation (which is known to be something best avoided). Reserve a fixed buffer, large and fully controllable during compilation, and manage it explicitly; after all, all we need is to either incrementally allocate chunks of memory, or free up everything and start from scratch, therefore management would be almost trivial.
This would also allow to dispense with the allocation of a fixed max number of units for each device type, meaning the user could decide to use up the whole memory to allocate e.g. buttons rather than displays (obviously according to the limited number of pins available). This might become crucial with the introduction of input shifters, multiplexers and I/O expanders.
Also, getting rid of the config buffer in RAM is something that's becoming overdue.

[neilenns]

@GioCC I was thinking of something similar after reading around online a bit. Was thinking of looking for a library that would handle the management, but as you point out the needs of the firmware are pretty simple.

[GioCC]

TBH it's something that I had in my bucket list, but (a) there's already very much going on at the moment (Hooray!!! :D) and (b) I won't claim to be able to work 25/8, even during the holidays... but I'm certainly up for it as soon as I manage to find the time.

[elral]

Very strangge things are going on. And now after a couple of hours I found out that MemInfo functions mentioned above from Neil can also cause a crash.
OK, so starting again from scratch with my investigations...

[elral]

Seems that I got now a stable version for the Uno. I have to test it for the ProMircro too, but unfortenutely I bricked him during my testing. I have to find some time during the weekend.

It was only possible to reduce the RAM by every idea I have in mind and we all habe discussed before. Espacielly reduncing the configBuffer size (only the names from the inputs are now stored) was a main driver, but also some other "small" modifications.
I need to clean up my branch with all my debug prints, comments, ... before I could make a pull request.
I do not look optimistic for merging the multiplexers as I except some more RAM usage for them and it is getting really really short.

Another option would be, to init all possible devices dynamically and issue an reset after uploading the config. Allocation of memory seems to working fine.

[GioCC]

@elral about the multiplexers (or any other device, really) you're right, in fact I had to temporarily disable Steppers in order to have at least enough memory to get them working; and the real offender BTW was the flash space (obviously RAM was on the edge too).

[elral]

@GioCC yes, the stepper lib needs quite a lot of RAM and Flash. Even with the RAM saving I have implemented and maybe same additional one (I expect only minor savings futhermore like Neil also stated in issue 136) it could be that more devices do not fit anymore into the RAM/Flash of the Uno/ProMicro.
And that could happen with your multiplexer, whereby it should be also discussed if it makes sense for the Uno/ProMicro (best under the discussion about this in the connector repo) and not limited to the multiplexer.

And by the way, I got again a worse finger from scrolling with the mouse through the "big" mobiflight.cpp file. ;)
I had a short discussion with @DocMoebiuz some days ago and @neilenns also proposed it already to split up the mobiflight.cpp into several files. I (and Neil?) have prepared a branch , but I guess it would be better to open a separate discussion/issue.

[GioCC]

Unfortunately I think we're already scraping the bottom of the barrel by just trying to optimize individual devices (which is still welcome anyway, where possible).
In my opinion the most promising way to go to reclaim memory is to get rid of the RAM config buffer (this is what you told me you were already working on, isn't it?) and most of all, controlled dynamic allocation of required devices. Having pre-allocated arrays for a fixed number of devices the you will not use is something that makes me itch...
For Flash space, modular compilation would be the ideal solution, but as already explored, this is a little more complicated feature. I do not lose hope that we'll probably end up addressing it in the long run.

About the length of the Mobiflight.cpp file... glad to hear this has been brought forward! I had the exactly same feeling, and I would have proposed that too sooner or later... Let's open a discussion, by all means, I'm interested.

[elral]

Regarding the configBuffer I fully agree, and I already prepared everthing. Parts of it I used for reducing the size as now only the names of the input devices are stored in the configBuffer. It is an easy next step to get rid of the complete configBuffer.
But, this would mean changes on the connector side I am not able to do this. And it is a topic of backwards compatibility what @MobiFlight-Admin mentioned to me. Means these changes result in a firmware update too. This was not required in the past and is a question of user acceptance. For now I have not build an opinion for myself.

Regarding the dynamic memory allocation I am also not sure how to proceed. Allocating does work, but not freeing the memory. A solution could be to issue a reset after config upload (not sure how to do this for the ProMicro), but then it has to be ensured that not too much memory gets allocated by too much devices. Some kind of calculation has to be done while adding each single device, either in the firmware (preferred) or in the connector. If this is not done the Arduino could crash during startup and even the ProMicro can get bricked.
For now I see a good chance to get it stable with the existing devices, but checking it for the ProMicro I have to shift until next week as I brocked yesterday my ProMicro mechanically (USB connector).
But it has to be decided how to proceed...