Whack a mole with MxCube interrupt configuration

[MFolk.1]

I am programming on the STM32L4R9I-EVAL dev board, but my project is configured

for the STM32L4S9AII6. I am clocked at 120MHz.

I have been fighting the following bug off and on for about 3 months. I queried for help on this a couple months ago and thought I had resolved the issue.

https://community.st.com/s/question/0D53W00001PxcHZSAZ/can-you-have-too-many-peripheral-init-functions

I think I fix the issue and then it randomly pops back to ruin my day about every 2-4 days. The problem first manifest itself in my project as I was trying to get a one-shot timer configured. Since then I have observed enough to be 97% convinced that this is an interrupt configuration issue with MxCube, but as I debug the code and analyze the auto-generated code by MxCube everything seems correct.

The cycle goes like this. I have to make some change to MxCube for various reasons like deleting a mutex or queue from FreeRTOS or adjusting settings with DMA or ADC interrupts. The ADC and DMA interrupts that I crawled through was the worst of all and I have since abandoned any hope of being able to use DMA and/or ADC interrupts at all. I have also noticed a very strong correlation with the previously mentioned one shot timer. This peripheral cannot be scrapped from my project.

Anyways, every time the bug comes back the behavior is the same. I run my code in the IDE via debug mode. The program enters HAL_Init() and right after the timebase timer (TIM3, but I've tried several others) IRQ is enabled I notice 3 interrupts become pending that were never configured (DMA1_ch3, DMA1_ch5, & OTG_FS). Its like the MCU just totally looses it. I made the following flow chart to illustrate what I see as I debug it.

 

So then I wrestle around with the NVIC tab within MxCube for hours or days and then the problem just goes away and everything is fine. It is like the MCU is possessed with evil spirits. I've never seen anything like this.

I even tried re-creating my project so that I am starting with the newest version of MxCube (6.5) and I haven't noticed a difference. I also noticed today that about 4mA starts to drain into one of the MCU's ADC pins (PA7) right as soon as the program gets to the crashing point.

Is it possible this is because I am running STM32L4S9AII6 firmware on the STM32L4R9I-EVAL dev board, which uses a different MCU?

Any help would be greatly appreciated. Thanks!

[waclawek.jan]

> break at address 0x1fff'xxxx

Bootloader/PEMPTY-related, this issue comes up here a lot, often related to 'L4+

See the end of this thread:

https://community.st.com/s/question/0D53W00000raYd2SAE/intermittent-break-at-address-0x1fff51f4-with-no-debug

JW

[MFolk.1]

Can the PEMPTY problem be solved on my end? Do I need to clear this bit at some point in the bootloader? The issue that this person this having in the other post may differ from my issue for the following reasons:

• Most of the time when I have this issue the program seems to make it out of the bootloader to my program because it is able to break at HAL_Init(). However, I admit that sometimes it happens before.
• The version of the IDE that the other person was using was STM32CubeIDE 1.6.0. I am using STM32CubeIDE 1.9.0. I would assume the provided patch files would have been incorporated into the next version of STM32CubeIDE. Am I wrong?

Is there a clever way to check for myself if flash is in the erased state?

[MFolk.1]

UPDATE:

I believe this to be some kind of memory issue. At the time I posted this, I was not able to get past HAL_Init() as mentioned already. This time, I whacked the mole by removing a few unused freertos queues within MxCube. The next day the mole came back yet again, except this time I didn't change anything to the interrupts or anything in MxCube at all. I proved through a lot of re-build and running debug that the mole would only exist depending on how many lines of code I had in one of my tasks. If I had too many lines of code, the mole was back with the exact same behavior described in my diagram above. I was able to remove some redundant code to get by for now. Now I am needing to add a mutex which I attempt to do via MxCube. You guessed it, the bug(mole) is back.

I have spent a lot of time playing around with stack vs heap memory allocation, but I feel I am still lacking in this area because this seems like it must be a memory overflow issue.

Any advice on debugging and managing memory on this MCU?

[MFolk.1 · Accepted solution]

I think I fixed the issue. I went into project properties (settings) and unchecked the following two flags under compiler optimization:

• Place functions in their own sections
• Place data in their own sections

I thought to do this because after analyzing my heap usage I notice that I have lots of heap and because I know the size of RAM on this CPU I know that I should have LOTS of space for stack. The only other explanation is how that memory is being utilized by the compiler. Notice that I have lots of RAM but I am out of FreeBlocks.

[waclawek.jan]

I don't use RTOS so I am not familiar with debugging those, sorry.

JW