Simulation freezes after completion of unity and next malloc

[IngmarEckhardt]

Hey Community,

Maybe you want to look into the situation, I have troubles to debug it. When I run the test for the flash helper with unity in the simulator (simutron as wrapper) the simulation freezes at next malloc after unity finished, doesn't matter where I call malloc or if this is a simulated atmega2560 or a Atmega328p. I think malloc can't be the problem, I see no blocking things or loops there.

Can't let simavr run as embedded gdb server, or with other words I lack the skills to add the virtual port to uart by my self. So I can't step with breakpoints through the code.

It is in this branch, I linked the CMakeLists for the tests. It's happening in the isolated target for flash helper and the test runner too. After the tests for stdio(puts_pf) this don't happen.

Edit: I know I forgot to tell you which version simutron is wrapping here. Maybe this is simutron related and their windows build related. Sry. Will give this infos at the evening when sun dissappeared.

Would still love a command line option for a virtual serial port to uart0. But your project is really great. Thanx for the tool.

https://github.com/IngmarEckhardt/dwarfOS/blob/7-unit-tests-for-flash_helper/tests/CMakeLists.txt

EDIT: There is no versioning at all? It is the simutron-1.0.1-SR1-Win32 build.

[IngmarEckhardt]

I updated this branch because added tests. Now this malloc freeze happens also inside the tests. Because its a branch under construction i added encapsulate printf around the failing malloc in the helper that its under test.

This is the situation at the serial terminal.

Will let this remote branch for sure at least two days in this condition, dont have so often a fire in the appartment :)).

Try to run the tests just without output. But i cant step into malloc and it still freeze when i use simavr.exe as embedded gdb. Did have to pull the source code and build the whole lib myself for this step into?

[gatk555]

I find this hard to understand, perhaps because your configuration is complicated. For example, I have no idea what "unity" is here.

Two suggestions: have you tried enabling the tracing feature of simavr? If the problem is an infinite loop in firmware, that will show it. If not, it will show what the simulator is trying to do when it hangs.

Second: please post just the firmware that fails and any instructions needed to build it. If some input is needed that can be recorded as a VCD file that can be played back in the simavr/run_avr program. Then maybe someone will look at it.

[buserror]

You could also try to attach gdb to the running process of simavr if it loops... and see what's going on. It's very likely the firmware is spinlooping somewhere, this leading simavr into 'freezing' as it continues emulating it...

[IngmarEckhardt]

I find this hard to understand, perhaps because your configuration is complicated. For example, I have no idea what "unity" is here.

It is linked as a library in the CMakeLists? It is linked as a folder as github module? It is a lightweight testing library for c code.

Two suggestions: have you tried enabling the tracing feature of simavr? If the problem is an infinite loop in firmware, that will show it. If not, it will show what the simulator is trying to do when it hangs.

Thank you for this advice. I will try this.

Second: please post just the firmware that fails and any instructions needed to build it. If some input is needed that can be recorded as a VCD file that can be played back in the simavr/run_avr program. Then maybe someone will look at it.

But i did this? The CMakeLists i linked contain every information to build the elf-file? It is the target with the separated test of the flash_helper? You can even watch the content of the whole flashmemory with a additional target?

EDIT: You can just change the implementation and get rid of user interaction and just start the test without asking stdin. Just set int menu to 1 and delete the call to stdin.

EDIT2: The output of the program is in the tx pin as normal string, serial communication. Frameformat is in setup of the actual sourcefiles of the DwarfOS library. Its set to 28kbaud, but i think this doesnt matter for a vcd file?

[IngmarEckhardt]

You could also try to attach gdb to the running process of simavr if it loops... and see what's going on. It's very likely the firmware is spinlooping somewhere, this leading simavr into 'freezing' as it continues emulating it...

Thank you for this advice.

EDIT: It is really the call to malloc where this happens, you see the printf before was executed, the printf after not. And malloc is not my function. So this could also be a avr-gcc bug if it also happen in the wsl-environment? Because their malloc implementation has no loops that could possibly block?
[/EDIT]

Found another strange behaviour, running simavr.exe as embedded gdb server, are you interested that i upload this in a different branch? But my next step is to use simavr in a wsl-ubuntu environment to get rid of problems that are maybe related to the windows build, maybe then such error dissappear.

EDIT2: Tried to encapsulate it as atomic operation with disabling all interrupts before, just a desperate move because no interrupt changes this values, but doesnt change the problem that the calculation is wrong with uint32_t as result. Really hope these problems dissappear with using the linux build, still love your tool.

[IngmarEckhardt]

I am now in a linux environment with simavr installed with apt-get package manager. Will look into the freezing malloc branche with this tracing feature (at first have to read how to do).

But also here i have this strange behaviour with the calculation, that its wrong with uint32_t as result. My CPU is slightly undervoltaged, never had any problems, maybe this is the first. This branch is still not uploaded, just playing around.

EDIT:
Tried to disassembly it. I am using avr-gdb. Maybe it is their bug?

[buserror]

You might be running out of stack. Try declaring half these variable 'static' and see if it helps

[IngmarEckhardt]

You might be running out of stack. Try declaring half these variable 'static' and see if it helps

This is with ELPM device, sry don't mentioned it, but I always name the run configurations recognizable, it's in the screen. it's a simulated atmega2560. This function getFreeMemory from my heaphelper that has the stack pointer gives me 7000 free memory between stack pointer and malloc heap.

Edit: Little bit frustrating, pretty sure the functions are now fine and all tests should pass, if this calculation goes right for example.... I know there is a strong probability that the user, me, is the problem, but it's hard to debug.

[gatk555]

Ingmar Eckhart,

Please read the first paragraph of the first comment on #531.

G,