I have got some rather weird behavior with a static array of function pointers on the ATmega328p. when I call the pointed to function, the normal behavior is expected to be that an LED blinks once. some of those functions have the behavior of being called an infinite amount of times. The exact positions of those incorrectly behaving functions in the array are: Index 1 5 18 21 24
You should print all function pointer values before calling into them, to see whether you’re not calling into 0x0000 (reset vector) or the function itself.
Also it could be that the processor automatically calls the ISR again after an ISR handler does not clear the interrupt pending bit for the interrupt? That’s how it works in many processors.
the class InterruptVectorTable initializes the array properly with empty functions(constructor defines an empty lambda function).
one of the functions in that array is set to a new lambda function that blinks an LED (InterruptVectorTable::setISR(index, function))
after that the method triggerISR(index) just simulates an interrupt, no interrupt is actually really triggered. it simply tries to call the function pointer in that static array.
There is no actual ISR behavior there other than ISRs also calling individual functions from that array. But my test aims currently at the method called triggerISR, which simply tries to call the functions directly.
Cannot really print anything, as bare metal and until now(?) there is no debugger for the atmega328p in PIO.
After some LED testing I can say that the controller is not being reset, otherwise it would initially blink fast and then once slowly. Afterwards these both patterns should repeat, what they do not do.
It simply continues to blink slowly (behavior of the function that’s being passed to the function pointer array).
Edit:
Some previous attempts that did not work were:
hm, slowly approaching goal, but I do not understand, why this helps.
I now have kind of two static arrays, one with uint16_t and another with the old function pointers.
the infinite loop of blinking stopped, but I seem not to be able to reproduce this state without getting the repeated behavior of the function pointer array.
I am guessing that the parallel existence of those two arrays seems to push the second array into some correct ram region, but not sure.
Another problem stays, I cannot execute multiple function calls after each other from that array.
I am not sure what happens.
Is there some IDE for this Microcontroller that I could use to debug the binary somehow?
I think it just needs any USB-Serial adapter and a Diode (to properly isolate the bi-directional line). As I said I’m trying to get that to work myself soon. But even with debug printf style debugging some important things should be found out, like function pointer target addresses.
So what does the output say, does adding print statements make it clearer?
You might try to reproduce the project in Atmel Studio, but i’m not sure whether the USB-ASP probe is debug-wire debugging capable.
Seems like its missing some C++ mutex stuf and it also doesn’t like your modern C++ stuff with auto [...] -> void lambda stuff there. Maybe it uses an older compiler version or a lower C++ standard number? Not sure how easy the compiler toolchain can be reconfigured in Atmel Studio to e.g. use the, for this project, working PlatformIO provided toolchain.
hm, I could not get the debugging to work, but Atmel Studio allows to simulate the microcontroller.
I was able to reproduce my weird blinking behavior.
hm, enabling individual interrupts on the ATmega328p seems to partially already trigger interrupts without them being configured.
(watchdog times etc.)
the arm cortex-m processors seem to behave differently when enabling individual interrupts without having configured them.
in PIO.
