stm32f334 and probably a stack overflow.. ?

[Manu Abraham]

Posted on April 08, 2017 at 15:31

Hi,

Have been doing quite a bit of drawing onto a LCD display with SPI and DMA. In the process of updating the display, i found the results were unexpected, but the code doesnt seem to be the culprit, since when I test individual parts of the code things do appear working as expected. Eventually, printing it out, my favourite debug model, putstr(), putting a string to the UART Tx register also appear to have frozen (attached screenshot), in all probability.

The program still fits into the flash .. :) The controller is a STM32F334R8T6 (LQFP64)

*** Using Compiler 'V5.06 update 4 (build 422)', folder: 'C:\Keil_v5\ARM\ARMCC\Bin'

Rebuild target 'Target 1'assembling startup_stm32f334x8.s...compiling stm32f30x_gpio.c...compiling stm32f30x_adc.c...compiling stm32f30x_rcc.c...compiling stm32f30x_i2c.c...compiling stm32f30x_usart.c...compiling stm32f30x_misc.c...compiling stm32f30x_spi.c...compiling stm32f30x_dma.c...compiling stm32f30x_hrtim.c...compiling stm32f30x_tim.c...compiling stm32f30x_syscfg.c...compiling stm32f30x_rtc.c...compiling pwm.c...compiling uart.c...compiling adc.c...compiling misc.c...compiling dma.c...compiling lcd_ili9341.c...compiling spi.c...compiling rbuf.c...compiling plot.c...compiling mav.c...compiling font.c...compiling clock_ana.c...compiling main.c...compiling clock_dig.c...compiling rtc.c...compiling graphics.c...compiling thermo.c...compiling rc5.c...compiling timer.c...compiling menu.c...compiling seg7.c...linking...Program Size: Code=23722 RO-data=11158 RW-data=372 ZI-data=5508  FromELF: creating hex file...'.\Objects\Test 2.axf' - 0 Error(s), 0 Warning(s).Build Time Elapsed:  00:00:24

Originally, I've had the

Stack_Size      EQU     0x00000400

thinking that the stack size (1024 bytes) could be a problem,  increased it to (4096 bytes)

(attached startup code), but the change did not make any difference.

One question that I have, the RO-data, is it in RAM or Flash ? If it is RAM, the 12kb of SRAM is almost done .. :(

But I guess the RO-data is in ROM.

(The STM32F334 seems like a one of a kind microcontroller. Even the STM32H7 microcontroller which is previewing, seems to have a scaled down variant of the HRTIM peripheral. Sad that there aren't any other controllers from ST, having HR-PWM and larger memory/clock speeds. :( Maybe someone @ ST takes note of this issue and closes the gap hopefully. If you are asking for my wish, more PWM pins and ADC pins, DMA channels, definitely are nice goodies. The Infineon XMC chips seems nice with regards to memory and peripherals especially the HRPWM and the PID controller on it, but that would mean switching everything. The TI UCD3138xx seems to have everything, but that one doesnt seem to be pleasant to work with any way)

Getting back from my little rant, I am wondering how to dissect this problem. Can someone give me some insight how to navigate this issue ?

Thanks

[Tesla DeLorean]

Posted on April 08, 2017 at 18:02

For stack I typically add code to check the depth in dynamic usage, also Keil outputs an HTML file breaking down the call tree and stack usage.

The stack is placed immediately above the heap and statics, if it ploughs into them you can get odd behaviour.

Make sure you properly initialize or clear auto/local variables.

Use a proper Hard Fault Handler so you can see if any gross failure has occurred.

https://community.st.com/0D50X00009XkYYDSA3

https://community.st.com/0D50X00009XkfOXSAZ

Use the debugger in this situation to understand where it is actually stuck.

[Manu Abraham]

Posted on April 08, 2017 at 19:12

Hi Clive,

I find the very first line in the html file, strongly indicating the function call depth.

Maximum Stack Usage = 280 bytes + Unknown(Functions without stacksize, Cycles, Untraceable Function Pointers)

I tried adding in

void HardFault_Handler(unsigned int * hardfault_args, unsigned int r4, unsigned int r5, unsigned int r6)

{ printf ('[Hard Fault]\n'); // After Joseph Yiu printf ('r0 = %08X, r1 = %08X, r2 = %08X, r3 = %08X\n', hardfault_args[0], hardfault_args[1], hardfault_args[2], hardfault_args[3]); printf ('r4 = %08X, r5 = %08X, r6 = %08X, sp = %08X\n', r4, r5, r6, (unsigned int)&hardfault_args[8]); printf ('r12= %08X, lr = %08X, pc = %08X, psr= %08X\n', hardfault_args[4], hardfault_args[5], hardfault_args[6], hardfault_args[7]); printf ('bfar=%08X, cfsr=%08X, hfsr=%08X, dfsr=%08X, afsr=%08X\n', *((volatile unsigned int *)(0xE000ED38)), *((volatile unsigned int *)(0xE000ED28)), *((volatile unsigned int *)(0xE000ED2C)), *((volatile unsigned int *)(0xE000ED30)), *((volatile unsigned int *)(0xE000ED3C)) ); while(1); }

to main as you suggested in

https://community.st.com/thread/15262?commentID=8095#comment-8095

But that freezes up everything, stuck at SystemInit

Attached screenshot

variables are minimal, and all of them inittialized before use.

How to use the debugger, when doing DMA transactions and such ? Also, steeping through delays seems like the steps do not end, even for those very small delays.

________________ Attachments : Test 2.htm.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hyih&d=%2Fa%2F0X0000000bBU%2F9q4YuSPLN_I_rdp0E0wKPgI3qSinE09mrGDrL7FG_G0&asPdf=falseStuck.PNG : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyiY&d=%2Fa%2F0X0000000bBW%2FNY0QR4bwbfymNfTPndQF15jmrxjGI_PQ7H7yelMzWGw&asPdf=false

[Tesla DeLorean]

Posted on April 08, 2017 at 19:36

You'd need code hosting the USART output. If it fails prior to main(), break-point the handler

Not recommending single-stepping real-time code, but when it locks up you need to make a determination about where it is, and the general state of the system. Once you know where to start looking, add telemetry and diagnostic output, and recognize system conditions leading to the failure.

[Manu Abraham]

Posted on April 08, 2017 at 19:52

By 'code hosting the USART output' do you mean something like this

http://www.keil.com/pack/doc/compiler/RetargetIO/html/_retarget__examples__u_a_r_t.html

?

[Tesla DeLorean · Accepted solution]

Posted on April 08, 2017 at 20:01

I use this in uV4

https://community.st.com/0D50X00009XkeksSAB

Adding more text to break moderation w/link

The BKPT suggests it is calling printf()/putchar() via semi-hosting code in the library, you don't want that happening..

[S.Ma]

Posted on April 10, 2017 at 11:12

When merging different piece of code, check that all the interrupt handlers are present. You could toggle a GPIO when entering ISR and see if it is swamped in one because the ISR is not clearing any HW pending flags...

[Manu Abraham]

Posted on April 12, 2017 at 15:21

Code hosted the USART output, which helped the printf not to go nuts (myself too, in the longer run. ;) ).

I made the change to use UART1 instead of UART2, since it was already wired up and ready.

This prompted me to use printf to be consistent, instead of using putstr and a 50 byte long char array.

With this change, the display now draws correctly, without issues. Have a knot in my head, how and why.. I have been trying a bit hard to replicate the original problem. Probably the putstr was overwriting the stack. I wonder how that could happen though, since never wrote anything that long. After writing this much, looking at the snapshot with the issue which i posted, well I did write 52 bytes. :-X Sigh! Probably that explains a lot.

(The code looked correct, in every review and that was true too.)

It would've been extremely difficult to spot the bug, if not for the switch from putstr to printf !

(Even while writing this reply, was thinking what the bug could be though.. :) )

Thanks a lot

[Manu Abraham]

Posted on April 12, 2017 at 15:40

Actually was not merging code at all, but trying hard to selectively paint the display regions. the calculations to do the offsets were long and giving me a headache, (such that only  the deltas are drawn, while I could resize the display) which made me dump those values to a console, to detect issues. But the issue turned out not to be there in those calculations or values, but somewhere so silly. The idea to toggle a GPIO to test ISR swamped is quite thoughtful.

[Tesla DeLorean]

Posted on April 12, 2017 at 17:30

Appreciate you came back with the follow-up, good luck with your project.